需求變動，產品經理的良心也會痛！

引言：在項目執行過程當中，產品經理與後續的合做團隊，包括設計、開發、測試等相關人員最尖銳突出的矛盾，就是需求變動，這是產品經理最常常被詬病的地方。頻繁的需求變動，對產品、項目進度和團隊積極性都有很是大的危害。產品經理必定要竭盡全力避免需求變動的狀況。
本文選自《爆款是怎樣煉成的：產品經理晉級寶典》。

　　做爲產品經理，咱們必定要理解開發團隊及其餘團隊成員爲何視需求變動爲大敵。事實上，需求變動對整個項目都很是有害。

1. 需求有變動，就意味着設計、開發團隊的工做有浪費。這首先是資源和時間的浪費。

2. 這會致使團隊成員有抵觸情緒，對產品經理及需求產生了不肯定感，產品經理的威信降低。嚴重的還會致使團隊成員懈怠工做，由於誰知道何時這個需求還會變動？也許就不用作了呢？

3. 打亂版本進度，除影響發版時間以外，還會打亂團隊的工做節奏。本來運轉得很好的團隊，若是頻繁發生需求變動，很容易打亂項目節奏，令人無所適從，由於本來計劃的時間點已經因爲需求變動不可能按計劃實現。

4. 臨時發生需求變動，容易致使新的需求考慮得更加不周全，項目的風險、產品質量降低的風險都會加大，嚴重的還會致使產品偏離本來的產品定位或想法。

頻繁的需求變動，對產品、項目進度和團隊積極性都有很是大的危害。產品經理必定要竭盡全力避免需求變動的狀況。下面來看看需求變動產生的主要矛盾以及如何應對。

（1）對需求考慮不周全。

　　好比產品經理小明設計用戶註冊流程，方案是用戶須要填寫手機號才能順利註冊。這個方案已經由設計人員給出效果圖和切圖，且進入了開發階段。那麼，在這個過程當中，小明從公司內部的其餘同類產品中瞭解到，用戶對手機號很是敏感，若是手機號是註冊時的必填信息，則很容易形成在註冊流程中用戶的流失。因而，小明只好修改產品方案，將填寫手機號一項改爲選填，增長填寫經常使用郵箱做爲註冊用戶的惟一標識。這就是典型的在需求方案設計階段，沒有全面考量方案的例子。固然，這與小明的經驗也有關係，通常新人不免在設計方案時對一些狀況不夠敏感，會有疏忽和考慮不全的狀況。這須要產品經理高標準要求本身，從各類角度審視、考量本身的方案，盡全力考慮周全，那麼就會在至關大的程度上避免需求變動，而且本人也會有所收穫、提高能力。

（2）因爲實現難度而修改需求。

　　這種狀況每每發生在設計人員已經給出了設計圖和切圖，開發人員開始開發，在某一個地方遇到了實現難題，好比按照本來的需求方案，可能有性能問題，或者開發難度太大，工做量比預期的大不少，等等。這時候，只好用一個妥協的產品方案來替代本來的需求。因而，設計人員須要從新做圖，開發人員也有部分工做須要調整。有的同窗可能會說，這種狀況可不能賴產品經理了吧？是開發人員實現不了致使推倒重來的。這裏要特別指出，若是你想成爲一名優秀的產品經理，千萬不要有這種思考習慣。項目中出現的任何問題，都有產品經理的責任。那麼，這種狀況要如何避免呢？那就是儘早地邀請開發人員介入，在需求方案還未敲定時，甚至在需求發起和討論時就邀請開發人員一塊兒參與討論，即便開發人員對產品方案不能給出建議，至少也能夠了解需求的來源，而且及時指出一些技術實現的難點。這種實現風險大、成本高的地方發現和提出得越早，越能保障產品後續環節的順暢進行。需求變動發生得越晚，新的需求方案輸出得就越倉促，考慮得就越不周全，對產品和項目都有很大危害。風險提出得越早，除能夠避免團隊成員工做量的浪費以外，還可讓你們對需求變動考慮得更周全。因此，在這裏產品經理要注意，讓開發人員儘早瞭解和知道接下來要作什麼需求，涉及哪些技術難點，這既是必需的，也是應該的。

（3）在設計圖出來以後，或者開發原型出來之後，甚至在測試階段，發現以前的需求方案不合理。

　　這種狀況通常是不該該發生的，產品經理的水平越高，發生這種狀況的機率也會越低。可是人不可能徹底不犯錯，或者說，在看到真正的效果以前，甚至試用原型以前，有些交互體驗的細節問題確實難以發現。這也是產品經理須要修煉自身的地方，平時應該多試用各類產品，體驗各類交互和頁面設計，這樣才能在設計產品方案時不是單純地拍腦殼，而是在有真正的操做體驗的基礎上去設計。可是也要說明一點，這種狀況下的需求變動，不該該是很是重大的變動，通常都是交互體驗或者頁面內視覺邏輯的微調整。產品流程或產品邏輯的問題，應該在視覺效果圖輸出以前就可以被發現，而不是到視覺效果圖或者產品原型階段才能發現。

（4）還有一種很是無奈可是常見的狀況，即老闆提出的需求變動，或者真的因爲產品方向改變而出現的需求變動。

