#本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品。

在團(tuán)隊工作中，產(chǎn)品經(jīng)理需要身兼多職、兼顧多方意見。而產(chǎn)品版本迭代管理往往需要牽扯項目的多方面。那么，當(dāng)產(chǎn)品經(jīng)理著手版本迭代管理工作時，應(yīng)當(dāng)如何協(xié)調(diào)團(tuán)隊工作、做好過程控制、進(jìn)而凝聚團(tuán)隊力量？本文作者便結(jié)合其自身經(jīng)驗向我們做出了清晰展示。

自春節(jié)到現(xiàn)在，我陷入一種困境里：突然間，我好像成了“夾心餅干”？

事情是這樣的，由于業(yè)務(wù)變動，最近我開始負(fù)責(zé)一個核心產(chǎn)品的版本迭代管理。我敞開心扉擁抱變化，但兩個月下來，事情比我想象中得更棘手。

先交代下背景。

在我之前的工作經(jīng)歷里，我和前線的團(tuán)隊交涉比較多，銷售、售前架構(gòu)師、產(chǎn)品架構(gòu)師、服務(wù)商、ISV，都相對比較熟稔。熟稔到什么地步呢，就是他們跟我說聲hi，我都幾乎能料到他下一句話想問什么、想要什么，我可以怎么推杯換盞地應(yīng)對他們。和他們站在同一條船上久了，我深諳支持項目有多不易，我理解客戶對產(chǎn)品的訴求有多急切，也愿意盡最大努力去爭取產(chǎn)品研發(fā)的資源投入。

但是，一切開始不一樣了。自打我接手產(chǎn)品研發(fā)工作，開始負(fù)責(zé)產(chǎn)品整體規(guī)劃和版本迭代管理后，我多了一重身份。隨著我深入了解產(chǎn)品的細(xì)節(jié)，了解看似簡單實則不易的需求背后沉淀了這么多研發(fā)、測試的人力后，我不得不站出來為產(chǎn)品研發(fā)團(tuán)隊說說話了。

這也就導(dǎo)致，我清楚客戶需求的合理性和迫切性，但我也在警惕產(chǎn)品研發(fā)資源的不合理占用。于項目團(tuán)隊而言，作為產(chǎn)品接口人的我開始謹(jǐn)慎承諾，小心防守；于研發(fā)團(tuán)隊而言，作為項目經(jīng)理的我抱著一攬子需求回來，生怕我獅子大開口。

里外不是人了不是？我反思過，是不是該去學(xué)一學(xué)怎么端水？

把情緒放一放，我給自己一個版本的試煉機(jī)會，也趁此摸清楚了項目支持和產(chǎn)品管理的平衡之術(shù)。

我和其他團(tuán)隊的產(chǎn)品經(jīng)理聊了下，有些同學(xué)一開始就是走產(chǎn)品策劃路線，始終站在產(chǎn)研的角度，專心琢磨如何讓產(chǎn)品做得更好；有些同學(xué)一直都是在客戶現(xiàn)場，或是出差去現(xiàn)場的路上，他懂行懂客戶，能根據(jù)客戶需求擬制解決方案。

其中不乏有產(chǎn)品經(jīng)理負(fù)責(zé)版本迭代管理，但總會遇到各種各樣的問題：怎么去權(quán)衡各大項目反饋的需求優(yōu)先級？怎么應(yīng)對空降的需求帶來的資源占用？怎么讓前線團(tuán)隊放心、讓研發(fā)團(tuán)隊齊心呢？

不少團(tuán)隊都傾向于將產(chǎn)品研發(fā)管理專門交給項目經(jīng)理去負(fù)責(zé)，由項目經(jīng)理協(xié)調(diào)產(chǎn)品、設(shè)計、研發(fā)、測試的資源，并跟進(jìn)整體版本迭代的進(jìn)展。這的確權(quán)責(zé)分明，產(chǎn)品做需求，開發(fā)寫代碼，各司其職，何樂而不為？

可事實上，版本管理的重點不在于由產(chǎn)品研發(fā)團(tuán)隊中的哪個角色來承擔(dān)，關(guān)鍵在于如何去管理這個版本。既然團(tuán)隊內(nèi)暫時沒有這樣的角色來支撐，那么我大可以利用自己的多重身份“夾帶私貨”，不是嗎？

一、不僅是規(guī)劃版本

規(guī)劃版本前先規(guī)劃產(chǎn)品roadmap。

為什么前線項目組總是源源不斷地投遞需求——我要斬斷不重要不緊急的客戶需求。

