如何做好項目啟動階段的需求管理？

根據(jù)PMI的解釋，接單之后項目自然轉(zhuǎn)入啟動階段。在這個階段，隨著需求分析的深入，PM也開始在公司內(nèi)部進行人員挑選和資源爭奪，著手組建自己的項目團隊。項目即將進入計劃階段。啟動階段PM的主要任務(wù)是率領(lǐng)總體架構(gòu)設(shè)計師和系統(tǒng)分析員收集盡可能詳細的數(shù)據(jù)，確立盡可能詳細的需求，進一步確立詳細的項目范圍，預(yù)估資源，確立其他方案并獲得進入下一階段的批準(zhǔn)。

在收集完數(shù)據(jù)之后，PM要和客戶開始明確項目的大小，成本，規(guī)格，期限等重要特征并將其寫入合同文本，同時準(zhǔn)備內(nèi)部的包括預(yù)算，衡量標(biāo)準(zhǔn)等文檔，建立項目的評估標(biāo)準(zhǔn)。接下來就是需求分析。由于專業(yè)的原因，我們這里僅討論軟件工程項目的需求分析（以下簡稱需求分析）。需求分析的主要參與人員有PM，總體架構(gòu)設(shè)計師，系統(tǒng)分析員，熟悉業(yè)務(wù)流程的客戶。PM統(tǒng)領(lǐng)的團隊這時候還不是真正的開發(fā)團隊，我們叫做前期團隊。隨著需求分析的逐步深入，新的團隊成員不斷加入，啟動階段結(jié)束的時候正式的團隊將建立。對一個已經(jīng)啟動的項目來說，需求分析直接決定了項目的成功與失敗。最初的需求體現(xiàn)在客戶的工作說明書或招標(biāo)文件及附件上。這種需求一般比較含糊，無法體現(xiàn)客戶真正的需求。

前期團隊要根據(jù)自己的經(jīng)驗和客戶溝通并引導(dǎo)客戶進入正軌。有時候客戶會很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個時候團隊成員要耐心和客戶舉事實，談經(jīng)驗，講道理，用圖形或模型等直觀的方式將需求描述出來，比如常見的數(shù)據(jù)流圖等。所以說，爭論再所難免，客戶有時候會吹胡子瞪眼睛拍桌子甚至?xí)�說"這個東西不要你們做了"之類的話。PM此時除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶的關(guān)系，確保關(guān)系不會惡化到無法收拾的地步。只要PM盡力約束團隊中的成員，這個度還是很容易控制的。

對快速開發(fā)和疊代開發(fā)來說，需求和實現(xiàn)往往是同步進行，開發(fā)速度快是一大優(yōu)勢。對有相同或類似模式的小項目來說采用快速開發(fā)或疊代開發(fā)是很合算的做法，時下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場上就只有產(chǎn)品而沒有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個問題，究竟應(yīng)該在需求分析和總體設(shè)計上花費多少時間？我們熟悉的瀑布開發(fā)模式基本上分需求分析，總體設(shè)計，軟件開發(fā)，測試等幾個階段，然而究竟應(yīng)該在前兩個階段上花多少時間卻沒有定論。實際項目操作的例子表明，分析設(shè)計的時間越長，需求設(shè)計做的越詳細，測試的時間就越短，返工率越低，風(fēng)險也越小，成本越容易得到控制。

而需求分析和總體設(shè)計沒有做好就急忙上馬進行開發(fā)的項目在項目初期進展順利的時候問題不大，到了項目后期和測試階段一些潛伏期比較長但是破壞作用比較大的問題就會凸顯出來，造成返工，延長測試時間。所以與其把問題堆積到緊張的項目后期，不如把時間多花點到需求分析和總體設(shè)計上。基礎(chǔ)夯實了，金字塔就容易造了。 在日本公司打工的程序員們可能都知道，小日本的軟件規(guī)范非常厲害，他們花在需求分析和總體設(shè)計上的時間通常在40%到50%左右，遠遠超過國內(nèi)軟件項目的實施，效果也要強的多。他們總體設(shè)計的規(guī)范甚至詳盡到某個過程該如何判斷，確立什么樣的條件，換言之就是把什么時候該如何寫(if...else)語句都幫程序員定好了。在這樣的軟件規(guī)范下，程序員更象是裝配流水線上的工人，對一個模塊或技術(shù)熟悉到一定程序就變成了完全的重復(fù)性勞動。

所以在日本和歐美經(jīng)常會有程序員是低級工作一說，很多人不明就里，對國內(nèi)程序員也照搬，對國內(nèi)的程序員來說是很不公平的。在國內(nèi)，只會照抄別人代碼，一點都不懂創(chuàng)新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優(yōu)秀的不斷進取的程序員也很多。由于國內(nèi)沒有象CMM這樣的軟件規(guī)范或者很少，所以這類優(yōu)秀的程序員不少都是干著系統(tǒng)分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現(xiàn)明顯的分化。當(dāng)上進的程序員們作為PM進行商務(wù)談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。

日本的軟件規(guī)范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經(jīng)濟不景氣，東京倒閉了160家軟件公司，這個數(shù)字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術(shù)人員。如果去這樣的公司應(yīng)聘就要考慮清楚了，進去可以學(xué)到他們的規(guī)范和質(zhì)量控制，可是要想從程序員成為系統(tǒng)分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經(jīng)通過CMM4），對在華為工作的程序員們來說可謂福禍難料。

當(dāng)然，已經(jīng)作到PM或QA或者熱愛CODING的朋友例外。 需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復(fù)審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復(fù)討論和磋商，反復(fù)提交文檔和表格，目的只有一個，明確需求。當(dāng)PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責(zé)人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。

需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內(nèi)目前的項目大多數(shù)客戶為了不讓自己的錢白花，經(jīng)常變著法子提需求。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術(shù)難關(guān)，就會放棄項目。典型的例子就是NMD洲際導(dǎo)彈防御系統(tǒng)。上世紀(jì)八十年代初美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認為蘇聯(lián)人上了美國的當(dāng)。其實并不完全如此，蘇聯(lián)人的情報機構(gòu)無孔不入，并非那么容易上當(dāng)受騙。實際上當(dāng)時美國國防部已經(jīng)開始著手NMD系統(tǒng)軟件的需求分析，前后耗資數(shù)億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現(xiàn)存在著在當(dāng)時技術(shù)上無法達到的高度，隨后項目被放棄。

在項目啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。 詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領(lǐng)域?qū)⑹且粋�決定是否進行項目的判斷標(biāo)準(zhǔn)。