CMM 1.1版本中第一個KPA（關(guān)鍵過程域）就是需求管理。雖然在CMM2級的標(biāo)準文本中對需求管理的論述篇幅最少，但它卻是最容易讓開發(fā)人員和項目經(jīng)理提出疑問的一個KPA。如何進行有效的需求管理？筆者將需求管理的基本原則與方法總結(jié)為以下幾點：
● 必須與需求工程的其它活動緊密整合
　　談需求管理一定不能脫離需求工程。從完整意義上講，需求工程包括了需求獲取、需求分析、需求描述、需求驗證、需求管理。狹義上，需求管理關(guān)心的是需求管理過程的建立，在企業(yè)或項目組中需要有一套規(guī)范的需求管理過程。而實際上從項目經(jīng)理的角度上看，可能還有50%甚至更多的精力是用于關(guān)注結(jié)果的，所以對需求內(nèi)容的管理與對需求形式的管理是密不可分的。
● 需求必須是文檔化的、正確的、最新的、可管理的、可理解的
　　需求必須有文檔來記錄，該文檔必須是正確的，是經(jīng)過驗證的，是在受控的狀態(tài)下變更的。而很多開發(fā)人員往往會問：“簡單的系統(tǒng)就不用寫需求了吧？”其實簡單的系統(tǒng)未必簡單，只有想清楚、寫清楚、說清楚才說明已經(jīng)真正把需求整理清楚了。有一次，筆者安排2名開發(fā)人員編寫一個簡單的單據(jù)錄入模塊。由于這兩名開發(fā)人員以前均做過類似的系統(tǒng)，所以筆者僅給出了數(shù)據(jù)庫的設(shè)計，并簡單講了一下模塊的需求。然而，當(dāng)系統(tǒng)交付時，才發(fā)現(xiàn)與想象中的系統(tǒng)差距非常大，很多需求在提出者看來是理所當(dāng)然的，卻被開發(fā)人員全部忽略了。
● 只要需求變化了，需求變更的影響就必須被評估
　　無論需求變化的程度如何，只要需求變化了就必須進行評估，這是基本的原則。此外，在一個項目組中必須明確定義一個需求管理員，由他負責(zé)整個項目的需求管理工作，確保在發(fā)生需求變更時，受影響的產(chǎn)品能得到修改并與需求的變更保持一致，受影響的其它組也必須與客戶協(xié)商一致。
● 需求必須分優(yōu)先級 需求的優(yōu)先級可能比需求本身更加重要
　　在每一次產(chǎn)品開發(fā)過程中，都會遇到這樣一個問題：負責(zé)產(chǎn)品需求的領(lǐng)域?qū)＜伊_列了長長的功能列表，每個功能似乎都是不可或缺的，而當(dāng)排出進度表后，卻發(fā)現(xiàn)工期是公司不能接受的，沒辦法，必須裁剪需求。沒有需求就不會有產(chǎn)品，而沒有產(chǎn)品就沒有利潤。如果需求過多，反而可能是陷阱——只有投入，沒有產(chǎn)出。一個好的項目需求，必須有需求的優(yōu)先級，便于進行項目的整體平衡。
● 需求一定要分類管理
　　在做工程項目的時候一定要將需求分出層次，不同層次的需求側(cè)重點是不一樣的，描述的方式是不同的，管理的方式也是不同的。比如說，在企業(yè)里高層領(lǐng)導(dǎo)提出來的是目標(biāo)性需求，中層管理人員提出來的是具體的業(yè)務(wù)流程的需求，而作業(yè)人員提出來的是更側(cè)重于操作性的需求。對于目標(biāo)性的需求可能采用簡短的幾句話就可以描述清楚，但這是項目的決策性需求，需要很穩(wěn)定，不能輕易更改，在確定的時候需要慎之又慎

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html