今天看到同事寫的一些思考，感覺還不錯，真的是通過這個項目讓他成長起來了。
對軟件項目開發的一點思考
湖工項目階段總結
1 引言
湖工項目磕磕碰碰也進行了很長時間，其中的酸甜苦辣，其中的艱辛，不是一言兩語能夠說清楚。
湖工項目是爲高校開發一套教務系統，是一個完整解決方案型項目，業務涵蓋學生從入校到出校四年中的所有教學活動，用戶包括：學生、授課教師，教務處各相關辦公窒，校領導，離退休教師等。
在整個項目的諸多問題中，項目前期風險評估不足，過於樂觀是最主要的問題，在項目實施過程中，項目邊界不確定，項目需求不清，計劃控制不好是現在所表現出來的問題的根源。這些問題常常引發我思考兩個問題：
什麼是軟件工程？
什麼是項目管理？
2 概念
“軟件工程”的概念書上和網上都有，之所以有軟件工程這個概念，是當時人們爲了解決軟件危機，而照搬其他領域已經很成熟的工程方法論到軟件開中來，再慢慢發展和總結才形成今天我我們所看到的所謂的軟件工程理論。軟件工程並不能保證一個項目成功，但卻能最大限度地保證項目不會失敗，這也是軟件工程的價值所在。
“項目管理”也是從其他領域來的，不是軟件開發獨創的。按照PMBOK紅寶書理論，項目管理是將知識、技能、工具與技術應用於項目活動，以滿足項目的要求（這個說得有點泛）。項目是爲了創造獨特的產品、服務或成果而進行的臨時性工作。項目的“臨時性”是指項目具有明確的起點和終點。當項目目標達成時，或當項目因不會達到或者不能達到目標而終止時，或者項目需求不復存在時，項目就結束了。
3 國內軟件項目角色分析
軟件開發是因人的需求而開始，又因人的需求被滿足而結束。軟件開發的根本是人，與技術無關，技術只是爲了滿足人的需求，不能滿足人的需求的技術是毫無價值的。下面就來分析一下軟件開發過程中所涉及到的各人各角色的特點。
表 31 軟件項目中各角色分析
|
哪方 |
角色 |
特點 |
|
客戶 |
高層領導 |
十分清楚項目目標，期望在指定的預算內達成目標。基本核心需求一定會堅持，對於不太影響目標實現的需求可以作讓步 |
|
中層領導 |
基本清楚項目目標，按照高層的意思辦事，爲保證滿足高層的要求，可能會對需求從嚴把握，但部分情況下可能迷失項目目標 |
|
|
基層用戶 |
不太清楚項目的目標，只關心能不能解決他具體的本職工作問題，往往會提出一些匪夷所思的需求 |
|
|
公司 |
高層領導 |
很清楚客戶的目標，想辦法以儘量低的成本來滿足。從本公司戰略發展的角度來處理客戶的要求 |
|
銷售人員 |
爲讓客戶簽單，容易做出項目組無法滿足的承諾，給客戶過高的期望值 |
|
|
項目經理 |
揹負超大的進度壓力，期望需求儘量少，容易背離項目目標。遇到需求變化時，難以靜下心來仔細思考 |
|
|
架構師 |
基本能理解項目需求，容易設計出過於超前的軟件架構，也容易設計出粗糙的設計甚至無設計，以致某些需求無法滿足，或者需要巨大的開發工作量 |
|
|
程序員 |
不太清楚項目的目標，對需求沒有全局觀，對於自己負責部分的需求瞭解得不深 |
|
|
測試員 |
不能得到“一手”的需求，需求往往是開發人員告知的，對軟件需求可能有很多疑問，但沒有時間或者沒有機會去求證。 |
|
|
實施員 |
很清楚客戶基層用戶的需求，但向項目組反饋意見時往往得不到重視。部分情況下，容易陷於需求細節，而迷失了項目目標 |
總的來說：
客戶一方總是傾向於：自己花最少的錢，讓軟件公司做最多的事；
軟件公司一方總是傾向於：多拿客戶的錢，儘量少做事。
4 國內項目的一般性問題
國內的項目，不管是開發過程還是開發完成，如果上線了，一般會遇到以下三種情況：
Ø 情況一、客戶一直沒有提出任何問題。
Ø 情況二、客戶一開始提了一些問題，但很快就沒有其他問題了。
Ø 情況三、客戶一直在提問題，項目組解決這些問題後，新的問題又來了，如此不斷重複。
分析：
情況一：估計客戶沒有怎麼使用過這套系統，所以沒提出什麼問題。對於項目組來說，似乎不用再被麻煩的需求變更所糾纏，可以爽快地脫離此項目了。但對於客戶來說，此係統白白花費了他們的錢，對他們沒有任何實際價值，對於公司來說，花費了那麼多的人力做出系統，客戶卻沒用上，很可能收不到項目驗收款。這種結果是“雙輸”。
情況二：可能是客戶試用了一段時間後，覺得系統不能滿足他們的需求，不再使用這個系統了。這種情況，項目估計很難驗收通過，公司收不到項目款，客戶不使用該系統，又是“雙輸”。
情況三：這可能是比較理想的情況，說明客戶在不斷地使用該系統。這些問題最開始會比較多，最開始項目組解決問題的速度會低於產生問題的速度，但後來問題逐步減少，直至基本消失，軟件和用戶的“磨合”過程終於完成，系統最終成爲客戶日常工作中的一部分。
5 客戶與項目組對需求的認知情況
需求開發和需求管理會貫穿於整個項目週期，在整個軟件項目開發週期中，隨着時間的推移，項目組和客戶對需求的理解程度會存在下面兩種情況中的一種。
5.1 第一種情況
對於第一種情況，在項目剛開始的時候，項目組對需求的理解是爲零的，客戶在項目剛開始的時候，對需求是有一定認識的。隨着時間的發展，客戶對需求的理解越來越強，儘管項目組對需求的理解也同樣在變強，但項目組對需求的理解總是落後與客戶，這樣需求分析工作肯定陷於被動，總是會被客戶“牽着鼻子走”，很容易出現互相責怪的局面：客戶責怪項目組水平太差，而項目組責怪客戶需求變來邊去！如果出現這種情況，項目進展往往不會順利，甚至有失敗的風險。
5.2 第二種情況
對於第二種情況，在項目剛開始時，客戶對需求的理解確實比項目組強，但在很短的時間內對需求的認識迅速超過了客戶，進而能引導客戶對需求的理解。從圖中的“交點”以後，項目組對需求的理解總是領先與客戶。項目組應具備超強的業務學習能力，迅速理解客戶的真正需求，抓住需求的本質，這樣才能做出符合客戶需要的軟件系統。
6 湖工項目實施過程中碰到的問題
6.1 項目邊界問題
在項目實施過程中，出於某些原因，項目邊界一直得不到確定，這樣造成一個很大的問題是：項目經理無法確定哪些需求該接受，哪些需求該拒絕，標書上又寫得很泛，很可能客戶一句話，可能要開發兩三個月。項目邊界不清晰時，項目經理就沒有拒絕客戶的依據，在博弈過程中很容易處於下風。客戶的想法很跳躍，什麼都想做，在客戶現場發現別的公司常常以不在合同範圍爲由委婉拒絕客戶的靈光想法，防止需求氾濫。
最理想的情況是，在項目正式編碼前能確定好：哪些需求能做，做到什麼程度？有限的預算只能做有限的事情，不能盲目樂觀承諾。
6.2 項目需求問題
6.2.1 沒有專業的需求管理
項目前期和項目實施過程中，沒有進行專業的開發和需求管理工作，基本上是客戶說了幾句後就回來埋頭開發，沒有從整體上去把握和控制需求。經常開發一段時間後，出現無可用的需求來支撐編碼開發，因爲需求開發工作還在進行中。
最好的做法是，在正式編碼前，一定要完成需求開發工作，然後在開發過程中逐漸的清晰需求。
6.2.2 對需求的認知滯後
項目經理和項目組對需求的認知一直滯後於客戶，就像前文說的第一種情況，沒有做到第二種情況，總是被客戶牽着鼻子走，還被客戶認爲不專業，然後項目組再跟着抱怨客戶的需求總是變來變去。
其實，湖工項目的精髓就在於業務，如果業務認知清楚以後，項目已經成功了80%。強智高校教務系統在教育行業立足十餘載，靠的就是業務爲王，他們的系統連IE以外的瀏覽器都不支持，但這並不妨礙他們賣出一套又一套的產品。
所以爲了解決這個問題，最簡單直接的方法是請一個業務專家，如果不能這樣的話，只能是項目組慢慢陪着客戶學習業務，這樣就變成一場持久戰，如果最後產品化戰略能成功，再用產品的收益去填補項目研發過程的超支費用。
6.2.3 沒有獲取到真正的需求
項目需求的提供者爲客戶領導，客戶領導對需求的理解不深入，項目經理過分依賴客戶領導，沒有向真正的用戶挖掘需求。項目初期，項目需求基本上來自於客戶領導，但客戶領導又不是最終用戶，這樣就會造成開發出來的功能和真正用戶的需求偏差很大，用戶抱怨很大，最終會造成大量返工。
比較好的做法是，向基層用戶收集需求，整理清楚後，請客戶領導一來拍板確認。
6.2.4 沒有專職的接口人
湖工項目都是由客戶領導作爲接口人，但領導比較忙，基本上沒有時間，有時候去客戶那裏等了一天都無法確認一件事情。與客戶交流時最好以開會的形式進行，相關干係人都要到場，會議結論以文檔形式在會後發送相關人員，這樣可以提高交流的效率，減少溝通成本。
6.3 項目計劃、里程碑問題
由於項目邊界和項目需求無法明確，項目的計劃及里程碑也就很難確定，這樣就造成項目進行到一半時，還是沒有一份完整的開發計劃，無法跟蹤項目進度，很難估算出還需要多少人力，還需要多少時間，無限增大了項目風險。
7 結語
本文基本上從人的角度和需求的角度結合實際項目去分析軟件開發，沒有全面展開討論，主要緣由時間和篇幅的限制，希望透過這兩點能達到一葉知秋的目的，這兩點就是人和需求，就像前文所說，軟件開發起於人的需求被發現，而止於人的需求被滿足。
