A的做法是不可取的。

    在案例中，老王的初衷是好的，提醒小項通過需求管理降低項目拖期的風險，小項在對待李經(jīng)理提出的變更請求時也堅持了變更管理規(guī)范（雖然他拒絕變更的閉鎖態(tài)度并不可取）。

    但也許銷售部經(jīng)理太強勢，也許是小項他們的管理規(guī)范不夠細致，總之正常的變更管理流程先是被老王“簡化”成一句話，而后又被小項進一步“演繹”成了空洞的文檔填寫，需求管理至此徹底失去了“管”住風險的機會。

    其次，掌握需求管理的技巧

    對需求管理，我們不但要正確認識其本質(zhì)，也要具備足夠的能力，掌握需求管理所需的能力和技巧，真正做到“管理”需求。

    管理已確定的需求

    一份通過評審并取得各方認可的《需求規(guī)格說明書》是需求管理的基礎，在此基礎上建立起的《需求庫》和《需求跟蹤矩陣》能夠幫助需求管理員對分析、設計、開發(fā)和測試階段，每個需求點被實現(xiàn)的情況進行跟蹤和管理，這是做好需求管理的基礎。

    《需求規(guī)格說明書》和《需求庫》是產(chǎn)品的設計基線，要進行嚴格的版本控制，不能隨意修改。在對其改動前，必須通過變更管理委員會的評審，以保證需求的穩(wěn)定性，防止需求蔓延的風險。

    案例中的小項編制了這些文檔，但是卻沒有給與足夠的重視，尤其是在變更頻繁、進度落后的壓力下，他選擇了罔顧QA小鄭的提醒，把這些當作純粹的文案工作來對待，忽視了產(chǎn)品基線對于穩(wěn)定需求的重要性，導致需求變更失控，需求說明書成了擺設。

    管理變更的請求

    沒有哪個項目的需求是不發(fā)生變化的，只是多少不同罷了，因此，如何管理變更就顯得更加重要。案例中，小項的項目其實是有變更管理流程的，只是沒有發(fā)揮應有的作用而已。

    一般來講，我們會通過一系列的表格和報告來實現(xiàn)變更的管理，比如《變更申求表》、《變更評審報告》、《變更實施記錄》、《變更請求處理報告》等，千萬不要把這些報告看作是僵化無用的文檔，它們實際上體現(xiàn)了組織對變更的管理方針，從變更的提出、評審、執(zhí)行、結(jié)果監(jiān)控到基線變更管理的全部過程，只有對每一步都認真執(zhí)行，才能實現(xiàn)變更的有序管理。

    管理用戶的需求

    在我們看來，用戶總是會提出各種奇怪的要求，并且總是猶豫不決，常常要求推翻之前的論斷從頭再來。對此不必太緊張，用戶的需求不是小怪獸，我們也無需變成奧特曼，只要掌握一定的規(guī)律和技巧，用戶的需求也是可以管理的。

    為了控制變更的數(shù)量和頻率，與各方干系人就項目的目標達成一致是十分必需的，通常情況下，用戶不斷增加需求是基于“這點改變不會影響項目進度”的認知提出的，如果讓用戶了解變更對進度的影響，對目標實現(xiàn)的影響，只要我們是據(jù)實以告，大多數(shù)情況下用戶是能夠理智對待的。

    對于案例中的小項來說，后期頻繁的需求變更主要是由于銷售部架構(gòu)調(diào)整和業(yè)務負責人更替造成的，屬于重大的意外情況，應當作為重大變更來處理。小項應該就此事與項目的各方干系人坐下來討論，必要時由老王出面協(xié)調(diào)，對有關項目工期、范圍和需求變動等關鍵問題重新評估并達成一致，制定出一分新的啟示可行的項目計劃。這樣既避免了無限制的延期，也不會被變更壓得喘不過氣來。

    最后，強調(diào)需求管理的跟進

    對需求管理，持續(xù)跟蹤是王道，無論進度壓力多大都不應該松懈，這樣才能達到“管理”需求的效果。三天打魚兩天曬網(wǎng)的做法，從來不是需求管理的那盤菜。

    需求跟蹤是一件艱難瑣碎的事，從《需求跟蹤矩陣》的表格設計就可見一斑，它幾乎涵蓋了軟件開發(fā)所有階段的需求點實現(xiàn)情況，除非該項需求通過變更評審后被關閉，否則必須從需求分析階段跟蹤到驗收測試階段，不能有任何遺漏。