下面是對(duì)一位項(xiàng)目經(jīng)理關(guān)于需求管理的訪談：

　　做了那么多個(gè)項(xiàng)目，我深深感到對(duì)項(xiàng)目的需求把握管理好了，是項(xiàng)目成功的關(guān)鍵。對(duì)需求的管理大概有那么幾個(gè)活動(dòng)，首先是需求獲取，這是一個(gè)確定和 理解客戶的需要和期望的過程，為實(shí)現(xiàn)項(xiàng)目目標(biāo)而定義、記錄、分析干系人的需求; 其次，是要求獲得相關(guān)人員對(duì)需求的認(rèn)可和承諾;最后，即使是需求確定下來之后，也不可避免得會(huì)有變更，如何控制和管理變更，是保障項(xiàng)目目標(biāo)的實(shí)現(xiàn)的重要環(huán) 節(jié)。

　　2010年，我擔(dān)任了公司一個(gè)重要項(xiàng)目，老撾TAIS系統(tǒng)的項(xiàng)目經(jīng)理，該項(xiàng)目是一個(gè)系統(tǒng)集成項(xiàng)目，在此之前，我并沒有做過類似項(xiàng)目，為謹(jǐn)慎起見，嚴(yán)格按照需求管理的規(guī)范執(zhí)行，收獲了很多經(jīng)驗(yàn)，也保證了項(xiàng)目的順利交付。

　　1、需求獲取 需求獲取分為兩個(gè)階段，需求調(diào)查、需求定義。需求調(diào)查和需求定義在邏輯上存在先后關(guān)系，但實(shí)際工作中二者通常是迭代進(jìn)行的。需求分析的工作則貫穿于“需求 調(diào)查”和“需求定義”兩個(gè)階段。 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息(原始材料)，產(chǎn)生《用戶需求說明書》。

　　需求分析的目的是對(duì)各種需求信息進(jìn)行分析，消除錯(cuò)誤，刻畫細(xì)節(jié)等。需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說明書》。系統(tǒng)設(shè)計(jì)人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計(jì)工作。

　　在進(jìn)行現(xiàn)場(chǎng)需求調(diào)查之前，我首先需要了解的是，這個(gè)項(xiàng)目是什么樣的項(xiàng)目，大概做什么事情?并仔細(xì)閱讀了售前階段產(chǎn)生的所有文檔資料，和售前階段參與人員交流溝通，進(jìn)一步了解項(xiàng)目是誰提出來的，目的是解決什么問題。

　　不單單聽介紹，特別關(guān)注了與合同具有同等效力的那些文件，如技術(shù)協(xié)議，工作說明書(SOW)、實(shí)施方案等等。從而知道，該項(xiàng)目是一個(gè)老撾 TAIS (THSCAN-ASYCUDA Integration Solution)項(xiàng)目是我司集裝箱/車輛檢查系統(tǒng)與海關(guān)數(shù)據(jù)系統(tǒng)整合解決方案的簡(jiǎn)稱。目前在老撾境內(nèi)，8個(gè)地點(diǎn)部署了6套車載式系統(tǒng)和2套組合式系統(tǒng)， 老撾海關(guān)使用的海關(guān)自動(dòng)化業(yè)務(wù)系統(tǒng)叫ASYCUDA，TAIS就是要實(shí)現(xiàn)NUCTECH掃描設(shè)備與海關(guān)數(shù)據(jù)系統(tǒng)的高度集成和信息共享。

　　了解都項(xiàng)目的業(yè)務(wù)領(lǐng)域之后，我又對(duì)客戶干系人進(jìn)行了分析，這樣，就能保證正式調(diào)研需求時(shí)，能夠選擇一些典型的客戶代表進(jìn)行需求調(diào)研。剛開始沒有 經(jīng)驗(yàn)，參與人員太多，提供的信息過于零散，減慢了收集需求的進(jìn)度。后來我們制定了現(xiàn)場(chǎng)訪談?dòng)?jì)劃，一次討論不超過10人。效果就好多了。通過和客戶的有效溝 通，獲取了大量的信息。

　　我發(fā)現(xiàn)，跟客戶交流時(shí)，提的問題最好是開放式的，比如 “是否確認(rèn)進(jìn)度檢查確認(rèn)方式”比“如何確認(rèn)進(jìn)度檢查確認(rèn)方式”可以獲得更多的信息。“項(xiàng)目計(jì)劃編制完成后，是否征求下級(jí)部門意見，如果下級(jí)部門不接受上級(jí) 部門分配的計(jì)劃，如何協(xié)調(diào)和處理?”這樣一個(gè)問題就可以了解客戶的計(jì)劃批準(zhǔn)和協(xié)商過程?，F(xiàn)場(chǎng)調(diào)研的工作很順利，共去了3次。

