如何制定一份縝密的項(xiàng)目計(jì)劃可能并不是項(xiàng)目中最難的事情，要應(yīng)對(duì)計(jì)劃之外的情況，才是最令大家頭痛的地方。在項(xiàng)目實(shí)際推進(jìn)過程中，不加控制的需求變更往往給項(xiàng)目帶來沉重的負(fù)擔(dān)和無法預(yù)料的風(fēng)險(xiǎn)。因此，設(shè)計(jì)一套合適的需求變更管理流程和規(guī)范，對(duì)項(xiàng)目和項(xiàng)目經(jīng)理而言都是不可或缺的。

問題分析

首先對(duì)筆者所在項(xiàng)目做一個(gè)簡單介紹：產(chǎn)品層面，我們是一個(gè)C端產(chǎn)品，需求主要來源于運(yùn)營和策劃，就產(chǎn)品階段而言正處于轉(zhuǎn)型期，現(xiàn)階段主要以新功能探索為主；項(xiàng)目層面，由于功能較為復(fù)雜龐大，可切割空間不大，因此每個(gè)版本周期都較長（每個(gè)版本的產(chǎn)品準(zhǔn)備周期，研發(fā)周期分別都在15～20個(gè)工作日左右），從產(chǎn)品設(shè)計(jì)到研發(fā)并上線的主干流程是具備的，如下：

筆者定義需求變更包含兩個(gè)層面，一是在產(chǎn)品設(shè)計(jì)階段：需求評(píng)審結(jié)束，PRD文檔定稿后再對(duì)需求稿進(jìn)行更改，定義為需求變更；二是研發(fā)排期結(jié)束，定稿開發(fā)測試上線計(jì)劃，之后凡是計(jì)劃外的變化都定義為需求變更。

一開始項(xiàng)目上并沒有對(duì)需求變更的流程規(guī)范做清晰的定義，因此項(xiàng)目實(shí)際推進(jìn)過程中會(huì)出現(xiàn)諸多由變更引發(fā)的問題，下面結(jié)合實(shí)際問題做逐一說明：

問題一：變更多：一開始，項(xiàng)目最大的問題是需求變更很多，如果只是猛的一頭扎進(jìn)流程中去，反而浪費(fèi)時(shí)間，所以我們嘗試去分析這些變更的原因，看看是否能在源頭堵住變更。經(jīng)過判斷，發(fā)現(xiàn)相當(dāng)一部分變更是因?yàn)?strong>需求設(shè)計(jì)不夠健壯或者交互對(duì)需求的理解不到位，在后續(xù)的階段發(fā)現(xiàn)，進(jìn)而才開始修改或新增需求。

問題二：變更不規(guī)范：變更是在所難免的問題，大家坐下來聊一聊，如果感覺不錯(cuò)那就把這個(gè)變更做了吧，這是我們之前的做法。但，由于缺乏一個(gè)明確的基本流程規(guī)范，一到變更的時(shí)候，處理事情往往丟三落四，進(jìn)而會(huì)出現(xiàn)以下問題：

• 變更需求提出人太多，不知道聽誰的
• 變更提出的太晚，留給項(xiàng)目的時(shí)間不多了
• 變更到底做不做，什么時(shí)候做等信息，在各個(gè)角色間的信息不同步

問題三：問題帶來風(fēng)險(xiǎn)：項(xiàng)目過多關(guān)注于討論變更本身以及變更的意義，往往忽略了實(shí)施變更往往會(huì)沖擊原有計(jì)劃，缺乏完整的風(fēng)險(xiǎn)分析；在變更執(zhí)行的時(shí)候，沒有相對(duì)固定的套路和章法，執(zhí)行過程很松散，缺乏一些有效的監(jiān)控，過程風(fēng)險(xiǎn)演變不得而知。

解決方案

我們在給出解法的同時(shí)還需注意到，項(xiàng)目管理所依賴的流程和規(guī)范若太強(qiáng)則使項(xiàng)目運(yùn)轉(zhuǎn)繁瑣低效；但過弱則又使項(xiàng)目松弛散漫。因此，設(shè)計(jì)對(duì)應(yīng)辦法的時(shí)候需要充分考慮各種方案，選取最簡單的方式來實(shí)現(xiàn)規(guī)范管理。

針對(duì)問題一，我們決定優(yōu)化原有的主干流程，增加一個(gè)承上啟下的環(huán)節(jié)做需求確認(rèn)；針對(duì)問題二和問題三，我們規(guī)范了變更如何審批，變更如何執(zhí)行兩個(gè)過程；建立方式監(jiān)控項(xiàng)目對(duì)變更工作量的承受情況。

主干流程優(yōu)化

