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