為什么研發(fā)同學(xué)總是下意識拒絕需求——我要調(diào)動產(chǎn)研資源實現(xiàn)優(yōu)先級最高的產(chǎn)品能力。

從客戶需求到產(chǎn)品能力之間是有Gap的，我要搭橋造梁，就需要一個支撐。

那么，怎么規(guī)劃產(chǎn)品的階段性里程碑？

1. 從團(tuán)隊KPI入手

今年團(tuán)隊的考核目標(biāo)是什么，是產(chǎn)品收入？用戶活躍度？標(biāo)桿案例數(shù)？項目的復(fù)制情況？

2. 制定個人OKR

基于團(tuán)隊的目標(biāo)，落實到個人所負(fù)責(zé)的產(chǎn)品目標(biāo)，去看在該目標(biāo)下你要輸出的關(guān)鍵結(jié)果是什么。

比如你們考核的是要在全國范圍內(nèi)樹立至少2個國家級標(biāo)桿項目，那么對應(yīng)的這類型項目最關(guān)注的需求場景是什么；為了滿足這樣的需求場景，產(chǎn)品要實現(xiàn)哪些能力、配套提供哪些服務(wù)支持。

3. KANO模型

這是東京理工大學(xué)教授狩野紀(jì)昭（Noriaki Kano）發(fā)明的對用戶需求分類和優(yōu)先排序的工具，需求分五類：基本型需求、期望型需求、興奮型需求、無差異型需求、反向型需求。

① 基本型需求（必備型需求）

客戶認(rèn)為必須有，沒有的話這個功能就不具有交付意義的需求。

針對這類需求，一旦你沒滿足客戶，客戶的滿意度將一落千丈，你可能馬上就要被踢出局。比如顧客買一個保溫杯，它能正常裝熱水，顧客不會為此感到滿意；但如果這杯子有裂縫，杯蓋擰不緊，或是保溫效果差，那么顧客對這個杯子的滿意度就會明顯下降，投訴接踵而至。

② 期望型需求

客戶期望你可以實現(xiàn)的需求，一旦你實現(xiàn)了，客戶滿意度會顯著提升，你提供的產(chǎn)品超出客戶期望越多，客戶就越滿意。

但相應(yīng)的，如果你拒絕滿足客戶需求或是表現(xiàn)不好的話，客戶也會立馬提出不滿。比如客戶期望貴司提供的問題響應(yīng)機(jī)制可以更快捷、故障處理可以更高效，那么一旦你優(yōu)化了問題處理流程，提高對客戶的響應(yīng)效率，客戶就越滿意。

③ 興奮型需求（魅力型需求）

客戶既不會過分期望，又不會明顯不滿的需求，即，有更好，沒有也能接受。

比如早期海底撈向客戶推出生日當(dāng)天全體員工向顧客唱生日歌，這種服務(wù)的確會讓顧客驚喜，但如果不提供這個服務(wù)，顧客也不會不滿。這類需求通常能在某些時機(jī)打動客戶，贏得客戶決策人更多的關(guān)注。

④ 無差異型需求

這類需求對客戶沒有影響，有或沒有都無所謂。

這種需求怎么會被人提出來呢，可能是客戶對標(biāo)了不同的產(chǎn)品，或是靈光乍現(xiàn)想到的，這樣的需求在應(yīng)對的時候需要甄別，不必過分投入在這類需求上。

⑤ 反向型需求

該需求會引起大部分人的強(qiáng)烈不滿，你實現(xiàn)該需求反而會降低客戶的滿意度。

比如客戶管理層提出一些強(qiáng)管理的需求，乍一聽很合理，但深究下來，這需求對員工不友好。即便你短暫地滿足了客戶高層的需求，但長遠(yuǎn)來看一定會收到客戶的投訴，畢竟客戶采購軟件并不僅限于在管理層使用，更多時候還是為了服務(wù)于全體員工。

針對這類需求，你且緩緩，先冷靜旁觀，做好充分的客戶需求調(diào)研后，再決定是否要做。

根據(jù)上述三方面，在實際規(guī)劃產(chǎn)品藍(lán)圖時，可以從以下兩方面去考慮：

