做好版本迭代管理，給團隊一顆糖

作者 | 林壯壯

來源 | 健壯的大姐姐（ID: is_strong）

本文5500字左右，閱讀時間12min.

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

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

先交代下背景，在我之前的工作經(jīng)歷里，我和前線的團隊交涉比較多，銷售、售前架構(gòu)師、產(chǎn)品架構(gòu)師、服務(wù)商、ISV，都相對比較熟稔。熟稔到什么地步呢，就是他們跟我說聲hi，我都幾乎能料到他下一句話想問什么、想要什么，我可以怎么推杯換盞地應(yīng)對他們。

和他們在一條船上久了，我深諳支持項目有多不易，我理解客戶對產(chǎn)品的訴求有多急切，也愿意盡最大努力去爭取產(chǎn)品研發(fā)的資源投入。

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

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

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

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

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

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

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

可事實上，版本管理的重點不在于由產(chǎn)品研發(fā)團隊中的哪個角色來承擔，關(guā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、從團隊KPI入手：今年團隊的考核目標是什么，是產(chǎn)品收入？用戶活躍度？標桿案例數(shù)？項目的復(fù)制情況？

2、制定個人OKR：基于團隊的目標，落實到個人所負責的產(chǎn)品目標，去看在該目標下你要輸出的關(guān)鍵結(jié)果是什么。比如你們考核的是要在全國范圍內(nèi)樹立至少2個國家級標桿項目，那么對應(yīng)的這類型項目最關(guān)注的需求場景是什么，為了滿足這樣的需求場景，產(chǎn)品要實現(xiàn)哪些能力，配套提供哪些服務(wù)支持；

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

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

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

3）興奮型需求（魅力型需求）：客戶既不會過分期望，又不會明顯不滿的需求，即，有更好，沒有也能接受。比如早期海底撈向客戶推出生日當天全體員工向顧客唱生日歌，這種服務(wù)的確會讓顧客驚喜，但如果不提供這個服務(wù)，顧客也不會不滿。這類需求通常能在某些時機打動客戶，贏得客戶決策人更多的關(guān)注。

4）無差異型需求：這類需求對客戶沒有影響，有或沒有都無所謂。這種需求怎么會被人提出來呢，可能是客戶對標了不同的產(chǎn)品，或是靈光乍現(xiàn)想到的，這樣的需求在應(yīng)對的時候需要甄別，不必過分投入在這類需求上；

5）反向型需求：該需求會引起大部分人的強烈不滿，你實現(xiàn)該需求反而會降低客戶的滿意度。比如客戶管理層提出一些強管理的需求，乍一聽很合理，但深究下來，這需求對員工不友好。即便你短暫地滿足了客戶高層的需求，但長遠來看一定會收到客戶的投訴，畢竟客戶采購軟件并不僅限于在管理層使用，更多時候還是為了服務(wù)于全體員工。針對這類需求，你且緩緩，先冷靜旁觀，做好充分的客戶需求調(diào)研后，再決定是否要做。

 

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

一方面根據(jù)團隊OKR劃定產(chǎn)品方向，圈定幾個需要沖刺的功能模塊，分月度、季度去迭代功能、做項目驗證，再炮制到其他項目中落地；

另一方面擺正心態(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)師都認為自己負責的客戶提的需求最靠譜，最重要，最緊急，動輒就是“這是某位CTO提的”，“這個需求已經(jīng)上升到我司的某位高管”之類的……通往產(chǎn)品發(fā)布的管道就這么寬，全堵在這段路上，誰也動不了，誰也不想讓。

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

 

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

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

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

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

 

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

1、資源投入情況

• 項目經(jīng)理：負責整體版本規(guī)劃和需求管理，跟進版本迭代進程，對版本的整體發(fā)布負責；

• 產(chǎn)品經(jīng)理：負責產(chǎn)品需求的方案設(shè)計和評審，負責與設(shè)計、研發(fā)、測試協(xié)作開展需求的建設(shè)，對需求的實現(xiàn)情況負責；

• 研發(fā)：負責產(chǎn)品需求的技術(shù)方案設(shè)計和實現(xiàn)，把控需求的研發(fā)進度；

• 設(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有多大，取決于你如何去理解需求，如何去細化需求場景，如何打磨好你的產(chǎn)品。

 

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

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

 

2、團隊機制與過程控制

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

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

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

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

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

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

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

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

 

3、加強過程控制

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

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

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

一個是產(chǎn)品體驗環(huán)節(jié)，不少團隊在前期需求設(shè)計上嚴防死守，可一旦步入研發(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)品做出來不就是為了更好地在項目里售賣和交付嗎？沒錯，但在實際運作的過程中確實存在這樣的問題。于是你會發(fā)現(xiàn)，前線團隊對產(chǎn)品一知半解，產(chǎn)研團隊對項目一窮二白。

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

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

• 在版本規(guī)劃初期，項目經(jīng)理可以請架構(gòu)師給出有力的項目背景佐證需求的合理性；

• 在需求調(diào)研時，產(chǎn)品經(jīng)理與架構(gòu)師的深入訪談，可以更充分地了解需求場景和目標，如有必要也可以跟架構(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)研團隊有了更多的互動和融合，這是我們給到架構(gòu)師的一顆糖，它不僅提升了架構(gòu)師對產(chǎn)品的理解力，也加深了產(chǎn)研團隊對客戶的認識。

 

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

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

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

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

 

四、小結(jié)

我相信不少成熟的團隊必定有自己一套完善的版本管理方法，對于客戶需求和產(chǎn)品能力的轉(zhuǎn)化也是運籌帷幄，對此我要恭喜你。

的確，同一個問題會有很多解題的思路，我從這次的事件中也想通一個道理，那就是如何去克制把問題簡單化處理的沖動，避免陷入對觀點做取舍的二元偏誤里。

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

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

 本文由『人人都是產(chǎn)品經(jīng)理原創(chuàng)激勵計劃』出品，轉(zhuǎn)載請聯(lián)系“人人都是產(chǎn)品經(jīng)理”公眾號。

---

 推薦閱讀：

• 產(chǎn)品策劃：To B | 產(chǎn)品經(jīng)理談需求，并不可恥

• 產(chǎn)品商業(yè)化：To B產(chǎn)品商業(yè)化的真相

歡迎長按二維碼關(guān)注“健壯的大姐姐”，如果你有一點點共鳴的話歡迎點贊、“在看”或是分享給更多的朋友。

感謝閱讀，鞠躬。