需求管理和變更控制的經驗

申請免費試用、咨詢電話：400-8352-114

　　軟件工程里的許多問題，諸如缺陷及資源運用不當，都是源于需求的不確定。在90年代，我曾在美國一個擁有數(shù)千員工的公司里從事大型軟件開發(fā)工作。該軟件主要是賣給汽車修復廠用的，它可估算出修復汽車的零件及勞力兩項費用，甚至還可以找到提供新零件及舊零件的廠家。軟件的的復雜度相當?shù)馗?，要界定什么樣的界面和功能是最適合市場的著實不易。所以，需求一變再變。在聊天時有個同事戲稱：“需求變更乃萬惡之源!”其他的人紛紛響應。當時，所有的需求都是寫在Word文檔里的，那些文檔不是放在一個共享的服務器里，就是交由負責編寫程序的人員管理。雖然沒用什么管理平臺及工具，但在團隊成員的配合和默契下，一切事情都有序地在進展著。項目管理者聯(lián)盟

　　但有一天產品經理換了個新的，一切事情似乎就全改變了。新的產品經理原是某汽車修復廠的經理，他對修汽車及車廠管理有不少的經驗，但對軟件的開發(fā)是很不懂的。很快地下列問題出現(xiàn)了：PgMp.mypm.net

　　(一)需求描述不清楚，導致開發(fā)任務的時間估算誤差可到100%，甚至200%;項目管理論壇

　　(二)優(yōu)先及全由產品經理決定，有時不太重要的任務先做了，重要的反倒后做;

　　(三)需求變更一再發(fā)生，并且當某需求變更了，它的連鎖反應會沖擊其他的部分，許多缺陷因此產生了。training.mypm.net

　　我們幾個資深人員分析整個過程，發(fā)現(xiàn)造成問題的原因是這樣的：項目管理者聯(lián)盟

　　(一)我們的現(xiàn)有需求文檔管理太亂，通常是找不到所要的版本。就算是找到要的文檔，常常也沒法找到要的那段內容。bbs.mypm.net

　　(二)可判斷任務優(yōu)先級的因素頗多，可以是在商業(yè)層面或技術層面，每人的視角不同，公說公有理，婆說婆有理。blog.mypm.net

　　(三)需求文檔、代碼、測試用例及其他的工件(artifacts)之間應是相關聯(lián)的，但在系統(tǒng)中我們無法從其中任一個工件找到其他的工件。項目管理者聯(lián)盟

　　由于文檔不全，這位新的產品經理很難在短時間內對整個系統(tǒng)有個概括性的了解。當他和資深人員溝通產品設計理念及歷史緣由時，資深人員也沒能明確地回答他的問題，這導致需求設計不完善，優(yōu)先級也有誤。找到原因后，我們想既然需求變更這一頭兇猛野獸是殺不死的，那我們所能做的大概也就是將這獸關在籠子里，使它溫馴點。 為解決這問題，我們建立了以下的體制。項目管理者聯(lián)盟

　　(一)細化需求的時間估算 – 我們將需求分解到程序員能清楚估算出完成時間的小單位，原則上每單位是可以讓一個程序員及一個測試人員在二至十天內做完，而且每個單位都有個編號。bbs.mypm.net

　　(二)使用版本控制系統(tǒng)管理需求文檔 – 所有需求文檔全保存在一中樞版本控制系統(tǒng)里。項目管理者聯(lián)盟

　　(三)將需求分組并設優(yōu)先級 – 所有的需求單位按照不同的版本區(qū)分開來，每個需求單位都有個優(yōu)先級。

       (四)建立工件之間的關聯(lián)性 – 將程序及測試用例與相對應的需求單位連接上，明確地寫上需求編號。training.mypm.net

　　(五)建立評審團隊 – 當需求產生或變更時，產品經理及干系人要一起評審，通過后才做更改。項目管理論壇