就項目而言，通常情況下，項目經理和團隊成員將各項計劃落實，開始執(zhí)行后，每個變動都會牽一發(fā)而動全身。

　　與此同時，由于項目本身具有不確定性的特點，項目的需求變更更是在項目管理過程中被談論最多的。 由于整個閉環(huán)鏈條上的每個角色對項目輸出的成果都是不可逆的，一旦決策，項目實施就會出現相應的后果，尤其是到了項目實施的中后期，需求變更所帶來的影響將顯著提高。

　　與業(yè)務確定需求

　　當需求文檔完成審查之后，即可交付給業(yè)務負責人做確認。為了加速業(yè)務負責人確認需求文檔的時間，可以邀請業(yè)務負責人參加需求評審會，或者講述一遍業(yè)務需求，然后再讓業(yè)務負責人線下確認，如果有修改意見，可約定郵件或者備注形式反饋，同時要跟對方說清楚確認完成時間。

　　羅列詳細任務需要

　　需求類別和模板確定之后，就要分配給項目相關負責人去撰寫需求。對中大型項目來說，撰寫需求說明書的人應該有多個，所以需要切分工作任務。

　　切分的原則是：每個任務盡可能獨立，任務的安排盡可能并行。每個任務必須要確定完成時間，如果時間不滿足項目進度，需調配其它人力資源進行協助。有些項目比較特殊，可能現有項目成員的專業(yè)能力無法覆蓋，此時需要引入外部專家或者將這部分任務外包出去。

　　為了把控需求收集的進度，需求撰寫計劃中要安排幾個檢查點。

　　舉個例子，假如需求撰寫的排期是1個月，那么就可以設置3個檢查點。

　　第一個檢查點為第一周結束。

　　第二個檢查點為第三周結束。

　　第三個檢查點為第四周結束前2天。

　　每到一個檢查點，各個需求撰寫人需將成果匯總到項目經理手里做review，根據review的意見或建議迅速調整或整改。

　　從四要素思考處理方案

　　如果團隊決定接受這個需求，項目經理接下來就要看團隊怎么處理這個需求了。

　　項目經理可以從項目管理四要素出發(fā)，看下能改變哪一個要素：

　　是降低系統的質量要求?——比如留些bug以后處理

　　是改變項目的交付范圍?—— 比如多了一個功能進來總得砍一個出去

　　是延長項目的交付時間?

　　還是改變實現功能的方式?

　　給出合理的需求處理解決方案，是項目經理綜合能力的體現。

　　另外，別忘了一件重要的事情，就是把變更的后續(xù)跟進方案通知到整個團隊，并且存檔變更紀錄。

　　經常遇到需求小范圍討論完就改掉的情況，但是測試人員并沒有通知到位，導致上線后才發(fā)現問題。項目經理需要有機制讓團隊避免這種情況。