1. 一方面根據(jù)團(tuán)隊OKR劃定產(chǎn)品方向，圈定幾個需要沖刺的功能模塊，分月度、季度去迭代功能、做項目驗證，再炮制到其他項目中落地；
2. 另一方面擺正心態(tài)，正視客戶反饋的需求，全力以赴滿足基本型需求，重視產(chǎn)品義務(wù)范疇內(nèi)的事項，確保在市場競爭中不丟分。同時，盡力去滿足客戶的期望型需求，提供大多數(shù)客戶關(guān)注的額外服務(wù)和產(chǎn)品，引導(dǎo)客戶的決策鏈對本產(chǎn)品有更多的傾向性；最后才是爭取實現(xiàn)客戶的興奮型需求，提高客戶用戶的粘性和復(fù)購率。

你看，通過層層過濾，你會發(fā)現(xiàn)有不少客戶需求其實沒那么重要，它并不能為產(chǎn)品的銷售有什么催化作用，甚至在占用產(chǎn)研資源后還討不到一點好處。

二、不僅是管理版本

前文提到如何在規(guī)劃版本前規(guī)劃好產(chǎn)品階段性的里程碑，圍繞里程碑去規(guī)劃每個月的版本內(nèi)容和版本節(jié)奏。

但實際上在管理版本中最大的問題不在于做哪些需求，而是什么需求要先做。每一位架構(gòu)師都認(rèn)為自己負(fù)責(zé)的客戶提的需求最靠譜、最重要、最緊急，動輒就是“這是某位CTO提的”、“這個需求已經(jīng)上升到我司的某位高管”之類的……通往產(chǎn)品發(fā)布的管道就這么寬，全堵在這段路上，誰也動不了，誰也不想讓。

這時候除了根據(jù)KANO模型對需求做一層初步的分類之后，每個類目下依然存在不少需求，怎么排優(yōu)先級？

向外看，競爭對手相比你的優(yōu)勢在哪？它推崇的關(guān)鍵控標(biāo)點有什么？研究競品并不可恥，市場就這么大，池子里的魚就這么多，為了捕獲更多的獵物，取長補(bǔ)短也是順理成章的。

向內(nèi)看，你不必把這份責(zé)任全部放在自己身上，建立版本評審委員會，邀請領(lǐng)導(dǎo)、產(chǎn)品和研發(fā)負(fù)責(zé)人、前線反饋需求的架構(gòu)師，共同來評審這些需求的優(yōu)先級。通過責(zé)任公攤和事務(wù)公開，形成一個集體公認(rèn)的版本需求池。

在需求池初具雛形后，你要及時組織產(chǎn)品研發(fā)團(tuán)隊開版本啟動會，宣導(dǎo)需求池里的所有需求，請產(chǎn)品和研發(fā)初步給出工作量的預(yù)估。一個版本迭代的周期就這么長的時間，對于比較復(fù)雜的需求，適時地拉長陣線去細(xì)化產(chǎn)品方案，才能確保不浪費研發(fā)的資源。

記住，排優(yōu)先級時，不可只關(guān)注客戶需求而忽視了去建設(shè)能滿足更多客戶的核心優(yōu)勢。

在明確版本需求和需求的優(yōu)先級后，我們再來看下如何調(diào)動資源投入到版本迭代。

1. 資源投入情況

• 項目經(jīng)理：負(fù)責(zé)整體版本規(guī)劃和需求管理，跟進(jìn)版本迭代進(jìn)程，對版本的整體發(fā)布負(fù)責(zé)；
• 產(chǎn)品經(jīng)理：負(fù)責(zé)產(chǎn)品需求的方案設(shè)計和評審，負(fù)責(zé)與設(shè)計、研發(fā)、測試協(xié)作開展需求的建設(shè)，對需求的實現(xiàn)情況負(fù)責(zé)；
• 研發(fā)：負(fù)責(zé)產(chǎn)品需求的技術(shù)方案設(shè)計和實現(xiàn)，把控需求的研發(fā)進(jìn)度；
• 設(shè)計：完成需求UI設(shè)計和視覺設(shè)計，輸出設(shè)計切圖；
• 測試：輸出測試用例，把控需求的質(zhì)量。

這些角色在參與版本迭代時都有各自的期望，在不同的環(huán)節(jié)里都需要換位思考下。

比如研發(fā)，最怕產(chǎn)品方案沒考慮完全就火急火燎地找上來要技術(shù)實現(xiàn)，前期方案的不周全大概率會引發(fā)后期需求的變更，這對研發(fā)而言就是資源的浪費。

那么站在研發(fā)的角度，產(chǎn)品經(jīng)理對待需求就不能只是在講一個簡單的用戶故事，客戶需求和產(chǎn)品能力之間的gap有多大，取決于你如何去理解需求、如何去細(xì)化需求場景、如何打磨好你的產(chǎn)品。