　　除此之外，我們還參觀了用戶的工作流程，觀察用戶的操作。 初步的需求信息得到以后，要對(duì)需求進(jìn)行分析。需求分析有很多方法，“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇?#8221;，總之，是要對(duì)得到的信息進(jìn)行處 理，提取這些信息間潛在的邏輯關(guān)系，分成不同的類別，這樣才能充分理解它們。

　　這就要求項(xiàng)目經(jīng)理不僅要盡可能記錄客戶信息，同時(shí)還要做一定的整理，否則，所有的討論只剩下一個(gè)模糊的印象，需求仍然是一件遙遠(yuǎn)的事情。只有進(jìn) 行深入收集和分析，才可以消除任何沖突或不一致性。 信息量越大，對(duì)準(zhǔn)確理解客戶的需求越有幫助，但同時(shí)，對(duì)需求的分析也就越難。

　　對(duì)于軟件項(xiàng)目，我認(rèn)為這可能是最困難、最關(guān)鍵、最需要交流的工作。因?yàn)檐浖皇怯布?，不是主板，顯示卡之類看得到摸得著的東西，軟件是思想，是 理念，是規(guī)則，是對(duì)真實(shí)世界的抽象。軟件項(xiàng)目的交付物是有形的，可又不同于其他行業(yè)，比如汽車的構(gòu)造是固定的，其組成部分是不變的。而一個(gè)軟件系統(tǒng)的模塊 劃分則可以有多種方法，多種結(jié)構(gòu)。這個(gè)特征導(dǎo)致對(duì)軟件項(xiàng)目經(jīng)理的抽象思維能力要求很高，要求要有較強(qiáng)的邏輯性。否則，就有可能表現(xiàn)為缺少全局概念，對(duì)項(xiàng)目 整體的范圍和業(yè)務(wù)系統(tǒng)把握不夠，在項(xiàng)目過程中被客戶牽著鼻子走，今天客戶說要個(gè)什么功能，就添加個(gè)什么，明天要修改個(gè)什么，就跟著修改什么，被動(dòng)至極。 將客戶信息結(jié)構(gòu)化，編寫成需求文檔。這是需求定義的工作。公司的《產(chǎn)品需求規(guī)格說明書》的主要內(nèi)容包括：“ 產(chǎn)品介紹;描述用戶群體的特征;定義產(chǎn)品的范圍; 闡述產(chǎn)品應(yīng)當(dāng)遵循的標(biāo)準(zhǔn)或規(guī)范;定義產(chǎn)品中的角色;定義產(chǎn)品的功能性需求;定義產(chǎn)品的非功能性需求，如用戶界面、軟硬件環(huán)境、質(zhì)量等需求;”僅有這份需求 文檔還不夠，我上現(xiàn)場(chǎng)調(diào)研時(shí)帶了個(gè)美工，將我們和客戶溝通好的軟件部分用圖形界面UI畫了出來。 需求定義是需求獲取中最“痛苦”的一件事情，為了盡量避免日后的扯皮，我們力圖使每個(gè)需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰， 則應(yīng)補(bǔ)充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，追究“是什么”和“為什么”的目的是獲得正確、 清楚的需求。對(duì)需求定義的標(biāo)準(zhǔn)大致如下： 需求存在二義性嗎?2 需求文檔的上下文有矛盾嗎?2 需求完備嗎?2 需求是必要的嗎?2 需求可實(shí)現(xiàn)嗎?2 需求可驗(yàn)證嗎?2 需求的優(yōu)先級(jí)確定了嗎?2

　　2、 需求確認(rèn) 需求確認(rèn)是指開發(fā)方和客戶共同對(duì)需求文檔進(jìn)行評(píng)審，雙方對(duì)需求達(dá)成共識(shí)后作出書面承諾，使需求文檔具有商業(yè)合同效果。 在需求調(diào)研的過程中，我發(fā)現(xiàn)對(duì)項(xiàng)目范圍的定義和當(dāng)初了解的存在誤差，這也是很正常的，因?yàn)槲春炗喓贤埃l也不能做很深入的調(diào)研，只能了解個(gè)大概要求。但 我們的原則是不輕易更改工作范圍，只是在原來的框架內(nèi)做一些小的調(diào)整。 而且每次和客戶討論之后，我們都寫一份會(huì)議紀(jì)要，請(qǐng)客戶簽字確認(rèn)。但即便如此，對(duì)需求的確認(rèn)也是一件很讓人頭痛的事情。如何劃定邊界?做到什么程度就可以 了?因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求，我們都盡量請(qǐng)客戶參與討論并更正。 需求評(píng)審會(huì)議非常重要，但是以前幾個(gè)項(xiàng)目的評(píng)審會(huì)都開得不很理想，大家事先不認(rèn)真閱讀文檔，會(huì)上亂哄哄的，你說一句，我問一句，往往花費(fèi)了很多時(shí)間，卻啥 結(jié)論也沒有。這一次，我吸取了教訓(xùn)，組織了一個(gè)非常正規(guī)的需求評(píng)審會(huì)議，將部門領(lǐng)導(dǎo)、公司的業(yè)務(wù)專家、技術(shù)骨干都請(qǐng)來當(dāng)評(píng)審人員。并自行設(shè)計(jì)了《評(píng)審準(zhǔn)備 表》和《評(píng)審記錄表》。會(huì)前兩天提前發(fā)了老撾項(xiàng)目的需求文檔《老撾TAIS項(xiàng)目方案建議書》、《老撾TAIS項(xiàng)目調(diào)研報(bào)告》，發(fā)放了《評(píng)審準(zhǔn)備表》，讓大 家提前將問題記錄在評(píng)審準(zhǔn)備表中，并反饋給我，我一直等到反饋意見收集的差不多了，才召開評(píng)審會(huì)。評(píng)審會(huì)開的很成功，效率很高。我讓人整理了評(píng)審發(fā)現(xiàn)的問 題，放在了評(píng)審記錄表中，方便下去追蹤。

