不管是互聯(lián)網(wǎng)的產(chǎn)品，還是傳統(tǒng)IT的甲方項目，需求不定是常事，變是唯一的不變。頻繁的需求變更，對團隊無疑是巨大的消耗和打擊，作為PM，是否有好的途徑和措施處理需求變更？如何讓團隊能夠相對輕松的應對變更？

需求變更總是帶來危機

先梳理一個基本的概念：一個產(chǎn)品是由一個或多個項目組成，而一個項目可以是一個版本，也可以是一個模塊功能。也就是，為了降低耦合度和管理的難度，一個項目不應當出現(xiàn)多個產(chǎn)品成果的局面，這種“項目”應該通過項目組或項目群的機制來協(xié)調(diào)控制。

產(chǎn)品強調(diào)的是成果，比如產(chǎn)品的一個版本；項目強調(diào)的是對過程的控制，如何按質(zhì)按量如期交付。

需求的變更發(fā)生在任意的一個項目過程，它針對的是一個過程的影響，進而給整個產(chǎn)品帶來重大甚至致命性的影響，輕則延期發(fā)布，重則分崩離析。

作為產(chǎn)品經(jīng)理，要理解的第二個概念是：項目的金三角（范圍S、進度T、成本C），當然也可以說是項目的四要素：范圍、進度、成本和質(zhì)量。

S、T、C三者之間存在強烈的制衡關系，當你需要擴大/變更范圍（也就是需求邊界）的時候，一定會給進度和資源的投入帶來影響，變更的范圍越大變更的頻率越高，則對進度和資源的影響越大，也就是你不要奢望“又想馬兒跑,又不給馬兒吃草”。由于S、T、C之間的制約關系，產(chǎn)品的質(zhì)量必然隨著需求的變更帶來影響，而且往往是負向的影響，最壞的局面可能是產(chǎn)品質(zhì)量急劇下滑直到演變?yōu)橘|(zhì)量事故，而團隊的士氣也會隨著頻繁的變更而低落甚至崩潰。

變更通常意味著當前的項目路徑搖擺不定和失去控制，人可以適應變化，但對未知的世界會感到恐懼，簡單的說就是“不知道你的需求什么時候是個頭”，當團隊失去盼頭的時候，就會像推翻了潘多拉魔盒一般。

管理需求變更的目的不是為了要避免變更，而是有序的控制變更，減少和降低需求變更對產(chǎn)品開發(fā)的影響，包括成本、進度和質(zhì)量的影響。

盡早明確游戲規(guī)則

項目一旦開工，往往都是開工沒有回頭箭，硬著頭皮都要往死里整的節(jié)奏，特別是甲方的項目。在IT領域，最難搞的就只有甲方的項目了，而且它有先天的特性————付費方往往都是大爺。

所以需求都變動那是家常便飯，沒有變更往往不正常?；诖耍鳛镻M，首先要做都第一件事情就是要明確規(guī)則，啟動項目之前首先要搞清楚邊界，梳理好規(guī)范，什么是必須要做的，什么是可以變更的，通過什么機制，流程來實施變更等等。產(chǎn)品經(jīng)理（或者是項目經(jīng)理）的一個重要職責就是確保團隊始終朝著確定的方向前進。

需求管理就是制定項目的交通規(guī)則

| 什么時候梳理規(guī)則

答案是開工之前，或者是研發(fā)寫碼之前。

任何項目都有一個特色，那就是項目之前群情激昂，至于過程和結果，有的怨聲載道，有的劫后余生，萬象叢生都很正常，越大的項目故事往往越多。在事情還沒正式開始時，往往什么話都好談，制定規(guī)則也相對容易，所以這個良機千萬不可錯過，必須在確保所有干系人頭腦清醒，態(tài)度溫和的動工之前，把未來可能預知的風險盡量評估，并形成有力的項目環(huán)境，以及良好的決策溝通機制。否則，你面臨諸多不可調(diào)和的矛盾，在所難免。

作為產(chǎn)品經(jīng)理，盡可能的丑話講在前頭，為未來的荊棘之路清理掉一些沙子石頭。

| 哪些基本原則需要遵守