相應(yīng)的，在版本迭代的過程中，項目經(jīng)理預(yù)留給產(chǎn)品經(jīng)理思考方案的時間要充分，不能為了滿足更多的需求而忽視了產(chǎn)品的細(xì)節(jié)。產(chǎn)品不可只看細(xì)節(jié)，也不可全然不顧細(xì)節(jié)。

不注重各個方面的細(xì)節(jié)，終究會連累到之前積累的口碑；當(dāng)所有人都盯著你缺的那一筐土的時候，沒有人會關(guān)心已經(jīng)堆好的九仞土山。

2. 團(tuán)隊機(jī)制與過程控制

既然是一個長期工程，那么何不如從一開始就下功夫定流程，定機(jī)制，把涉及到的角色的工作地圖畫出來？

前面提到，我給自己一個版本的時間窗，去印證這個團(tuán)隊機(jī)制的可行性。具體流程是什么樣呢？

1）明確版本節(jié)奏

一個半月2個小版本1個大版本（ab為小版本，c為大版本），小版本內(nèi)部測試體驗，大版本對外正式發(fā)布。

2）規(guī)范迭代流程

① 建立版本評審委員會，從版本規(guī)劃開始，做好向上匯報和對內(nèi)同步，保證信息公開透明。沒錯，你是版本總體負(fù)責(zé)人，但你沒必要把很多責(zé)任往自己身上攬，尤其涉及到需要上升決策的事情，分?jǐn)傌?zé)任也同樣是在分?jǐn)傦L(fēng)險。

② 版本需求確定后，預(yù)留充分的時間給到產(chǎn)品經(jīng)理調(diào)研需求、設(shè)計產(chǎn)品方案，并樹立一個標(biāo)桿性事件：開展版本啟動會。由各產(chǎn)品經(jīng)理大體宣講需求，明確需求的研發(fā)負(fù)責(zé)人，全員投票評估需求的合理性和可行性。

③ 需求進(jìn)一步得到產(chǎn)品和研發(fā)的評估后，產(chǎn)品和研發(fā)負(fù)責(zé)人各自組成feature team，啟動對需求的實現(xiàn)之路，再配合設(shè)計、測試的資源，讓需求在版本發(fā)布計劃的時間窗內(nèi)有序地推進(jìn)，并適時地同步進(jìn)展和風(fēng)險，確保需求相關(guān)人對需求的理解是一致的。

3）加強(qiáng)過程控制

流程是有了，但流程里涉及到的環(huán)節(jié)比較多，需要抓住最關(guān)鍵的部分加強(qiáng)管控。

一個是需求評審環(huán)節(jié)，這決定了這個需求后續(xù)的實現(xiàn)路徑，絕不能輕視。對于相對復(fù)雜且重要的需求，對于空降的高優(yōu)先級需求，能不能插隊也不是研發(fā)或產(chǎn)品或架構(gòu)師說了算，都必須嚴(yán)格上升到版本評審委員會共同決議。

一個是研發(fā)排期環(huán)節(jié)，版本的發(fā)布時間窗是基本固定的，研發(fā)排期的評估除了根據(jù)需求的優(yōu)先級、實現(xiàn)的工作量之外，還要根據(jù)發(fā)布計劃的時間點看能趕上哪一個發(fā)布計劃，以確保給客戶承諾的交付時間是相對可靠的。

一個是產(chǎn)品體驗環(huán)節(jié)，不少團(tuán)隊在前期需求設(shè)計上嚴(yán)防死守，可一旦步入研發(fā)階段，產(chǎn)品經(jīng)理除了間或響應(yīng)研發(fā)的問題咨詢外，對需求本身的實現(xiàn)過程和實現(xiàn)結(jié)果是有點輕視的。

這里需要尤其重視需求研發(fā)完成后的產(chǎn)品體驗環(huán)節(jié)，產(chǎn)品經(jīng)理必須完整地按測試用例走查一遍功能，確保最終的功能與最初需求的設(shè)計是契合的。若有偏差，是否要變更或追加需求，則同樣需要引入版本評審委員會（與該需求相關(guān)的人員）一起來評估。

三、不僅是一顆糖

產(chǎn)品如期發(fā)布了，這時候我對前線的架構(gòu)師是否就有了交代？不夠。

回想下，架構(gòu)師對產(chǎn)品的能力是清晰的嗎？他們提的客戶需求為什么在不少產(chǎn)品研發(fā)同學(xué)看來不太合理呢？歸根結(jié)底是因為項目支持和產(chǎn)品建設(shè)脫節(jié)了。

