如何做好項目啟動(dòng)階段的需求管理？
發(fā)布時(shí)間：2023/2/15 10:00:00
根據PMI的解釋?zhuān)訂沃箜椖孔匀晦D入啟動(dòng)階段。在這個(gè)階段，隨著(zhù)需求分析的深入，PM也開(kāi)始在公司內部進(jìn)行人員挑選和資源爭奪，著(zhù)手組建自己的項目團隊。項目即將進(jìn)入計劃階段。啟動(dòng)階段PM的主要任務(wù)是率領(lǐng)總體架構設計師和系統分析員收集盡可能詳細的數據，確立盡可能詳細的需求，進(jìn)一步確立詳細的項目范圍，預估資源，確立其他方案并獲得進(jìn)入下一階段的批準。
在收集完數據之后，PM要和客戶(hù)開(kāi)始明確項目的大小，成本，規格，期限等重要特征并將其寫(xiě)入合同文本，同時(shí)準備內部的包括預算，衡量標準等文檔，建立項目的評估標準。接下來(lái)就是需求分析。由于專(zhuān)業(yè)的原因，我們這里僅討論軟件工程項目的需求分析（以下簡(jiǎn)稱(chēng)需求分析）。需求分析的主要參與人員有PM，總體架構設計師，系統分析員，熟悉業(yè)務(wù)流程的客戶(hù)。PM統領(lǐng)的團隊這時(shí)候還不是真正的開(kāi)發(fā)團隊，我們叫做前期團隊。隨著(zhù)需求分析的逐步深入，新的團隊成員不斷加入，啟動(dòng)階段結束的時(shí)候正式的團隊將建立。對一個(gè)已經(jīng)啟動(dòng)的項目來(lái)說(shuō)，需求分析直接決定了項目的成功與失敗。最初的需求體現在客戶(hù)的工作說(shuō)明書(shū)或招標文件及附件上。這種需求一般比較含糊，無(wú)法體現客戶(hù)真正的需求。
前期團隊要根據自己的經(jīng)驗和客戶(hù)溝通并引導客戶(hù)進(jìn)入正軌。有時(shí)候客戶(hù)會(huì )很不講道理或者思路僵化，就要求按照他的思維去定一些明顯錯誤的需求。這個(gè)時(shí)候團隊成員要耐心和客戶(hù)舉事實(shí)，談經(jīng)驗，講道理，用圖形或模型等直觀(guān)的方式將需求描述出來(lái)，比如常見(jiàn)的數據流圖等。所以說(shuō)，爭論再所難免，客戶(hù)有時(shí)候會(huì )吹胡子瞪眼睛拍桌子甚至會(huì )說(shuō)"這個(gè)東西不要你們做了"之類(lèi)的話(huà)。PM此時(shí)除了要親身參與需求分析綜合整理文檔之外，還要處理好團隊成員與客戶(hù)的關(guān)系，確保關(guān)系不會(huì )惡化到無(wú)法收拾的地步。只要PM盡力約束團隊中的成員，這個(gè)度還是很容易控制的。
對快速開(kāi)發(fā)和疊代開(kāi)發(fā)來(lái)說(shuō)，需求和實(shí)現往往是同步進(jìn)行，開(kāi)發(fā)速度快是一大優(yōu)勢。對有相同或類(lèi)似模式的小項目來(lái)說(shuō)采用快速開(kāi)發(fā)或疊代開(kāi)發(fā)是很合算的做法，時(shí)下流行的極限編程就是針對這方面建立的思維模式。然而，大中型項目中有太多不一樣的需求和模塊。如果不是因為項目有差異，那么市場(chǎng)上就只有產(chǎn)品而沒(méi)有項目了。所以，大中型項目的需求要認真仔細的去做。我們要討論一個(gè)問(wèn)題，究竟應該在需求分析和總體設計上花費多少時(shí)間？我們熟悉的瀑布開(kāi)發(fā)模式基本上分需求分析，總體設計，軟件開(kāi)發(fā)，測試等幾個(gè)階段，然而究竟應該在前兩個(gè)階段上花多少時(shí)間卻沒(méi)有定論。實(shí)際項目操作的例子表明，分析設計的時(shí)間越長(cháng)，需求設計做的越詳細，測試的時(shí)間就越短，返工率越低，風(fēng)險也越小，成本越容易得到控制。
而需求分析和總體設計沒(méi)有做好就急忙上馬進(jìn)行開(kāi)發(fā)的項目在項目初期進(jìn)展順利的時(shí)候問(wèn)題不大，到了項目后期和測試階段一些潛伏期比較長(cháng)但是破壞作用比較大的問(wèn)題就會(huì )凸顯出來(lái)，造成返工，延長(cháng)測試時(shí)間。所以與其把問(wèn)題堆積到緊張的項目后期，不如把時(shí)間多花點(diǎn)到需求分析和總體設計上�；A夯實(shí)了，金字塔就容易造了。 在日本公司打工的程序員們可能都知道，小日本的軟件規范非常厲害，他們花在需求分析和總體設計上的時(shí)間通常在40%到50%左右，遠遠超過(guò)國內軟件項目的實(shí)施，效果也要強的多。他們總體設計的規范甚至詳盡到某個(gè)過(guò)程該如何判斷，確立什么樣的條件，換言之就是把什么時(shí)候該如何寫(xiě)(if...else)語(yǔ)句都幫程序員定好了。在這樣的軟件規范下，程序員更象是裝配流水線(xiàn)上的工人，對一個(gè)模塊或技術(shù)熟悉到一定程序就變成了完全的重復性勞動(dòng)。
所以在日本和歐美經(jīng)常會(huì )有程序員是低級工作一說(shuō)，很多人不明就里，對國內程序員也照搬，對國內的程序員來(lái)說(shuō)是很不公平的。在國內，只會(huì )照抄別人代碼，一點(diǎn)都不懂創(chuàng )新，凡事依靠別人，快下班就盯著(zhù)表看的程序員是不少，這種人一般很難有什么前途。但是，優(yōu)秀的不斷進(jìn)取的程序員也很多。由于國內沒(méi)有象CMM這樣的軟件規范或者很少，所以這類(lèi)優(yōu)秀的程序員不少都是干著(zhù)系統分析員甚至PM的活，拿著(zhù)程序員的工資。這類(lèi)程序員雖然在起步時(shí)會(huì )吃很多虧，而且是主動(dòng)找虧吃，然而幾年之后與前一種程序員的社會(huì )地位會(huì )出現明顯的分化。當上進(jìn)的程序員們作為PM進(jìn)行商務(wù)談判的時(shí)候，前者還在各個(gè)公司里頻繁跳槽，跳來(lái)跳去都不滿(mǎn)意。有些扯開(kāi)了，回到我們的話(huà)題。
日本的軟件規范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經(jīng)濟不景氣，東京倒閉了160家軟件公司，這個(gè)數字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術(shù)人員。如果去這樣的公司應聘就要考慮清楚了，進(jìn)去可以學(xué)到他們的規范和質(zhì)量控制，可是要想從程序員成為系統分析員或PM，比登天還難。往往一個(gè)程序員進(jìn)去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經(jīng)通過(guò)CMM4），對在華為工作的程序員們來(lái)說(shuō)可謂福禍難料。
當然，已經(jīng)作到PM或QA或者熱愛(ài)CODING的朋友例外。 需求分析本身也存在著(zhù)時(shí)間分配的問(wèn)題。第一遍需求分析花的時(shí)間會(huì )最長(cháng)，分析員們在客戶(hù)的各個(gè)部門(mén)之間幾乎把腿都跑斷，把口水說(shuō)干，就是為了確立一個(gè)初期的需求模型。所有的文檔將會(huì )提交給PM進(jìn)行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶(hù)，第二遍第三遍等等等等接踵而來(lái)，與客戶(hù)反復討論和磋商，反復提交文檔和表格，目的只有一個(gè)，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶(hù)的各部門(mén)負責人簽字。這些文檔將作為合同的附件添加，以便在將來(lái)項目變更或者碰到重大問(wèn)題時(shí)和客戶(hù)扯皮的重要依據。
需要說(shuō)明的是，客戶(hù)并非都是蠻不講理，但是說(shuō)實(shí)話(huà)，頗有無(wú)奈，國內目前的項目大多數客戶(hù)為了不讓自己的錢(qián)白花，經(jīng)常變著(zhù)法子提需求。有時(shí)候，這種大項目在簽單時(shí)雙方都沒(méi)有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現難以逾越的技術(shù)難關(guān)，就會(huì )放棄項目。典型的例子就是NMD洲際導彈防御系統。上世紀八十年代初美國搞星球大戰計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認為蘇聯(lián)人上了美國的當。其實(shí)并不完全如此，蘇聯(lián)人的情報機構無(wú)孔不入，并非那么容易上當受騙。實(shí)際上當時(shí)美國國防部已經(jīng)開(kāi)始著(zhù)手NMD系統軟件的需求分析，前后耗資數億美圓，耗時(shí)兩年，僅僅是做需求分析，終于發(fā)現存在著(zhù)在當時(shí)技術(shù)上無(wú)法達到的高度，隨后項目被放棄。
在項目啟動(dòng)階段明確需求并簽字，無(wú)論最終情況如何，一份詳盡的書(shū)面文檔可以解決很多口頭承諾或概念模糊的文檔帶來(lái)的許多問(wèn)題。 詳盡的需求分析有一個(gè)額外的好處就是對一些雙方都很陌生或者從來(lái)無(wú)人嘗試的領(lǐng)域將是一個(gè)決定是否進(jìn)行項目的判斷標準。