1. 重視需求變更作為PM，首先你要能深刻的理解變更將給你以及你的團隊帶來巨大的影響，你需要在戰(zhàn)略上保持清晰的頭腦，你只有在有序、可控的情況下，才能確保項目的按質(zhì)按量的交付，通常你都不可能在頻繁的接受需要變更的情況保證項目的質(zhì)量和進度，以及資源投入（這句話帶有極強的絕對性）。你需要讓你的團隊，你的客戶都深刻的理解需求變更的代價，任何在項目之初的輕視都會埋下隱患。
2. 統(tǒng)一需求入口為什么需要產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理的使命是什么呢？其中至少有一個極強的因素，那就是控制需求入口，搞清楚要做什么，該做什么，以及能做什么。所以，你需要牢牢的控制需求的入口——需求的接收渠道和管理平臺，它決定整個項目的邊界范圍，為此，你應該有足夠的心里準備，你需要面對N多方的壓力和“撕逼”，甚至，為了項目交付的這一終極目標，你需要有不惜得罪人的思想準備。越是大項目，越是牽涉多方的項目，風險和協(xié)調(diào)都會是指數(shù)級的放大。當一個項目，失去統(tǒng)一的需求入口，當一個產(chǎn)品經(jīng)理失去對入口的控制，意味著項目的失控。
3. 評審后再動手“不要著急做”，“不要任何人接到需求就開始動手”。你需要讓整個項目團隊，包括上至老板、直到程序員，也包括外部的客戶，都認同、理解并遵守一個基本原則，那就是程序員不直接接受任何非PM的需求，不接收任何非經(jīng)過評審的需求——所有未經(jīng)過評審的需求，只可討論，不可執(zhí)行。作為產(chǎn)品經(jīng)理，在需求變更收集上來之后，根據(jù)需求提出方的業(yè)務進行分析后，邀請需求方、技術、設計和測試多個環(huán)節(jié)進行分析，從而判定需求對于項目的影響如何，確定是否接受變更并將變更排列優(yōu)先級。當然，你可以適當根據(jù)需求的范圍大小，決定評審的范圍，甚至可以決定需要告知的對象，這沒有標準，需求靈活把握。這里其實是有一個例外，那就是技術本身驅(qū)動的變更，比如有更好的實現(xiàn)方案可以帶來性能的提升，這個情況，需要根據(jù)整體項目狀況，結合技術本身的能力判斷。
4. 保持持續(xù)跟蹤俗話說“好記性不如爛筆頭”。任何需求，都必須記錄在案，甭管是否執(zhí)行，需求的第一個動作就是備忘，第二步才是決定是否執(zhí)行。完整的需求變更記錄文檔將有助于你了解整個項目情況，包括執(zhí)行的需求，被拒絕的需求，你需要一個“需求池”統(tǒng)一管理來自業(yè)務端、技術端的需求，并針對項目中出現(xiàn)的資源、時間等因素可以合理的進行調(diào)配。今天被拒絕的需求，不等于將來也會拒絕，今天已經(jīng)執(zhí)行的需求，也不代表未來依然可行。

| 需求變更過程示例

這是一個簡單的圖例，來說明項目中對需求的控制過程，符合上述的基本規(guī)則。

你可以結合實際的項目結合，把需求的評審，變更機制，根據(jù)項目組織結構繪制一個完整的變更流程，包括需求的評審范圍，決策機制，文檔的追蹤存檔等環(huán)節(jié)。

節(jié)奏，一定要控制節(jié)奏

你確定了規(guī)則，梳理好了邊界，甚至也形成了流程。

下一步，你得控制好整個產(chǎn)品的推進節(jié)奏，合理的控制和調(diào)節(jié)需求、變更的優(yōu)先級，以及資源的投放力度，什么事情該投入多少資源，什么時候該做什么事情，什么是關鍵路徑，什么是關鍵角色，你必須門兒清。你得想方設法讓你的項目，在你所能控制的范圍內(nèi)進行，一旦超過邊界，你可能需要啟動后備資源予以干預，而且是在苗頭開始之際。

你所有的干預手段，預防機制，都是為了確保項目按照一定的規(guī)則和秩序推進，也只有基于可控的節(jié)奏，你才能確保整個過程的質(zhì)量，以及最終交付的質(zhì)量。當過程不可控的時候，往往結果會很糟糕。

最后，一定要深刻的理解，需求是不斷的演進和變化的，合理的規(guī)避不合理的變更方為上策。

不是你的團隊害怕和拒絕變更，而是對不可預知的狀態(tài)的擔憂，或者質(zhì)疑。產(chǎn)品經(jīng)理作為引路人，就是盡可能的讓不確定性的因素，變?yōu)榇_定的，可被執(zhí)行的流程、方案。