給將要進入職場的同學 – 開發軟體不是閉卷考試

有同學問我這個問題：

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

  

一種典型失敗的情況是：

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

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

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

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

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

 

 

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

 

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

 

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