起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識做好版本迭代管理，給團隊一顆糖
#本文為人人都是產品經理《原創激勵計劃》出品。
在團隊工作中，產品經理需要身兼多職、兼顧多方意見。而產品版本迭代管理往往需要牽扯項目的多方面。那么，當產品經理著手版本迭代管理工作時，應當如何協調團隊工作、做好過程控制、進而凝聚團隊力量？本文作者便結合其自身經驗向我們做出了清晰展示。
自春節到現在，我陷入一種困境里：突然間，我好像成了“夾心餅干”？
事情是這樣的，由于業務變動，最近我開始負責一個核心產品的版本迭代管理。我敞開心扉擁抱變化，但兩個月下來，事情比我想象中得更棘手。
先交代下背景。
在我之前的工作經歷里，我和前線的團隊交涉比較多，銷售、售前架構師、產品架構師、服務商、ISV，都相對比較熟稔。熟稔到什么地步呢，就是他們跟我說聲hi，我都幾乎能料到他下一句話想問什么、想要什么，我可以怎么推杯換盞地應對他們。和他們站在同一條船上久了，我深諳支持項目有多不易，我理解客戶對產品的訴求有多急切，也愿意盡最大努力去爭取產品研發的資源投入。
但是，一切開始不一樣了。自打我接手產品研發工作，開始負責產品整體規劃和版本迭代管理后，我多了一重身份。隨著我深入了解產品的細節，了解看似簡單實則不易的需求背后沉淀了這么多研發、測試的人力后，我不得不站出來為產品研發團隊說說話了。
這也就導致，我清楚客戶需求的合理性和迫切性，但我也在警惕產品研發資源的不合理占用。于項目團隊而言，作為產品接口人的我開始謹慎承諾，小心防守；于研發團隊而言，作為項目經理的我抱著一攬子需求回來，生怕我獅子大開口。
里外不是人了不是？我反思過，是不是該去學一學怎么端水？
把情緒放一放，我給自己一個版本的試煉機會，也趁此摸清楚了項目支持和產品管理的平衡之術。
我和其他團隊的產品經理聊了下，有些同學一開始就是走產品策劃路線，始終站在產研的角度，專心琢磨如何讓產品做得更好；有些同學一直都是在客戶現場，或是出差去現場的路上，他懂行懂客戶，能根據客戶需求擬制解決方案。
其中不乏有產品經理負責版本迭代管理，但總會遇到各種各樣的問題：怎么去權衡各大項目反饋的需求優先級？怎么應對空降的需求帶來的資源占用？怎么讓前線團隊放心、讓研發團隊齊心呢？
不少團隊都傾向于將產品研發管理專門交給項目經理去負責，由項目經理協調產品、設計、研發、測試的資源，并跟進整體版本迭代的進展。這的確權責分明，產品做需求，開發寫代碼，各司其職，何樂而不為？
可事實上，版本管理的重點不在于由產品研發團隊中的哪個角色來承擔，關鍵在于如何去管理這個版本。既然團隊內暫時沒有這樣的角色來支撐，那么我大可以利用自己的多重身份“夾帶私貨”，不是嗎？
一、不僅是規劃版本
規劃版本前先規劃產品roadmap。
為什么前線項目組總是源源不斷地投遞需求——我要斬斷不重要不緊急的客戶需求。
為什么研發同學總是下意識拒絕需求——我要調動產研資源實現優先級最高的產品能力。
從客戶需求到產品能力之間是有Gap的，我要搭橋造梁，就需要一個支撐。
那么，怎么規劃產品的階段性里程碑？
1. 從團隊KPI入手
今年團隊的考核目標是什么，是產品收入？用戶活躍度？標桿案例數？項目的復制情況？
2. 制定個人OKR
基于團隊的目標，落實到個人所負責的產品目標，去看在該目標下你要輸出的關鍵結果是什么。
比如你們考核的是要在全國范圍內樹立至少2個國家級標桿項目，那么對應的這類型項目最關注的需求場景是什么；為了滿足這樣的需求場景，產品要實現哪些能力、配套提供哪些服務支持。
3. KANO模型
這是東京理工大學教授狩野紀昭（Noriaki Kano）發明的對用戶需求分類和優先排序的工具，需求分五類：基本型需求、期望型需求、興奮型需求、無差異型需求、反向型需求。
① 基本型需求（必備型需求）
客戶認為必須有，沒有的話這個功能就不具有交付意義的需求。
針對這類需求，一旦你沒滿足客戶，客戶的滿意度將一落千丈，你可能馬上就要被踢出局。比如顧客買一個保溫杯，它能正常裝熱水，顧客不會為此感到滿意；但如果這杯子有裂縫，杯蓋擰不緊，或是保溫效果差，那么顧客對這個杯子的滿意度就會明顯下降，投訴接踵而至。
② 期望型需求
客戶期望你可以實現的需求，一旦你實現了，客戶滿意度會顯著提升，你提供的產品超出客戶期望越多，客戶就越滿意。
但相應的，如果你拒絕滿足客戶需求或是表現不好的話，客戶也會立馬提出不滿。比如客戶期望貴司提供的問題響應機制可以更快捷、故障處理可以更高效，那么一旦你優化了問題處理流程，提高對客戶的響應效率，客戶就越滿意。
③ 興奮型需求（魅力型需求）
客戶既不會過分期望，又不會明顯不滿的需求，即，有更好，沒有也能接受。
比如早期海底撈向客戶推出生日當天全體員工向顧客唱生日歌，這種服務的確會讓顧客驚喜，但如果不提供這個服務，顧客也不會不滿。這類需求通常能在某些時機打動客戶，贏得客戶決策人更多的關注。
④ 無差異型需求
這類需求對客戶沒有影響，有或沒有都無所謂。
這種需求怎么會被人提出來呢，可能是客戶對標了不同的產品，或是靈光乍現想到的，這樣的需求在應對的時候需要甄別，不必過分投入在這類需求上。
⑤ 反向型需求
該需求會引起大部分人的強烈不滿，你實現該需求反而會降低客戶的滿意度。
比如客戶管理層提出一些強管理的需求，乍一聽很合理，但深究下來，這需求對員工不友好。即便你短暫地滿足了客戶高層的需求，但長遠來看一定會收到客戶的投訴，畢竟客戶采購軟件并不僅限于在管理層使用，更多時候還是為了服務于全體員工。
針對這類需求，你且緩緩，先冷靜旁觀，做好充分的客戶需求調研后，再決定是否要做。
根據上述三方面，在實際規劃產品藍圖時，可以從以下兩方面去考慮：
- 一方面根據團隊OKR劃定產品方向，圈定幾個需要沖刺的功能模塊，分月度、季度去迭代功能、做項目驗證，再炮制到其他項目中落地；
- 另一方面擺正心態，正視客戶反饋的需求，全力以赴滿足基本型需求，重視產品義務范疇內的事項，確保在市場競爭中不丟分。同時，盡力去滿足客戶的期望型需求，提供大多數客戶關注的額外服務和產品，引導客戶的決策鏈對本產品有更多的傾向性；最后才是爭取實現客戶的興奮型需求，提高客戶用戶的粘性和復購率。
你看，通過層層過濾，你會發現有不少客戶需求其實沒那么重要，它并不能為產品的銷售有什么催化作用，甚至在占用產研資源后還討不到一點好處。
二、不僅是管理版本
前文提到如何在規劃版本前規劃好產品階段性的里程碑，圍繞里程碑去規劃每個月的版本內容和版本節奏。
但實際上在管理版本中最大的問題不在于做哪些需求，而是什么需求要先做。每一位架構師都認為自己負責的客戶提的需求最靠譜、最重要、最緊急，動輒就是“這是某位CTO提的”、“這個需求已經上升到我司的某位高管”之類的……通往產品發布的管道就這么寬，全堵在這段路上，誰也動不了，誰也不想讓。
這時候除了根據KANO模型對需求做一層初步的分類之后，每個類目下依然存在不少需求，怎么排優先級？
向外看，競爭對手相比你的優勢在哪？它推崇的關鍵控標點有什么？研究競品并不可恥，市場就這么大，池子里的魚就這么多，為了捕獲更多的獵物，取長補短也是順理成章的。
向內看，你不必把這份責任全部放在自己身上，建立版本評審委員會，邀請領導、產品和研發負責人、前線反饋需求的架構師，共同來評審這些需求的優先級。通過責任公攤和事務公開，形成一個集體公認的版本需求池。
在需求池初具雛形后，你要及時組織產品研發團隊開版本啟動會，宣導需求池里的所有需求，請產品和研發初步給出工作量的預估。一個版本迭代的周期就這么長的時間，對于比較復雜的需求，適時地拉長陣線去細化產品方案，才能確保不浪費研發的資源。
記住，排優先級時，不可只關注客戶需求而忽視了去建設能滿足更多客戶的核心優勢。
在明確版本需求和需求的優先級后，我們再來看下如何調動資源投入到版本迭代。
1. 資源投入情況
- 項目經理：負責整體版本規劃和需求管理，跟進版本迭代進程，對版本的整體發布負責；
- 產品經理：負責產品需求的方案設計和評審，負責與設計、研發、測試協作開展需求的建設，對需求的實現情況負責；
- 研發：負責產品需求的技術方案設計和實現，把控需求的研發進度；
- 設計：完成需求UI設計和視覺設計，輸出設計切圖；
- 測試：輸出測試用例，把控需求的質量。
這些角色在參與版本迭代時都有各自的期望，在不同的環節里都需要換位思考下。
比如研發，最怕產品方案沒考慮完全就火急火燎地找上來要技術實現，前期方案的不周全大概率會引發后期需求的變更，這對研發而言就是資源的浪費。
那么站在研發的角度，產品經理對待需求就不能只是在講一個簡單的用戶故事，客戶需求和產品能力之間的gap有多大，取決于你如何去理解需求、如何去細化需求場景、如何打磨好你的產品。
相應的，在版本迭代的過程中，項目經理預留給產品經理思考方案的時間要充分，不能為了滿足更多的需求而忽視了產品的細節。產品不可只看細節，也不可全然不顧細節。
不注重各個方面的細節，終究會連累到之前積累的口碑；當所有人都盯著你缺的那一筐土的時候，沒有人會關心已經堆好的九仞土山。
2. 團隊機制與過程控制
既然是一個長期工程，那么何不如從一開始就下功夫定流程，定機制，把涉及到的角色的工作地圖畫出來？
前面提到，我給自己一個版本的時間窗，去印證這個團隊機制的可行性。具體流程是什么樣呢？
1）明確版本節奏
一個半月2個小版本1個大版本（ab為小版本，c為大版本），小版本內部測試體驗，大版本對外正式發布。
2）規范迭代流程
① 建立版本評審委員會，從版本規劃開始，做好向上匯報和對內同步，保證信息公開透明。沒錯，你是版本總體負責人，但你沒必要把很多責任往自己身上攬，尤其涉及到需要上升決策的事情，分攤責任也同樣是在分攤風險。
② 版本需求確定后，預留充分的時間給到產品經理調研需求、設計產品方案，并樹立一個標桿性事件：開展版本啟動會。由各產品經理大體宣講需求，明確需求的研發負責人，全員投票評估需求的合理性和可行性。
③ 需求進一步得到產品和研發的評估后，產品和研發負責人各自組成feature team，啟動對需求的實現之路，再配合設計、測試的資源，讓需求在版本發布計劃的時間窗內有序地推進，并適時地同步進展和風險，確保需求相關人對需求的理解是一致的。
3）加強過程控制
流程是有了，但流程里涉及到的環節比較多，需要抓住最關鍵的部分加強管控。
一個是需求評審環節，這決定了這個需求后續的實現路徑，絕不能輕視。對于相對復雜且重要的需求，對于空降的高優先級需求，能不能插隊也不是研發或產品或架構師說了算，都必須嚴格上升到版本評審委員會共同決議。
一個是研發排期環節，版本的發布時間窗是基本固定的，研發排期的評估除了根據需求的優先級、實現的工作量之外，還要根據發布計劃的時間點看能趕上哪一個發布計劃，以確保給客戶承諾的交付時間是相對可靠的。
一個是產品體驗環節，不少團隊在前期需求設計上嚴防死守，可一旦步入研發階段，產品經理除了間或響應研發的問題咨詢外，對需求本身的實現過程和實現結果是有點輕視的。
這里需要尤其重視需求研發完成后的產品體驗環節，產品經理必須完整地按測試用例走查一遍功能，確保最終的功能與最初需求的設計是契合的。若有偏差，是否要變更或追加需求，則同樣需要引入版本評審委員會（與該需求相關的人員）一起來評估。
三、不僅是一顆糖
產品如期發布了，這時候我對前線的架構師是否就有了交代？不夠。
回想下，架構師對產品的能力是清晰的嗎？他們提的客戶需求為什么在不少產品研發同學看來不太合理呢？歸根結底是因為項目支持和產品建設脫節了。
兩撥人，一撥人忙著做項目，一撥人忙著做需求，各自作戰，各自為政。
你可能會說，產品做出來不就是為了更好地在項目里售賣和交付嗎？沒錯，但在實際運作的過程中確實存在這樣的問題。于是你會發現，前線團隊對產品一知半解，產研團隊對項目一窮二白。
這是常態，但可以被改變。
回過頭來看整個版本迭代流程，你會發現有很多環節完全可以借助前線架構師的力量。
- 在版本規劃初期，項目經理可以請架構師給出有力的項目背景佐證需求的合理性；
- 在需求調研時，產品經理與架構師的深入訪談，可以更充分地了解需求場景和目標，如有必要也可以跟架構師一起拜訪客戶；
- 在需求研發完成轉產品體驗時，產品經理邀請架構師一起體驗功能，確保功能的效果與架構師的預期一致；
- 在產品發布后，產品經理可以請架構師一同編制功能故事，描述功能的操作路徑、實現效果和價值，以便客戶更好地使用功能。
整個過程里，前線架構師與產研團隊有了更多的互動和融合，這是我們給到架構師的一顆糖，它不僅提升了架構師對產品的理解力，也加深了產研團隊對客戶的認識。
同樣的，產品發布后交付給到客戶后，這時候我對產研團隊是否就有了交代？不夠。
很多時候一個新版本從規劃到發布，一個多月過去了。這一個月期間，客戶也許還在追著要這個能力，也許早已不在意這個需求。但是產研資源也確確實實地投入進來了，他們需要一顆糖，可能不夠甜，但總比交付出去下落不明要好得多。
因此我們會要求，前線實施團隊交付新版本給客戶后，需要主動了解客戶的使用情況：有沒有用？用得怎么樣？有全面推廣起來嗎？還有其他反饋嗎？這些都要定期追蹤，了解客戶不同層級的用戶對新版本發布的新功能的想法，正向反饋負向反饋都好，都要有個交代。
通過這樣的交代，一個更加完備的產品故事應運而生，產品經理有更多的實踐素材去佐證功能的價值，架構師有更充分的底稿去應對客戶的挑戰。
四、小結
我相信不少成熟的團隊必定有自己一套完善的版本管理方法，對于客戶需求和產品能力的轉化也是運籌帷幄，對此我要恭喜你。的確，同一個問題會有很多解題的思路，我從這次的事件中也想通一個道理，那就是如何去克制把問題簡單化處理的沖動，避免陷入對觀點做取舍的二元偏誤里。
在對外和前線團隊的持續溝通中，我清楚了項目的百種不易；在對內和研發團隊的共同作戰中，我理解了產品的所思所想。如何去平衡項目和產品，讓項目驅動產品的提升，讓產品更好地服務于項目，讓原本若即若離的兩撥人匯聚成一股更強勁的力量，這是我從中體會最深的。
我想，捋完一遍思路后，我大概不需要去學怎么成為端水大師了。
#專欄作家#
健壯的大姐姐，微信公眾號：健壯的大姐姐（ID: is_strong），人人都是產品經理專欄作家。騰訊高級產品經理，專注于To B服務項目管理和行業分析，歡迎各路好漢一起探討。
本文為人人都是產品經理《原創激勵計劃》出品，未經許可，禁止轉載。
題圖來自?Unsplash，基于 CC0 協議
寫的不錯。菊廠跟你們的區別是，客戶需求的功能設計是直接由架構師（SA）出的。
大哥，產品路線圖就產品路線圖，你非要用roadmap，哎，我真是不知道該怎么說了，一定要用英文嗎
哈哈哈哈這也能成為吐槽點啊
管理版本中最大的問題不在于做哪些需求，而是什么需求要先做，這句話寫的相當精確啊，先做：意味著各方團隊利益的優先級的取舍，流程管理作者講的已經非常明白了，我想很多的公司需求實現模型應該也與此類似了。
多說一句，不管是互聯網行業還是什么行業在需求管理這一塊上，說到底還是錢多壓死人，尤其是ToB，所以在項目深入紅海競爭的時候，人力肯定是不足的，資源肯定是不夠，做好取舍，面向Money管理。
“面向Money管理”，哈哈這話有點直接了哈