　　3、 需求變更控制 需求變更控制是指依據(jù)“變更申請(qǐng)-審批-更改-重新確認(rèn)”的流程處理需求的變更，確保需求的變更不會(huì)失去控制而導(dǎo)致項(xiàng)目發(fā)生混亂。

　　需求變更難以避免，重要的是不能沒有章法得變，要遵循一個(gè)標(biāo)準(zhǔn)的變更控制程序，使得變化有序起來。 如果不進(jìn)行變更控制，那么，項(xiàng)目就不能得到及時(shí)的警告，常常會(huì)因?yàn)檫M(jìn)度超期、預(yù)算超支而陷入泥潭，成為“爛尾”工程。但是變更實(shí)在太頻繁，如果每次變更都 走變更流程，也會(huì)大大影響項(xiàng)目進(jìn)展。按照變更控制流程，需要對(duì)變更做影響分析等等。

　　既然變更在所難免，不可能只要有變更就執(zhí)行嚴(yán)格的變更控制程序，這個(gè)過程也是有成本的，所以，和項(xiàng)目組成員討論的結(jié)果，只有重大變更時(shí)，才執(zhí)行變更控制程序。比如影響了項(xiàng)目里程碑的達(dá)到，工作量超出了原先估計(jì)的30%等等。

　　這樣一來，既保證了變更的有序性，又保證了項(xiàng)目進(jìn)展。 除此之外，我還對(duì)需求的穩(wěn)定度做了一個(gè)度量，度量了原始需求的個(gè)數(shù)，增加、刪除、更改的需求個(gè)數(shù);并分散在項(xiàng)目各個(gè)階段，如需求分析、概要設(shè)計(jì)、詳細(xì)設(shè) 計(jì)、編碼階段、測(cè)試階段等等的需求數(shù)，并將每次需求變更的提出人、變更原因，是否走了正式的變更流程都記錄了下來。一來是為以后的項(xiàng)目做參考，二來跟客戶 溝通時(shí)也有話說。不至于拿不出令人說服的事實(shí)和根據(jù)來。

　　比如這個(gè)項(xiàng)目，初始的軟件需求共有142個(gè)，中間增加了21個(gè)，刪除了6個(gè)，更改了34個(gè)?？傮w需求穩(wěn)定度在30%左右，對(duì)于一個(gè)軟件項(xiàng)目來 說，就很不錯(cuò)了。 老撾項(xiàng)目于2011年12月底結(jié)束，項(xiàng)目獲得了老撾海關(guān)的好評(píng),目前系統(tǒng)運(yùn)行正常，系統(tǒng)已經(jīng)融入老撾海關(guān)工作流程，成為海關(guān)工作不可分割的一部分。公司也 收回了該項(xiàng)目所有尾款，實(shí)現(xiàn)了公司的價(jià)值。

　　在此項(xiàng)目中，我們做到了一下幾點(diǎn)：盡早開始需求調(diào)研，清晰進(jìn)行需求定義，隨時(shí)和客戶進(jìn)行溝通，及時(shí)記錄需求變更，統(tǒng)計(jì)需求變更的影響和工作量。 因此，項(xiàng)目進(jìn)行得很成功，期間克服了很多困難，比如人手緊張，客戶方接口人變動(dòng)等等。但因?yàn)楣ぷ鞣秶鷽]有什么改變，需求一直在掌控之中，項(xiàng)目一直按計(jì)劃執(zhí)行和完成。

文章來源：項(xiàng)目管理者聯(lián)盟論壇

http://www.mypm.net/bbs/article.asp?titleid=215917&ntypeid=24