為這可能是最困難、最關(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ù)算超支而陷入泥潭，成為“爛尾”工程。但是變更