A的做法是不可取的。

    在案例中，老王的初衷是好的，提醒小項(xiàng)通過需求管理降低項(xiàng)目拖期的風(fēng)險(xiǎn)，小項(xiàng)在對(duì)待李經(jīng)理提出的變更請(qǐng)求時(shí)也堅(jiān)持了變更管理規(guī)范（雖然他拒絕變更的閉鎖態(tài)度并不可?。?/SPAN>

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

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

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

    管理已確定的需求

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

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

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

    管理變更的請(qǐng)求

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

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

    管理用戶的需求

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

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

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

    最后，強(qiáng)調(diào)需求管理的跟進(jìn)

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

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