為這可能是最困難、最關(guān)鍵、最需要交流的工作。因為軟件不是硬件，不是主板，顯示卡之類看得到摸得著的東西，軟件是思想，是理念，是規(guī)則，是對真實世界的抽象。軟件項目的交付物是有形的，可又不同于其他行業(yè)，比如汽車的構(gòu)造是固定的，其組成部分是不變的。而一個軟件系統(tǒng)的模塊劃分則可以有多種方法，多種結(jié)構(gòu)。
這個特征導(dǎo)致對軟件項目經(jīng)理的抽象思維能力要求很高，要求要有較強的邏輯性。否則，就有可能表現(xiàn)為缺少全局概念，對項目整體的范圍和業(yè)務(wù)系統(tǒ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)場調(diào)研時帶了個美工，將我們和客戶溝通好的軟件部分用圖形界面UI畫了出來。
需求定義是需求獲取中最“痛苦”的一件事情，為了盡量避免日后的扯皮，我們力圖使每個需求都應(yīng)當(dāng)用陳述句說明“是什么”，如果“是什么”的內(nèi)涵不夠清晰，則應(yīng)補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當(dāng)然”的，那么應(yīng)當(dāng)解釋“為什么”，追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。對需求定義的標(biāo)準(zhǔn)大致如下：需求存在二義性嗎?2 需求文檔的上下文有矛盾嗎?2 需求完備嗎?2 需求是必要的嗎?2 需求可實現(xiàn)嗎?2需求可驗證嗎?2 需求的優(yōu)先級確定了嗎?2
2、需求確認
需求確認是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。 在需求調(diào)研的過程中，我發(fā)現(xiàn)對項目范圍的定義和當(dāng)初了解的存在誤差，這也是很正常的，因為未簽訂合同前，誰也不能做很深入的調(diào)研，只能了解個大概要求。但我們的原則是不輕易更改工作范圍，只是在原來的框架內(nèi)做一些小的調(diào)整。
而且每次和客戶討論之后，我們都寫一份會議紀(jì)要，請客戶簽字確認。但即便如此，對需求的確認也是一件很讓人頭痛的事情。如何劃定邊界?做到什么程度就可以了?因為只有提供需求的人才能確定是否真正獲取需求，我們都盡量請客戶參與討論并更正。需求評審會議非常重要，但是以前幾個項目的評審會都開得不很理想，大家事先不認真閱讀文檔，會上亂哄哄的，你說一句，我問一句，往往花費了很多時間，卻啥結(jié)論也沒有。
這一次，我吸取了教訓(xùn)，組織了一個非常正規(guī)的需求評審會議，將部門領(lǐng)導(dǎo)、公司的業(yè)務(wù)專家、技術(shù)骨干都請來當(dāng)評審人員。并自行設(shè)計了《評審準(zhǔn)備表》和《評審記錄表》。會前兩天提前發(fā)了老撾項目的需求文檔《老撾TAIS項目方案建議書》、《老撾TAIS項目調(diào)研報告》，發(fā)放了《評審準(zhǔn)備表》，讓大家提前將問題記錄在評審準(zhǔn)備表中，并反饋給我，我一直等到反饋意見收集的差不多了，才召開評審會。評審會開的很成功，效率很高。我讓人整理了評審發(fā)現(xiàn)的問題，放在了評審記錄表中，方便下去追蹤。
3、需求變更控制
需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認”的流程處理需求的變更，確保需求的變更不會失去控制而導(dǎo)致項目發(fā)生混亂。
需求變更難以避免，重要的是不能沒有章法得變，要遵循一個標(biāo)準(zhǔn)的變更控制程序，使得變化有序起來。如果不進行變更控制，那么，項目就不能得到及時的警告，常常會因為進度超期、預(yù)算超支而陷入泥潭，成為“爛尾”工程。但是變更