項(xiàng)目上根據(jù)實(shí)踐經(jīng)驗(yàn)發(fā)現(xiàn)僅靠需求評(píng)審無法完全保證需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本質(zhì)原因在于PRD并不能完整的描述清楚整個(gè)場景，許多需求層面的細(xì)節(jié)和串聯(lián)即便在需求評(píng)審結(jié)束后依然可能覆蓋不全；只有隨著交互設(shè)計(jì)師把需求完善成結(jié)構(gòu)嚴(yán)謹(jǐn)?shù)倪壿媹D和場景說明，往往才會(huì)發(fā)現(xiàn)一開始需求設(shè)計(jì)不到位的情況，在大版本的情況下，等到整個(gè)交互稿都拿出來了再去做變更，變更代價(jià)過大/感受也不好。

因此，對(duì)于較為復(fù)雜的設(shè)計(jì)，在交互評(píng)審之前會(huì)拆分一個(gè)環(huán)節(jié)出來，做一個(gè)交互主場景的評(píng)審。通過新增的環(huán)節(jié)，確保需求的健全和完善，減少流入后續(xù)階段的需求變更數(shù)量。

這個(gè)做法適用于策劃變更PRD頻繁，以及功能過于復(fù)雜伴隨較大的潛在變更風(fēng)險(xiǎn)兩個(gè)場景。PRD頻繁變更頻繁并不完全因?yàn)楣δ苓壿嬙O(shè)計(jì)有漏洞，還有可能是產(chǎn)品規(guī)劃/商業(yè)分析論證等前置流程沒做好，這種背景下光是增加一個(gè)主場景的評(píng)審是沒用的，讀者需要仔細(xì)分析。

這樣一個(gè)交互主場景的評(píng)審，具體操作建議如下：

• 時(shí)點(diǎn)：這個(gè)環(huán)節(jié)安排在需求評(píng)審結(jié)束后，交互評(píng)審開始前，且建議在需求評(píng)審后盡快安排，大概2個(gè)工作日內(nèi)安排；
• 內(nèi)容：交互理解策劃PRD說明后，初步制作交互稿，粒度達(dá)到覆蓋主要的場景及完整的邏輯流程，然后召開主場景評(píng)審會(huì)與策劃/需求方進(jìn)行確認(rèn)，確保需求理解正確和需求的健全。
• 參與人：需求提出方（如運(yùn)營，市場等），策劃，交互

變更規(guī)范明確

變更流程的規(guī)范涵蓋兩個(gè)主要方面，一是明確變更管理的基本理念；二是明確一旦要做變更，需要依序執(zhí)行的步驟。

管理變更的理念>>

變更管理的核心在于評(píng)估需求變更的價(jià)值，然后決定做不做以及是否在當(dāng)前版本做，我們嘗試從更多角度去思考，包括說產(chǎn)品的規(guī)劃，需求的特點(diǎn)。

首先分析產(chǎn)品階段特點(diǎn)：我們處在產(chǎn)品轉(zhuǎn)型這樣一個(gè)新舊交叉時(shí)期（簡單說就是一方面要維護(hù)原有功能，另一方面更需探索設(shè)計(jì)新的功能），因此這個(gè)時(shí)期的需求變更可以劃分成四個(gè)維度：原有核心功能，原有周邊功能，新功能核心功能，新功能周邊功能；變更也按上述維度進(jìn)行分類，再考慮版本上線時(shí)間和質(zhì)量，按照以下順序去考慮需求變更（筆者假設(shè)質(zhì)量是恒定的，范圍和進(jìn)度是變量，所以對(duì)范圍和進(jìn)度進(jìn)行優(yōu)先級(jí)排序）：新功能核心功能變更>原有核心功能變更>版本上線時(shí)間>新功能周邊功能變更>原有周邊功能變更。

同時(shí)，十分不建議因?yàn)榫o急需求變更去延遲既定的上線時(shí)間，對(duì)于項(xiàng)目而言，上線時(shí)間是一個(gè)很嚴(yán)肅的事情，不能輕易的去改變，是大家共同守護(hù)的目標(biāo)。因此，我們定義需求變更凍結(jié)時(shí)點(diǎn)，原則上在凍結(jié)點(diǎn)后不接受任何變更。關(guān)于需求凍結(jié)點(diǎn)如何設(shè)置，不同的項(xiàng)目需要根據(jù)實(shí)際情況做分析，比如我們的做法是：產(chǎn)品階段的凍結(jié)時(shí)點(diǎn)是交互場景評(píng)審結(jié)束后兩天內(nèi)；研發(fā)階段的凍結(jié)時(shí)點(diǎn)是提測點(diǎn)前兩天左右（設(shè)置的原則就是做版本計(jì)劃的時(shí)候，開發(fā)在估算提測時(shí)間同時(shí)確認(rèn)showcase時(shí)點(diǎn)作為凍結(jié)點(diǎn)，而這個(gè)時(shí)間一般就是提測點(diǎn)前兩天左右）。而實(shí)際上對(duì)這兩個(gè)凍結(jié)點(diǎn)，我們會(huì)側(cè)重于對(duì)后一個(gè)凍結(jié)點(diǎn)的管理。

