IT行業中失敗項目的比例可以說明“項目管理”是很難做好的事情，項目失敗的原因千千萬，我認為需求管理、需求變更管理是個很重要的因素。恰恰PM的工作缺不了項目管理，更缺不了對於需求的管理，偶然的原因，和團隊分享了我對於項目進行中“需求變更”的理解和管理方法。忽然發現之前寫過很多產品思考和細節思考的東西，但從沒有整理出方法論，後續應該多整理下方法論。
我認為對需求變更這件事是需要無限關心的，它的目的在於兩點：
1，管理需求變更的過程，實際上是不斷明確項目目標的過程，是自我完善的過程。
2，需求變更對虛擬團隊的打擊是PM需要避免的，無論是對PM的信任度，還是對於自身的挫折感，都很重要。
我整理的需求變更循環如下：
1，需求質量
需求包含調研過程、溝通過程、文檔產出等內容，PM前期需要盡可能的想清楚、表達清楚，包括大局、節奏和細節。需求質量的高低能夠對後續的變更起到決定性的作用，雜亂無章、漏洞百出的需求必然會導致無盡的需求變更。但需求質量也並不是絕對的，要看項目，看開放方案，對於敏捷開發來說，質量要求也許70分就夠了，快速迭代才是硬道理。對於重大項目，也許要80分才能過各級的評審。但無論如何60分是必須的，需求達到一定質量才能立項進入開發階段，這也是一般情況下采取的項目評審方式。
2，團隊理解一致
PM團隊、項目虛擬團隊的溝通效果最重要，要明確每個人的理解一致。PM把自己的調研、設想、預期描述清楚是第一步，這也是PM的必須課。但更重要的是要明確每個人的理解是一致的。要知道很多時候不同的人對於同一句話，同一個描述段落，理解很有可能是不一致的，這必然會導致後續的發展不一致。因此團隊成員每一個人的理解是一致的這件事很重要，不光是為了給大家洗腦，更重要的是讓大家做同一件事。
3，越早發現問題越好
問題發現的越早，產生的破壞力越小，對項目進度的影響也越小。可行的方法有很多，隨時關注開發進度、進行每日例行站會都是好方法。PM的責任當然不是啟動開發後把所有的事情交由項目經理（或者開發負責人，或者什麼人）去管理，正確的方式應該是要不自己就是項目經理，要不自己也參與項目的管理工作，最低自己也得隨時關注項目的進度。
4，積極面對
發現問題後不能等待，要麼變更要麼放棄，必須做出選擇。事實上經常會遇到一些情況，讓我們很難去積極面對，比如資源緊張，比如時間緊張，比如麻煩太大，比如無法向老板交代，比如無法向同學們解釋，比如會讓同學們鄙視等等。但不作為永遠都是下下策，積極面對是解決問題的唯一出路，也是必須要使用的方式。
5，及時更新文檔
文檔雖然不是最重要的，但記錄變更非常重要。無論是對團隊成員來說，還是對自己來說，記錄變更內容都是非常重要的。每個人的記憶力都是有限的，每次評審都是沒有記錄的，每次郵件都是雜亂無章的，每次會議紀要都是不正式的。唯一正式、可靠的就是需求文檔，將變更內容及時更新不但是良好的工作習慣，也是對項目團隊負責人的表現，任何人這樣做都會獲得別人的尊重。
6，凍結時間點
需求太多、誘惑太多、我們每個人都是個完美主義者。無論是從用戶角度出發，還是從自己的完美癖好出發，還是從領導交差出發，好像都需要把事情做到極致。但極致是需要一步一步來的，為了避免項目延期、成員灰心喪氣，我們需要有個凍結需求的時間點。同事為了保護團隊和項目進度，要自我嚴格執行，任何時候都反過來想一想，我自己是不是已經成為了項目失敗的原因，想一想我的所作所為是不是已經是問題本身而不是解決問題的方法了。
7，必要的妥協
事無完美，快速迭代得永生。無論是技術代價還是人力代價，都是有閥值的，雖說技術沒有實現不了的想法，人力代價往往也不是問題，但時間代價是實實在在的。而且，世界上沒有一口吃成胖子的事情，也沒有萬事如意的情況。妥協是必要的甚至是每天都要面對的，妥協並不是放棄，而需要仔細的思考和規劃。也許之前考慮的就不成熟，也許後續可以更好的安排。
8，事後總結，才能進步，避免重蹈覆轍。
http://daxu.net/archives/1333.html