有同學問我這個問題：

“你正在做一個項目，這個項目有一項關鍵的feature需要實現，這個feature有一定的技術難度，你調試了很久，都沒找到實現的途徑，這時你已經在這個feature上花了很多時間了，而且無法預期解決需要多長時間。在這種情況下，你會怎么做？”

一種典型失敗的情況是：

第一天：我正在做一個關鍵的feature, 看起來不難，做好了會很有面子。。。

第三天：就是搞不通，就這樣過了三天，其中“murphy's law”又浪費了一天。我想還是加班，先別告訴老板；如果做好了，再加緊做幾個小的feature。這樣還是能趕上進度。。。

第五天：全組開會，支吾了幾句，說還是很有希望如期完成的。。。

第九天：加了班，也問了同事，還是沒戲，小的feature也沒時間做了… 眼看期限就要到了，心里充滿了悲劇情緒。老板要是問起，就如實說明，要是沒問，我還是爭取做好了再報告。

第十一天：期限到了！還是沒頭緒， 要和老板開會review了，Panic！

首先我們要明確，這是一個實際的團隊項目。不是學校里的閉卷考試（一些人在離開學校很久還偶爾做惡夢，考試中一些題做不出來…）。

實際的項目中的問題，都是有解的，而且大多數是多項式時間內有解。我們在現實項目中的“解題能力”，取決于下面這些因素：

1．  對問題的了解，有沒有能力了解客戶需求，分析問題，把大問題分解成小問題來解決。有沒有眼光看到可以簡化/繞過一些難題. 在閉卷考試的時候，所有的題意都在試卷上，理解好了之后，就可以埋頭做題了；但是實際項目中，用戶的初始需求是非常含糊的，而且經常變化。比如“網站要支持搜索”- 是哪一種呢？

      - 全部自己做搜索，還是可以用第三方的解決方案？

      - 所有剛剛post的信息必須立即顯示在結果中，還是允許有延時

      - 支持中文？分詞？還是。。。

      - 支持復雜的查詢條件么？是否支持再次查詢？

      - 結果的ranking 有何要求？

      - 最終想達到什么結果？

      不同的需求，有不同的解決方案，這時不宜“make too much assumption”，認為用戶要的就是某一種，就甩開膀子開始做。

      要深入的了解用戶文字后面的真正理由，一個工程師有一次說他的企業客戶要求 UI 所有的按鈕都要是3D 并且半透明。深入了解后，發現原因是客戶的MM 喜歡玩某一時髦游戲軟件（就不點名了），上面的按鈕都是這樣的。 工程師大叫一聲 - 我倒...   他從Faint 中蘇醒后，怎么辦?  我想他可以提示客戶專注于軟件的流程和業務邏輯，也許能把按鈕的需求放到較低的優先級。

      另外，有時候 low-tech 的解決方案要更好。 不一定每一個類都要多態繼承, 用很多虛函數, 才能實現。

2．  對技術的了解，看書的時候覺得“技止此耳”，開發項目的時候才覺得實際情況和書上講的都有一些出入，偏偏一些重要的出入書上沒有提。我們很多人是邊看asp.net的書, 邊開發asp.net 的項目，這相當于一邊看醫學書一邊動手術。。。

3．  溝通的能力 – 軟件工程項目中最怕的是“surprise”和“lack of visibility”，作為程序員，溝通非常重要。及早和同事/上級/客戶通報項目遇到的風險，會讓大家都了解項目的進展及問題，及時得出解決方案。 比如要達到某個要求有困難，用戶是否一定要此功能？要及時溝通。

4．  估計任務的能力 – 軟件項目難度及日程的估計，是一門不小的學問，初學者犯了錯誤也沒關系，關鍵是要吃一塹，長一智。當你說“某某 feature要在某某日子完成”，你的意思是到了那一天：

    - 程序剛寫好，編譯通過， or

    - 可以在debugger 中運行通過， or

    - debug/retail 都成功，可以集成在網站上，但是有一些問題 or

    - 自己已經完成了測試， or

    - 測試人員已經全面完成了測試，or

    - 和其他有依賴關系的功能都集成測試過。

    要達到不同的狀態需要的時間是很不一樣的！

5.  在以上能力的基礎上，還要有對不切實際的需求說 “no”的勇氣和自信。

講了這么多，我想大家都會知道怎么做了。

原作寫于 2006 年.

http://yishan.cc/blogs/xin/archive/2006/07/17/450.aspx