在應(yīng)對(duì)變更的整體思路上，除了以上的實(shí)踐經(jīng)驗(yàn)總結(jié)而來的基本思路，還建議有條件的項(xiàng)目盡量嘗試固定時(shí)間研發(fā)迭代時(shí)間，周期上如果能達(dá)到兩周一迭代是最理想的。我們也嘗試一周一迭代，這時(shí)候在應(yīng)對(duì)需求變更的時(shí)候明顯更加從容，但適用場景有限，細(xì)碎的優(yōu)化需求是周迭代處理的重點(diǎn)。

執(zhí)行變更的步驟>>

其實(shí)變更如何執(zhí)行，并沒有一個(gè)一成不變的套路，但結(jié)構(gòu)上其實(shí)還是大同小異，筆者給出項(xiàng)目上的一些實(shí)踐供大家參考：

• 需求方提出變更（建議同一個(gè)角色集中由一個(gè)人來提變更，比如運(yùn)營/市場需要分別指定唯一的輸出需求變更的接口人），策劃評(píng)估變更必要性，制定變更的方案（建議變更統(tǒng)一由當(dāng)前版本負(fù)責(zé)的策劃來統(tǒng)一收集和輸出）；如果需要交互設(shè)計(jì)，需要和交互一起討論實(shí)現(xiàn)方案。
• 策劃通知開發(fā)，開發(fā)同學(xué)評(píng)估變更工作量，一般情況下，開發(fā)和策劃共同決定是否在當(dāng)前版本實(shí)現(xiàn)變更，如果意見不能一致，需要提交可以負(fù)責(zé)的干系人審批決定，但這種情況往往較少，大部分情況還是要靠產(chǎn)品和開發(fā)撕出一個(gè)結(jié)論。
• PK成功的變更將進(jìn)入研發(fā)，站會(huì)周知，項(xiàng)目經(jīng)理評(píng)估風(fēng)險(xiǎn)；PK失敗的變更進(jìn)入需求池，在池子里重排優(yōu)先級(jí)。對(duì)于PK成功的變更，一般而言我們會(huì)拿掉一個(gè)優(yōu)先級(jí)較低的需求，保證迭代里工作量相對(duì)恒定；但，這只是原則上的做法，我們也會(huì)靈活的分析當(dāng)前剩余工作量，來決定是否可以直接添加變更，這種做法建議是盡量要少。
• ?在變更執(zhí)行過程中去監(jiān)控狀態(tài)和風(fēng)險(xiǎn)：我們在項(xiàng)目過程中利用jira的dashboard去監(jiān)控各個(gè)開發(fā)變更工作量和剩余時(shí)間，利用每日站會(huì)去不斷review確認(rèn)隊(duì)列中的變更，按照優(yōu)先級(jí)依次完成項(xiàng)目允許范圍內(nèi)的變更。說明：項(xiàng)目上常常會(huì)有這樣的情況，大型的需求變更往往比較正式的走流程，風(fēng)險(xiǎn)比較好把控；對(duì)于細(xì)碎的小變更，在沒法打包統(tǒng)一處理的情況下，單個(gè)開發(fā)人員會(huì)陸續(xù)承受一個(gè)一個(gè)而來的多個(gè)小問題，而這些細(xì)小的問題你很難做去做時(shí)間承諾，只能大致的感受很簡單+可以改，最終結(jié)果可能就是這樣：不知不覺中，隊(duì)列中的變更會(huì)慢慢增多，一個(gè)個(gè)未經(jīng)詳細(xì)估算的小點(diǎn)匯聚成較大的風(fēng)險(xiǎn)。

總結(jié)

最后總結(jié)一下，除了要梳理好策略和流程規(guī)范去管理變更和執(zhí)行變更，還需要選取合適時(shí)機(jī)引導(dǎo)團(tuán)隊(duì)復(fù)盤變更的原因，持續(xù)改進(jìn)策略和流程規(guī)范。復(fù)盤中需要排除干擾因素，聚焦高頻變更并分析產(chǎn)生的本質(zhì)。復(fù)盤除了支持持續(xù)改進(jìn)，形成流程閉環(huán)，也有助于團(tuán)隊(duì)就變更原因和解決方案達(dá)成共識(shí)，提高團(tuán)隊(duì)管理變更和執(zhí)行變更兩方面的執(zhí)行力。

如何深入的做好變更管理，簡化變更的步驟，仍在探索優(yōu)化中，歡迎大家與我交流。

作者：何雨，網(wǎng)易杭研項(xiàng)目管理部高級(jí)項(xiàng)目經(jīng)理，先后在網(wǎng)易GACHA、網(wǎng)易云公共產(chǎn)品部擔(dān)任項(xiàng)目經(jīng)理。關(guān)注Agile、scrum在互聯(lián)網(wǎng)產(chǎn)品的實(shí)踐和團(tuán)隊(duì)的成長?！毒W(wǎng)易一千零一夜》主要編輯之一。

本文由@網(wǎng)易杭研項(xiàng)目管理（微信公眾號(hào)：NetEasePM）原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。