起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識你有哪些策略應對不斷的需求變更？
不管是互聯網的產品，還是傳統IT的甲方項目，需求不定是常事，變是唯一的不變。頻繁的需求變更，對團隊無疑是巨大的消耗和打擊，作為PM，是否有好的途徑和措施處理需求變更？如何讓團隊能夠相對輕松的應對變更？
需求變更總是帶來危機
先梳理一個基本的概念：一個產品是由一個或多個項目組成，而一個項目可以是一個版本，也可以是一個模塊功能。也就是，為了降低耦合度和管理的難度，一個項目不應當出現多個產品成果的局面，這種“項目”應該通過項目組或項目群的機制來協調控制。
產品強調的是成果，比如產品的一個版本，項目強調的是對過程的控制，按質按量如期交付。
需求的變更發生在任意的一個項目過程，它針對的是一個過程的影響，進而給整個產品帶來重大甚至致命性的影響，輕則延期發布，重則分崩離析。
作為產品經理，要理解的第二個概念是：項目的金三角（范圍S、進度T、成本C），當然也可以說是項目的四要素：范圍、進度、成本和質量。
S、T、C三者之間存在強烈的制衡關系，當你需要擴大/變更范圍（也就是需求邊界）的時候，一定會給進度和資源的投入帶來影響，變更的范圍越大變更的頻率越高，則對進度和資源的影響越大，也就是你不要奢望“又想馬兒跑,又不給馬兒吃草”。由于S、T、C之間的制約關系，產品的質量必然隨著需求的變更帶來影響，而且往往是負向的影響，最壞的局面可能是產品質量急劇下滑直到演變為質量事故，而團隊的士氣也會隨著頻繁的變更而低落甚至崩潰。
變更通常意味著當前的項目路徑搖擺不定和失去控制，人可以適應變化，但對未知的世界會感到恐懼，簡單的說就是“不知道你的需求什么時候是個頭”，當團隊失去盼頭的時候，就會像推翻了潘多拉魔盒一般。
管理需求變更的目的不是為了要避免變更，而是有序控制變更，減少和降低需求變更對產品開發的影響，包括成本、進度和質量的影響。
盡早明確游戲規則
項目一旦開工，往往都是開工沒有回頭箭，硬著頭皮都要往死里整的節奏，特別是甲方的項目。在IT領域，最難搞的就只有甲方的項目了，而且它有先天的特性————付費方往往都是大爺。
所以需求都變動那是家常便飯，沒有變更往往不正常，基于此，作為PM，首先要做都第一件事情就是要明確規則，啟動項目之前首先要搞清楚邊界，梳理好規范，什么是必須要做的，什么是可以變更的，通過什么機制，流程來實施變更等等。產品經理（或者是項目經理）的一個重要職責就是確保團隊始終朝著確定的方向前進。
需求管理就是制定項目的交通規則
什么時候梳理規則
答案是開工之前，或者是研發寫碼之前。
任何項目都有一個特色，那就是項目之前群情激昂，至于過程和結果，有的怨聲載道，有的劫后余生，萬象叢生都很正常，越大的項目故事往往越多。在事情還沒正式開始時，往往什么話都好談，制定規則也相對容易，所以這個良機千萬不可錯過，必須在確保所有干系人頭腦清醒，態度溫和的動工之前，把未來可能預知的風險盡量評估，并形成有力的項目環境，以及良好的決策溝通機制。否則，你面臨諸多不可調和的矛盾，在所難免。
作為產品經理，盡可能的丑話講在前頭，為未來的荊棘之路清理掉一些沙子石頭。
哪些基本原則需要遵守
（1）重視需求變更
作為PM，首先你要能深刻的理解變更將給你以及你的團隊帶來巨大的影響，你需要在戰略上保持清晰的頭腦，你只有在有序、可控的情況下，才能確保項目的按質按量的交付，通常你都不可能在頻繁的接受需要變更的情況保證項目的質量和進度，以及資源投入（這句話帶有極強的絕對性）。
你還需要讓你的團隊，你的客戶都深刻的理解需求變更的代價，任何在項目之初的輕視都會埋下隱患。
（2）統一需求入口
為什么需要產品經理，產品經理的使命是什么呢？其中至少有一個極強的因素，那就是控制需求入口，搞清楚要做什么，該做什么，以及能做什么。
所以，你需要牢牢的控制需求的入口——需求的接收渠道和管理平臺，它決定整個項目的邊界范圍，為此，你應該有足夠的心里準備，你需要面對N多方的壓力和“撕逼”，甚至，為了項目交付的這一終極目標，你需要有不惜得罪人的思想準備。越是大項目，越是牽涉多方的項目，風險和協調都會是指數級的放大。
當一個項目，失去統一的需求入口，當一個產品經理失去對入口的控制，意味著項目的失控。
（3）評審后再動手
“不要著急做”，“不要任何人接到需求就開始動手”。
你需要讓整個項目團隊，包括上至老板、直到程序員，也包括外部的客戶，都認同、理解并遵守一個基本原則，那就是程序員不直接接受任何非PM的需求，不接收任何非經過評審的需求——所有未經過評審的需求，只可討論，不可執行。
作為產品經理，在需求變更收集上來之后，根據需求提出方的業務進行分析后，邀請需求方、技術、設計和測試多個環節進行分析，從而判定需求對于項目的影響如何，確定是否接受變更并將變更排列優先級。當然，你可以適當根據需求的范圍大小，決定評審的范圍，甚至可以決定需要告知的對象，這沒有標準，需求靈活把握。
這里其實是有一個例外，那就是技術本身驅動的變更，比如有更好的實現方案可以帶來性能的提升，這個情況，需要根據整體項目狀況，結合技術本身的能力判斷。
（4）保持持續跟蹤
俗話說“好記性不如爛筆頭”。任何需求，都必須記錄在案，甭管是否執行，需求的第一個動作就是備忘，第二步才是決定是否執行。
完整的需求變更記錄文檔將有助于你了解整個項目情況，包括執行的需求，被拒絕的需求，你需要一個“需求池”統一管理來自業務端、技術端的需求，并針對項目中出現的資源、時間等因素可以合理的進行調配。
今天被拒絕的需求，不等于將來也會拒絕，今天已經執行的需求，也不代表未來依然可行。
需求變更過程示例
這是一個簡單的圖例，來說明項目中對需求的控制過程，符合上述的基本規則。
你可以結合實際的項目結合，把需求的評審，變更機制，根據項目組織結構繪制一個完整的變更流程，包括需求的評審范圍，決策機制，文檔的追蹤存檔等環節。
節奏，一定要控制節奏
你確定了規則，梳理好了邊界，甚至也形成了流程。
下一步，你得控制好整個產品的推進節奏，合理的控制和調節需求、變更的優先級，以及資源的投放力度，什么事情該投入多少資源，什么時候該做什么事情，什么是關鍵路徑，什么是關鍵角色，你必須門兒清。你得想方設法讓你的項目，在你所能控制的范圍內進行，一旦超過邊界，你可能需要啟動后備資源予以干預，而且是在苗頭開始之際。
你所有的干預手段，預防機制，都是為了確保項目按照一定的規則和秩序推進，也只有基于可控的節奏，你才能確保整個過程的質量，以及最終交付的質量。當過程不可控的時候，往往結果會很糟糕。
最后，一定要深刻的理解，需求是不斷的演進和變化的，合理的規避不合理的變更方為上策。
不是你的團隊害怕和拒絕變更，而是對不可預知的狀態的擔憂，或者質疑。產品經理作為引路人，就是盡可能的讓不確定性的因素，變為確定的，可被執行的流程、方案。
【注：本文排除一種可能性——“產品上線在即卻發現不符合用戶/客戶的基本需求”，這應該歸屬于產品的方向性錯誤，嚴格來說已經超過變更的范疇?！?/p>
本文由 @杜松 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Pexels，基于 CC0 協議
說的很好，受到啟發！
碰上一個不懂套路的pm.整個過程是個災難。項目形的產品。
辛苦了。