兩撥人，一撥人忙著做項目，一撥人忙著做需求，各自作戰(zhàn)，各自為政。

你可能會說，產(chǎn)品做出來不就是為了更好地在項目里售賣和交付嗎？沒錯，但在實際運(yùn)作的過程中確實存在這樣的問題。于是你會發(fā)現(xiàn)，前線團(tuán)隊對產(chǎn)品一知半解，產(chǎn)研團(tuán)隊對項目一窮二白。

這是常態(tài)，但可以被改變。

回過頭來看整個版本迭代流程，你會發(fā)現(xiàn)有很多環(huán)節(jié)完全可以借助前線架構(gòu)師的力量。

• 在版本規(guī)劃初期，項目經(jīng)理可以請架構(gòu)師給出有力的項目背景佐證需求的合理性；
• 在需求調(diào)研時，產(chǎn)品經(jīng)理與架構(gòu)師的深入訪談，可以更充分地了解需求場景和目標(biāo)，如有必要也可以跟架構(gòu)師一起拜訪客戶；
• 在需求研發(fā)完成轉(zhuǎn)產(chǎn)品體驗時，產(chǎn)品經(jīng)理邀請架構(gòu)師一起體驗功能，確保功能的效果與架構(gòu)師的預(yù)期一致；
• 在產(chǎn)品發(fā)布后，產(chǎn)品經(jīng)理可以請架構(gòu)師一同編制功能故事，描述功能的操作路徑、實現(xiàn)效果和價值，以便客戶更好地使用功能。

整個過程里，前線架構(gòu)師與產(chǎn)研團(tuán)隊有了更多的互動和融合，這是我們給到架構(gòu)師的一顆糖，它不僅提升了架構(gòu)師對產(chǎn)品的理解力，也加深了產(chǎn)研團(tuán)隊對客戶的認(rèn)識。

同樣的，產(chǎn)品發(fā)布后交付給到客戶后，這時候我對產(chǎn)研團(tuán)隊是否就有了交代？不夠。

很多時候一個新版本從規(guī)劃到發(fā)布，一個多月過去了。這一個月期間，客戶也許還在追著要這個能力，也許早已不在意這個需求。但是產(chǎn)研資源也確確實實地投入進(jìn)來了，他們需要一顆糖，可能不夠甜，但總比交付出去下落不明要好得多。

因此我們會要求，前線實施團(tuán)隊交付新版本給客戶后，需要主動了解客戶的使用情況：有沒有用？用得怎么樣？有全面推廣起來嗎？還有其他反饋嗎？這些都要定期追蹤，了解客戶不同層級的用戶對新版本發(fā)布的新功能的想法，正向反饋負(fù)向反饋都好，都要有個交代。

通過這樣的交代，一個更加完備的產(chǎn)品故事應(yīng)運(yùn)而生，產(chǎn)品經(jīng)理有更多的實踐素材去佐證功能的價值，架構(gòu)師有更充分的底稿去應(yīng)對客戶的挑戰(zhàn)。

四、小結(jié)

我相信不少成熟的團(tuán)隊必定有自己一套完善的版本管理方法，對于客戶需求和產(chǎn)品能力的轉(zhuǎn)化也是運(yùn)籌帷幄，對此我要恭喜你。的確，同一個問題會有很多解題的思路，我從這次的事件中也想通一個道理，那就是如何去克制把問題簡單化處理的沖動，避免陷入對觀點做取舍的二元偏誤里。

在對外和前線團(tuán)隊的持續(xù)溝通中，我清楚了項目的百種不易；在對內(nèi)和研發(fā)團(tuán)隊的共同作戰(zhàn)中，我理解了產(chǎn)品的所思所想。如何去平衡項目和產(chǎn)品，讓項目驅(qū)動產(chǎn)品的提升，讓產(chǎn)品更好地服務(wù)于項目，讓原本若即若離的兩撥人匯聚成一股更強(qiáng)勁的力量，這是我從中體會最深的。

我想，捋完一遍思路后，我大概不需要去學(xué)怎么成為端水大師了。

#專欄作家#

健壯的大姐姐，微信公眾號：健壯的大姐姐（ID: is_strong），人人都是產(chǎn)品經(jīng)理專欄作家。騰訊高級產(chǎn)品經(jīng)理，專注于To B服務(wù)項目管理和行業(yè)分析，歡迎各路好漢一起探討。

本文為人人都是產(chǎn)品經(jīng)理《原創(chuàng)激勵計劃》出品，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自?Unsplash，基于 CC0 協(xié)議