　　這種狀況下，產品經理也並不是徹底沒有責任。這時產品經理要思考，爲何老闆在已經進入設計和開發的階段才提出需求變動？是否由於老闆以前並無可以充分了解需求？這多是由於老闆太忙了，沒有關注到這個項目，那麼其實產品經理能夠更主動積極地讓老闆瞭解產品項目的進度、整個需求的思考過程和最終方案。這樣，若是老闆有其餘想法或不一樣意見，便可及早提出。
　　所以咱們看到，避免需求變動的主要思想就是，讓信息在團隊內部，產品與產品之間， 團隊與老闆之間，進行充分的交流和溝通，避免信息不對稱或不一樣步的狀況，在信息充分同步的狀況下，才能更早地暴露問題，提早修改需求方案，不浪費設計和開發等資源。
　　沒有需求變動的團隊是很是理想的，可是當理想照進現實，咱們發現，事實上不多有需求不變動的狀況。那麼，當需求變動不可避免地發生了，該怎麼處理，才能將危害降到最小呢？ 
　　其實，需求變動流程與產品的通常流程是一致的，首先是產品經理從新思考變動的需求， 全面考慮後輸出新的需求方案，同時並行的是充分與設計、開發、測試等團隊成員溝通，讓你們瞭解需求爲何要變動，如何變動，以及修改後的方案會是什麼樣子，等等。在團隊成員對變動後的需求都承認了以後，就要再次進入設計、開發、測試的階段。在整個過程當中， 產品經理同時要關注的是需求變動對整個產品版本進度的影響，通常須要設計、開發、測試人員從新評估工做量和提測時間，產品經理須要瞭解該變動是否會影響產品最終的發佈時間， 若是確實有影響，沒法經過協調其餘時間來消化，那麼要及時告知更大範圍的團隊成員。好比需求變動只涉及一個功能的開發和測試，但當這個需求變動會影響整個版本的進度時，就須要讓整個產品版本涉及的全部開發、測試等人員知道版本發佈計劃的變動及緣由。
　　因爲需求變動通常是產品經理髮起的，而這是至關不討好的事，因此產品經理的壓力其實很是大。最後再談兩點，讓產品經理適當減輕一點壓力，避免所以受到傷害。固然前提是產品經理要修煉本身，儘可能避免發生需求變動的狀況，在此基礎上，能夠用以下兩個方法來適當地調侃、保護本身。

（1）開發人員能保證不用修改Bug，那麼產品經理也能夠保證不發生需求變動。

　　修改Bug 其實就是開發人員不能一次性將產品作到完美的真實例子，其實這個道理在任何人身上都適用，只是開發人員的Bug 並不那麼容易被發現，而產品經理的「Bug」，不少狀況下是能夠提早避免的。因此，必定要注意這句話說出來的場合和語氣（通常要用調侃的語氣）。雖然道理如此，但這並非產品經理的擋箭牌。在說這句話以前，必定要真誠地向團隊成員道歉，尤爲是受到需求變動影響的成員，畢竟需求變動的責任更多地在產品經理。可是也能夠用這句話調侃下，讓你們互相理解，都是無可奈何。

（2）是Bug仍是需求變動？

　　善良的產品新人會說，這個問題須要去深究嗎？是的，通常狀況下，尤爲是小團隊，是不須要深究的，可是，當團隊比較大，或者需求變動致使的影響比較大的時候，搞清楚問題出現的緣由是Bug仍是需求變動，對將來避免發生相似問題是有益的。如何搞清楚呢？這就須要查看產品需求文檔。
　　曾經有產品新人問，寫需求文檔有沒有意義？若是它只是爲了備案和存檔記錄，那麼對於創業階段的小團隊，因爲產品方向還在不斷地變化，還在快速嘗試中，備案和記錄好像並無那麼必要和緊急。其實需求文檔的重要意義在於能夠先後印證，瞭解這一類有利於鞭策產品經理提高本身完整考慮需求的能力及寫需求文檔的能力。好比開發人員說：「這個Bug不是Bug，是你的需求，若是你如今要變成這樣，那麼你就要說明是需求變動。」這時，你可以悠然地打開需求文檔，指出某一條，上面明確寫明瞭需求，是開發人員沒有正確實現。不要覺得這種狀況很罕見。是Bug仍是需求變動，關乎聲譽甚至績效，是一個值得去明確的問題。對於產品經理來講，若是是早就想到了的需求邏輯點，只是由於在需求文檔中漏寫或沒有明確表達出來，致使開發人員認爲需求文檔裏沒有寫明而在開發過程當中也漏寫了邏輯從而產生問題，這種「需求變動」確實不能算Bug，責任就在於產品經理。
　　因此，若是你真的在需求文檔中明確表達清楚了，是開發人員沒有按照需求實現，那就是Bug，不能算做需求變動，這是對產品經理聲譽的保護。但若是是由於你的需求文檔寫得不夠嚴謹而形成「需求變動」，那麼就只有吃下黃連以後繼續修煉了。
　　本文選自《爆款是怎樣煉成的：產品經理晉級寶典》，點此連接可在博文視點官網查看此書。
　　　　　　　　　　　　　　　　　　　　
　　想及時得到更多精彩文章，可在微信中搜索「博文視點」或者掃描下方二維碼並關注。