做變更申請的評估，為了讓系統(tǒng)盡快上線，他只好來一個改一個，修改完成后再抽點時間填個《變更實施記錄表》了事。至于《需求說明書》也根本來不及更新，離系統(tǒng)實際的功能相差越來越遠(yuǎn)……

    經(jīng)理老王也沒閑著，他要頂住銷售經(jīng)理和老板的雙重壓力，拼命爭取給項目寬限些時日?？墒遣还茉趺磁Γ到y(tǒng)上線的日子依然遙遙無期。老王回過頭責(zé)備小項，怪他沒控制住需求，重蹈了過去的覆轍。小項也一肚子委屈，認(rèn)為責(zé)任應(yīng)歸咎于需求管理流程的虛有其表，根本“管”不住蔓延的需求。

    兩人各執(zhí)一詞，面對不斷拖后的工期，一籌莫展。

  “管”不住的需求管理

    老王和小項面臨的困境很多人似曾相識，也許細(xì)節(jié)不盡相同，但那種眼睜睜看著項目失控的無力感，相信不少人都深有體會。

    案例中的老王和小項事先已經(jīng)認(rèn)識到了需求蔓延的危害，并且采取了一定的預(yù)防措施，比如對需求庫的管理、對變更申請的評估、對變更處理的報告等。可是，為什么到最后卻還是一團(tuán)亂？為什么好好的流程擺在那兒卻沒人遵守？為什么項目的需求只能跟著業(yè)務(wù)部門跑？為什么看似嚴(yán)密的“需求管理”制度卻根本“管”不住需求？

    看看他們對待變更的態(tài)度是如果變化的，大概可以找到些原因。

嚴(yán)防 

    剛開始的時候，老王和小項對需求蔓延導(dǎo)致的延期風(fēng)險心有余悸，一致認(rèn)為這個項目應(yīng)當(dāng)加強需求管理，減少需求蔓延的風(fēng)險。

松懈 

    當(dāng)變更出現(xiàn)時，小項牢記當(dāng)初的承諾“不允許輕易變更”，可是他的堅持并沒有擋住業(yè)務(wù)部門的壓力，變更被接受了，規(guī)矩被破壞了，可當(dāng)時的情況還沒有變得太糟，隱忍之后也就慢慢習(xí)慣了。

縱容 

    當(dāng)變更不斷、無法控制時，小項干脆放棄了對需求的管理。反正銷售部架構(gòu)變了、流程變了、一切都變了，不滿足新需求系統(tǒng)根本無法交付，上了賊船的小項只能被變更牽著鼻子走，慢慢從習(xí)慣、到麻木、再到縱容，最后演變成一場災(zāi)難。

    說到底，需求蔓延的根本原因還是管理制度執(zhí)行不下去。小項說的對，那些規(guī)章制度根本“管”不住蔓延的需求。

    尤其是，當(dāng)我們被層出不窮的變更壓得喘不過氣，當(dāng)我們?yōu)榱斯?jié)省時間繞過了應(yīng)有的評審，當(dāng)我們因為一次的“捷徑”忘記了失敗的風(fēng)險，當(dāng)我們把需求管理弱化成機械的文檔填寫，當(dāng)我們面對變更麻木的自以為是，我們已經(jīng)失去了應(yīng)有的警惕，失去了防范風(fēng)險的機會，一套被“形式化”的需求管理規(guī)范，除了生成無用的事后文書之外，毫無用處。

    把需求“管”起來

    “管”不住需求的管理流程根本毫無作用，卻像一座高墻禁錮我們的洞察力，讓我們沉浸在“只要把報告補充完整就是做了需求管理”的虛假幻像中。

    面對高墻，我們不能依賴別人的救贖。就像小項不能指靠銷售部自愿放棄提出變更請求一樣，只有正確認(rèn)識需求管理的實質(zhì)、掌握需求管理的技巧、努力堅持下去，不被暫時的挫折和困境打倒，才能達(dá)到真正意義上的“管理”。

    首先，認(rèn)識需求管理的實質(zhì)

    需求是可以管理的，需求蔓延是可以控制的，只要我們采用正確的、恰當(dāng)?shù)墓芾矸椒?，它不會成為項目進(jìn)展的阻礙，哪怕有時候它看上去的確占用了大把的時間。

    需求管理包含兩方面的內(nèi)容。一是對已經(jīng)確定的需求進(jìn)行跟蹤和管理，確保每個需求點都被實現(xiàn)或者被關(guān)閉。二是對用戶提出的變更請求進(jìn)行評估、跟蹤和監(jiān)控，確保新的變更不會與現(xiàn)有需求沖突，如果有沖突，那么需要在更大的范圍內(nèi)評審，或者修改此前的需求，或者拒絕變更的請求。

    需求管理的目的是保證需求被正確的理解和實現(xiàn)，沒有遺漏，保證最終交付的產(chǎn)品符合用戶的要求。不管從哪個方面來理解，需求管理都絕不是寫幾篇文檔那么簡單，那種突擊式的補齊文檔應(yīng)付Q