需求變更，產品經理的良心也會痛！
引言：在項目執行過程中，產品經理與後續的合作團隊，包括設計、開發、測試等相關人員最尖銳突出的矛盾，就是需求變更，這是產品經理最經常被詬病的地方。頻繁的需求變更，對產品、項目進度和團隊積極性都有非常大的危害。產品經理一定要不遺余力避免需求變更的情況。
本文選自《爆款是怎樣煉成的：產品經理晉級寶典》。
作為產品經理，我們一定要理解開發團隊及其他團隊成員為什麽視需求變更為大敵。事實上，需求變更對整個項目都非常有害。
需求有變更，就意味著設計、開發團隊的工作有浪費。這首先是資源和時間的浪費。
這會導致團隊成員有抵觸情緒，對產品經理及需求產生了不確定感，產品經理的威信下降。嚴重的還會導致團隊成員懈怠工作，因為誰知道什麽時候這個需求還會變更？也許就不用做了呢？
打亂版本進度，除影響發版時間之外，還會打亂團隊的工作節奏。原本運轉得很好的團隊，如果頻繁發生需求變更，很容易打亂項目節奏，使人無所適從，因為原本計劃的時間點已經由於需求變更不可能按計劃實現。
臨時發生需求變更，容易導致新的需求考慮得更加不周全，項目的風險、產品質量下降的風險都會加大，嚴重的還會導致產品偏離原本的產品定位或想法。
頻繁的需求變更，對產品、項目進度和團隊積極性都有非常大的危害。產品經理一定要不遺余力避免需求變更的情況。下面來看看需求變更產生的主要矛盾以及如何應對。
（1）對需求考慮不周全。
比如產品經理小明設計用戶註冊流程，方案是用戶需要填寫手機號才能順利註冊。這個方案已經由設計人員給出效果圖和切圖，且進入了開發階段。那麽，在這個過程中，小明從公司內部的其他同類產品中了解到，用戶對手機號非常敏感，如果手機號是註冊時的必填信息，則很容易造成在註冊流程中用戶的流失。於是，小明只好修改產品方案，將填寫手機號一項改成選填，增加填寫常用郵箱作為註冊用戶的唯一標識。這就是典型的在需求方案設計階段，沒有全面考量方案的例子。當然，這與小明的經驗也有關系，一般新人難免在設計方案時對一些情況不夠敏感，會有疏忽和考慮不全的情況。這需要產品經理高標準要求自己，從各種角度審視、考量自己的方案，盡全力考慮周全，那麽就會在相當大的程度上避免需求變更，並且本人也會有所收獲、提升能力。
（2）由於實現難度而修改需求。
這種情況往往發生在設計人員已經給出了設計圖和切圖，開發人員開始開發，在某一個地方遇到了實現難題，比如按照原本的需求方案，可能有性能問題，或者開發難度太大，工作量比預期的大很多，等等。這時候，只好用一個妥協的產品方案來替代原本的需求。於是，設計人員需要重新作圖，開發人員也有部分工作需要調整。有的同學可能會說，這種情況可不能賴產品經理了吧？是開發人員實現不了導致推倒重來的。這裏要特別指出，如果你想成為一名優秀的產品經理，千萬不要有這種思考習慣。項目中出現的任何問題，都有產品經理的責任。那麽，這種情況要如何避免呢？那就是盡早地邀請開發人員介入，在需求方案還未敲定時，甚至在需求發起和討論時就邀請開發人員一起參與討論，即使開發人員對產品方案不能給出建議，至少也可以了解需求的來源，並且及時指出一些技術實現的難點。這種實現風險大、成本高的地方發現和提出得越早，越能保障產品後續環節的順暢進行。需求變更發生得越晚，新的需求方案輸出得就越倉促，考慮得就越不周全，對產品和項目都有很大危害。風險提出得越早，除可以避免團隊成員工作量的浪費之外，還可以讓大家對需求變更考慮得更周全。所以，在這裏產品經理要註意，讓開發人員盡早了解和知道接下來要做什麽需求，涉及哪些技術難點，這既是必需的，也是應該的。
（3）在設計圖出來之後，或者開發原型出來以後，甚至在測試階段，發現之前的需求方案不合理。
這種情況一般是不應該發生的，產品經理的水平越高，發生這種情況的概率也會越低。但是人不可能完全不犯錯，或者說，在看到真正的效果之前，甚至試用原型之前，有些交互體驗的細節問題確實難以發現。這也是產品經理需要修煉自身的地方，平時應該多試用各種產品，體驗各種交互和頁面設計，這樣才能在設計產品方案時不是單純地拍腦袋，而是在有真正的操作體驗的基礎上去設計。但是也要說明一點，這種情況下的需求變更，不應該是非常重大的變更，一般都是交互體驗或者頁面內視覺邏輯的微調整。產品流程或產品邏輯的問題，應該在視覺效果圖輸出之前就能夠被發現，而不是到視覺效果圖或者產品原型階段才能發現。
（4）還有一種非常無奈但是常見的情況，即老板提出的需求變更，或者真的由於產品方向改變而出現的需求變更。
這種情況下，產品經理也並非完全沒有責任。這時產品經理要思考，為什麽老板在已經進入設計和開發的階段才提出需求變更？是否因為老板之前並沒有能夠充分了解需求？這可能是因為老板太忙了，沒有關註到這個項目，那麽其實產品經理可以更主動積極地讓老板了解產品項目的進度、整個需求的思考過程和最終方案。這樣，如果老板有其他想法或不同意見，即可及早提出。
因此我們看到，避免需求變更的主要思想就是，讓信息在團隊內部，產品與產品之間， 團隊與老板之間，進行充分的交流和溝通，避免信息不對稱或不同步的情況，在信息充分同步的情況下，才能更早地暴露問題，提前修改需求方案，不浪費設計和開發等資源。
沒有需求變更的團隊是非常理想的，但是當理想照進現實，我們發現，事實上很少有需求不變更的情況。那麽，當需求變更不可避免地發生了，該怎麽處理，才能將危害降到最小呢？
其實，需求變更流程與產品的一般流程是一致的，首先是產品經理重新思考變更的需求， 全面考慮後輸出新的需求方案，同時並行的是充分與設計、開發、測試等團隊成員溝通，讓大家了解需求為什麽要變更，如何變更，以及修改後的方案會是什麽樣子，等等。在團隊成員對變更後的需求都認可了之後，就要再次進入設計、開發、測試的階段。在整個過程中， 產品經理同時要關註的是需求變更對整個產品版本進度的影響，一般需要設計、開發、測試人員重新評估工作量和提測時間，產品經理需要了解該變更是否會影響產品最終的發布時間， 如果確實有影響，無法通過協調其他時間來消化，那麽要及時告知更大範圍的團隊成員。比如需求變更只涉及一個功能的開發和測試，但當這個需求變更會影響整個版本的進度時，就需要讓整個產品版本涉及的所有開發、測試等人員知道版本發布計劃的變更及原因。
由於需求變更一般是產品經理發起的，而這是相當不討好的事，所以產品經理的壓力其實非常大。最後再談兩點，讓產品經理適當減輕一點壓力，避免因此受到傷害。當然前提是產品經理要修煉自己，盡量避免發生需求變更的情況，在此基礎上，可以用如下兩個方法來適當地調侃、保護自己。
（1）開發人員能保證不用修改Bug，那麽產品經理也可以保證不發生需求變更。
修改Bug 其實就是開發人員不能一次性將產品做到完美的真實例子，其實這個道理在任何人身上都適用，只是開發人員的Bug 並不那麽容易被發現，而產品經理的“Bug”，很多情況下是可以提前避免的。所以，一定要註意這句話說出來的場合和語氣（一般要用調侃的語氣）。雖然道理如此，但這並不是產品經理的擋箭牌。在說這句話之前，一定要真誠地向團隊成員道歉，尤其是受到需求變更影響的成員，畢竟需求變更的責任更多地在產品經理。但是也可以用這句話調侃下，讓大家互相理解，都是迫不得已。
（2）是Bug還是需求變更？
善良的產品新人會說，這個問題需要去深究嗎？是的，一般情況下，尤其是小團隊，是不需要深究的，但是，當團隊比較大，或者需求變更導致的影響比較大的時候，搞清楚問題出現的原因是Bug還是需求變更，對未來避免發生類似問題是有益的。如何搞清楚呢？這就需要查看產品需求文檔。
曾經有產品新人問，寫需求文檔有沒有意義？如果它只是為了備案和存檔記錄，那麽對於創業階段的小團隊，由於產品方向還在不斷地變化，還在快速嘗試中，備案和記錄好像並沒有那麽必要和緊急。其實需求文檔的重要意義在於可以前後印證，了解這一類有利於鞭策產品經理提升自己完整考慮需求的能力及寫需求文檔的能力。比如開發人員說：“這個Bug不是Bug，是你的需求，如果你現在要變成這樣，那麽你就要說明是需求變更。”這時，你能夠悠然地打開需求文檔，指出某一條，上面明確寫明了需求，是開發人員沒有正確實現。不要以為這種情況很罕見。是Bug還是需求變更，關乎聲譽甚至績效，是一個值得去明確的問題。對於產品經理來說，如果是早就想到了的需求邏輯點，只是因為在需求文檔中漏寫或沒有明確表達出來，導致開發人員認為需求文檔裏沒有寫明而在開發過程中也漏寫了邏輯從而產生問題，這種“需求變更”確實不能算Bug，責任就在於產品經理。
所以，如果你真的在需求文檔中明確表達清楚了，是開發人員沒有按照需求實現，那就是Bug，不能算作需求變更，這是對產品經理聲譽的保護。但如果是因為你的需求文檔寫得不夠嚴謹而造成“需求變更”，那麽就只有吃下黃連之後繼續修煉了。
本文選自《爆款是怎樣煉成的：產品經理晉級寶典》，點此鏈接可在博文視點官網查看此書。
想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關註。
本文出自 “博文視點官方博客” 博客，請務必保留此出處http://bvbroadview.blog.51cto.com/3227029/1924810
需求變更，產品經理的良心也會痛！