深入理解項目管理之需求

寬泛地講，需求來(lái)源于用戶(hù)的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說(shuō)明了產(chǎn)品“必須或應當”做什么。所以如果只有一些零碎的對話(huà)、資料或郵件，你就以為自己已經(jīng)掌握了需求，那是自欺欺人。需求是產(chǎn)品的根源，需求工作的優(yōu)劣對產(chǎn)品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。我們經(jīng)�？吹降氖牵喝藗儾⒉磺宄�究竟該做什么，但卻一直忙碌不停地開(kāi)發(fā)。
　　需求開(kāi)發(fā)與管理面臨最普遍的問(wèn)題是：用戶(hù)說(shuō)不清楚需求。
　　有些用戶(hù)真的不知道需求是什么，或者對需求只有朦朧的感覺(jué)，他當然說(shuō)不清楚需求。例如，早期的政府信息化項目用戶(hù)通常只有一個(gè)朦朧的信息化感覺(jué)而已，需求分析中會(huì )這樣寫(xiě)："總之，要實(shí)現那種能夠想到就能做到功能。"。如果開(kāi)發(fā)方的營(yíng)銷(xiāo)人員水平比較高，他能夠在用戶(hù)不清楚自己要什么的情況下引導用戶(hù)“消費”。
　　有些用戶(hù)雖然心里明白想要什么，但卻說(shuō)不清楚需求。 比如說(shuō)買(mǎi)鞋子。我們非常了解自已的腳，但很難用語(yǔ)言說(shuō)清楚腳的大小和形狀。通常拿鞋子去試，試穿時(shí)感覺(jué)到舒服才會(huì )買(mǎi)鞋。一些企業(yè)的信息化項目，每個(gè)子部門(mén)對自身的需要很清楚，但不知道如何從系統角度來(lái)要求。
　　因此，我們可以說(shuō)項目開(kāi)發(fā)最困難的部分也就是準確說(shuō)明開(kāi)發(fā)什么。最困難的概念性工作是編寫(xiě)出詳細的需求，包括所有面向用戶(hù)、面向機器和其它軟件系統的接口。此工作一旦做錯，將會(huì )給系統帶來(lái)極大的損害，并且以后對它修改也極為困難。為此，需求分析員絕不能以用戶(hù)說(shuō)不清楚需求為借口而草率地對待需求開(kāi)發(fā)工作，否則會(huì )連累整個(gè)開(kāi)發(fā)團隊的。
　　業(yè)內來(lái)看，一個(gè)成熟、成功的項目，通常它在前期需求、系統設計投入的工作量比例會(huì )大于30%。
　　1、需求開(kāi)發(fā) 與分析
　　需求開(kāi)發(fā)的目的是通過(guò)調查與分析，獲取用戶(hù)需求并定義產(chǎn)品需求。根據需求調查和需求分析的結果，進(jìn)一步定義準確無(wú)誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規格說(shuō)明書(shū)》。系統設計人員將依據《產(chǎn)品需求規格說(shuō)明書(shū)》開(kāi)展系統設計工作。一個(gè)良好的需求說(shuō)明書(shū)，應該有如下特征：
　　1.1 正確
　　需求規格說(shuō)明書(shū)應當正確地反映用戶(hù)的真實(shí)意圖，開(kāi)發(fā)者和用戶(hù)自己都不明白用戶(hù)究竟“想要什么”和“不要什么”。為確保需求是正確的，開(kāi)發(fā)方和用戶(hù)必須對《需求規格說(shuō)明書(shū)》進(jìn)行確認。
　　1.2 清楚
　　清楚的需求讓人易讀易懂，包括文檔的結構、段落等是否清晰。
　　1.3 無(wú)二義性
　　“無(wú)二義性” 是指每個(gè)需求只有唯一的含義。
　　1.4 一致
“一致”(Consistent)是指各個(gè)需求之間不會(huì )發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。
　　1.5 必要
　　開(kāi)發(fā)者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產(chǎn)品需求規格說(shuō)明書(shū)》中將那些“錦上添花”的需求設置為較低的優(yōu)先級。
　　1.6 完備
　　“完備”(Complete)是指《產(chǎn)品需求規格說(shuō)明書(shū)》中沒(méi)有遺漏一些必要的需求，比如是否覆蓋了所有的功能、性能、交叉、安全等需求。
　　1.7 可實(shí)現
　　《產(chǎn)品需求規格說(shuō)明書(shū)》中的各項需求對開(kāi)發(fā)方而言應當都是可實(shí)現的(Attainable)。
　　“可實(shí)現”意味著(zhù)在技術(shù)上是可行的，并且滿(mǎn)足時(shí)間、費用、質(zhì)量等約束。
　　1.8 可驗證
　　《產(chǎn)品需求規格說(shuō)明書(shū)》中的各項需求對用戶(hù)方而言應當都是可驗證的(Verifiable)。如果需求是不可驗證的，那么用戶(hù)就無(wú)法驗收軟件，可能會(huì )發(fā)生商業(yè)糾紛。
　　1.9 確定優(yōu)先級
　　需求的優(yōu)先級其實(shí)就是需求“輕重緩急”的分級表述，例如劃分為“高、中、低”三級。一般地，由用戶(hù)和開(kāi)發(fā)方共同確定需求的優(yōu)先級。
　　1.10 闡述“做什么”而不是“怎么做”
　　開(kāi)發(fā)人員常常身兼數職，可能把需求開(kāi)發(fā)、系統設計、編程等工作從頭做到尾。他們經(jīng)常在整理需求的時(shí)候習慣性將如何實(shí)現的信息涵蓋在需求中，導致需求可讀性、可驗證性無(wú)法保證。
　　2、需求管理過(guò)程域
需求管理的目的是在客戶(hù)與開(kāi)發(fā)方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。
　　需求確認是指開(kāi)發(fā)方和客戶(hù)共同對需求文檔進(jìn)行評審，雙方對需求達成共識后作出書(shū)面承諾，使需求文檔具有商業(yè)合同效果。
　　需求跟蹤是指通過(guò)比較需求文檔與后續工作成果之間的對應關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據需求文檔進(jìn)行開(kāi)發(fā)。
　　需求變更控制是指依據“變更申請-審批-更改-重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發(fā)生混亂。
　　2.1需求跟蹤
　　需求跟蹤的目的是建立與維護“需求-設計-編程-測試”之間的一致性，確保所有的工作成果符合用戶(hù)需求。需求跟蹤有兩種方式：
　　正向跟蹤。檢查《產(chǎn)品需求規格說(shuō)明書(shū)》中的每個(gè)需求是否都能在后繼工作成果中找到對應點(diǎn)。
　　逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在《產(chǎn)品需求規格說(shuō)明書(shū)》中找到出處。
　　正向跟蹤和逆向跟蹤合稱(chēng)為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣(即表格)。需求跟蹤矩陣保存了需求與后繼工作成果的對應關(guān)系。
　　我們就曾經(jīng)出現大家埋頭于開(kāi)發(fā)，最后才發(fā)現項目協(xié)議書(shū)中的一個(gè)小基本功能沒(méi)有開(kāi)發(fā)的事故。
　　2.2 變更管理
　　需求變更通常會(huì )對項目的進(jìn)度、人力資源、經(jīng)費產(chǎn)生很大的影響。
　　如果在項目開(kāi)發(fā)的初始階段，開(kāi)發(fā)人員和用戶(hù)沒(méi)有搞清楚需求或者搞錯了需求，到了項目開(kāi)發(fā)后期才將需求糾正過(guò)來(lái)，會(huì )導致產(chǎn)品的部分內容需要重新開(kāi)發(fā)。這是要堅決避免的。
　　如果由于市場(chǎng)變化而導致產(chǎn)品需求發(fā)生變更，開(kāi)發(fā)商大可不必為此煩惱，應當高興才對。倘若市場(chǎng)靜如死水，那么開(kāi)發(fā)商吃了“上一頓”就沒(méi)有“下一頓”。正因為市場(chǎng)在變化，才會(huì )產(chǎn)生更多商機，聰明的開(kāi)發(fā)商才會(huì )有活干，有錢(qián)賺。
　　其實(shí)需求變更并不可怕，可怕的是需求變更失去控制，導致項目混亂。所以需求變更控制是需求工程的重要活動(dòng)。如果需求變更帶來(lái)的好處大于壞處，那么允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。如果需求變更帶來(lái)的壞處大于好處，那么拒絕變更。
需求變更控制過(guò)程中最難辦的事情是莫過(guò)于“拒絕客戶(hù)提出的需求變更請求”。通常情況下開(kāi)發(fā)方是不敢得罪客戶(hù)的，但是無(wú)原則地退讓將使開(kāi)發(fā)小組陷入困境。解決這個(gè)問(wèn)題的一個(gè)辦法是事先建立規則：如開(kāi)發(fā)方與客戶(hù)方達成“事不過(guò)三”的約定，即允許客戶(hù)變更三次需求;如果客戶(hù)第四此變更需求，開(kāi)發(fā)方有權提請客戶(hù)補償開(kāi)發(fā)投入。
　　3、深入理解需求
　　需求的開(kāi)發(fā)和管理有一些規律或經(jīng)驗可以參考，核心是溝通確認、溝通控制。
　　3.1認清誰(shuí)才是"上帝"
　　我們說(shuō)客戶(hù)是上帝，是因為客戶(hù)的重要性，客戶(hù)占有決定性的地位。對于廣大不能清楚描述需求的客戶(hù)，項目開(kāi)發(fā)人員負有教育客戶(hù)的義務(wù)，需要引導客戶(hù)，讓他們說(shuō)出自己的心聲�？蛻�(hù)往往都是領(lǐng)域專(zhuān)家，對自己的工作有很深的認識，可是由于對軟硬件開(kāi)發(fā)的不了解，往往表達不清，甚至表達不出自己的需求。這時(shí)候，就是體現你的功力的時(shí)候了，象對待上帝一樣對待你的客戶(hù)。
　　3.2 耐心是首要的學(xué)理工科的人，一般在邏輯思維上會(huì )比較好，可是對于客戶(hù)來(lái)說(shuō)，可不一定是這樣。一些客戶(hù)在了解需求的時(shí)候，扯東扯西，含糊不清，只有耐心才能獲得真正的需求。耐心最后會(huì )仍會(huì )體現為溝通，只有耐心的溝通，你才能揭開(kāi)需求的重重面紗。人的行為總是會(huì )受到思想的指導，如果你解不開(kāi)客戶(hù)的心結，你就不可能了解他真正需要的。
　　3.3 參與是重要的
　　方法的一個(gè)重要實(shí)踐，就是提倡"現場(chǎng)客戶(hù)"(on-site customer)。也就是說(shuō)，客戶(hù)應該隨時(shí)和開(kāi)發(fā)人員在一起，隨時(shí)提供資料和做出決策。而這個(gè)客戶(hù)，也必須領(lǐng)域專(zhuān)家，而且能夠有權做出決策。非常的貼近客戶(hù)，甚至可以在做游戲的過(guò)程中完成卡片的填寫(xiě)，能帶來(lái)很強的客戶(hù)參與度。
　　4 擁抱變化
　　需求變化是開(kāi)發(fā)人員最討厭的一件事了�？墒�，就像我們常說(shuō)"哭不能解決問(wèn)題"一樣，討厭能解決問(wèn)題嗎?拒絕客戶(hù)的變更要求，要求客戶(hù)在需求規格說(shuō)明書(shū)上簽字。這些做法只能是適得其反。沒(méi)有任何正面的、積極的意義。需求變更要求我們的開(kāi)發(fā)工作要迭代式進(jìn)行，包括需求、設計、實(shí)現等階段。這樣才能將變更風(fēng)險減到最小。
　　5 測試
　　這里的測試指的是考核軟件項目是否成功的一個(gè)"執行性目標"。例如，開(kāi)發(fā)物流系統的目的是為了縮短產(chǎn)品周轉周期，降低庫存;開(kāi)發(fā)供應鏈系統是為了加強和供應商的聯(lián)系，降低庫存。這些和具體業(yè)務(wù)有關(guān)的指標都是可以通過(guò)細化，用多種分指標來(lái)度量的，所以是可以做到的。
　　我們把這種目標稱(chēng)為測試就是要提醒開(kāi)發(fā)人員，要把滿(mǎn)足這種目標當作最終的測試。
　　有了明確的需求，我們一定竭力做如下幾件事情：
　　什么(WHAT)：按順序列出達到目標所需完成的工作.( 資料來(lái)源：項目管理者聯(lián)盟)