“版本管理”是B端產(chǎn)品最容易忽視的環(huán)節(jié)，但其異常重要。在本文中，筆者指明了版本管理的重要性，并給出了制定”科學(xué)“的版本所需要考慮的四大重點(diǎn)。

在很多產(chǎn)品經(jīng)理的頭腦中，需求調(diào)研、需求分析、產(chǎn)品設(shè)計(jì)、上線后的迭代，以及產(chǎn)品規(guī)劃等，是大家的主要工作內(nèi)容。但是在B端的產(chǎn)品迭代中，有一件非常容易被忽視，但又異常重要的事，那就是“版本管理”。

何為版本管理？版本管理的本質(zhì)是要管什么？怎么管？

在制定一個(gè)版本的具體需求內(nèi)容時(shí)，我們需要慎重考慮以下4點(diǎn)：

1. 版本目標(biāo)；
2. 版本需求和目標(biāo)的匹配關(guān)系；
3. 需求研發(fā)工作量（難度和體量）；
4. 模塊對應(yīng)的研發(fā)人員工作排期。

只有妥善了考慮了這4個(gè)問題，我們才能真正制定一個(gè)“科學(xué)”的版本。

一、為什么版本管理很重要？

1、對客戶來說：

無論是To C 還是 To B，每個(gè)版本都代表著你的產(chǎn)品外化。

新版本發(fā)布上線后，你的用戶們都會(huì)去使用、體驗(yàn)，對他們來說，一個(gè)新版本如果能解決他們之前遇到的問題，給他們帶來新的意想不到的好功能，用戶便會(huì)感到欣喜和滿意。

產(chǎn)品是公司連接客戶的核心關(guān)系鏈。產(chǎn)品好不好，客戶會(huì)直接代入到這家公司、這個(gè)品牌好不好的印象中。

所以每個(gè)版本是否能夠真正解決用戶最痛的問題，決定著這個(gè)版本的口碑，甚至影響到產(chǎn)品整體的口碑，甚至是公司和品牌的口碑。由此可見產(chǎn)品版本的重要性有多大。

2、對團(tuán)隊(duì)、產(chǎn)品來說：

一個(gè)科學(xué)有效的版本能夠給團(tuán)隊(duì)帶來正反饋的效應(yīng)；客戶在這個(gè)版本的基礎(chǔ)上能提出更多有效需求和好的產(chǎn)品建議，逐漸形成正循環(huán)效應(yīng)。而一個(gè)糟糕的版本只會(huì)引來客戶的吐槽，甚至謾罵，這些除了對團(tuán)隊(duì)有很大的自信心打擊以外，更會(huì)讓大家忙于在下個(gè)版本中加塞修復(fù)性需求，來解決這個(gè)版本所引發(fā)的問題。

在這樣的情況下，結(jié)果可想而知：原計(jì)劃下個(gè)版本的高優(yōu)先級需求就會(huì)被影響，或擱置，或延后，從而帶來一連串的連鎖反應(yīng)；若是碰上多個(gè)版本需求制定不合理的，那基本一個(gè)產(chǎn)品在短期內(nèi)會(huì)陷入無休止的做了改，改了再改的泥潭中——這對公司和團(tuán)隊(duì)來說，都是一種資源浪費(fèi)。即沒有用充足的資源產(chǎn)出有效的價(jià)值。

3、對市場來說：

我非常喜歡一個(gè)詞叫：卡位。

什么叫卡位？

簡單來說就是你比別人早做出來一個(gè)產(chǎn)品，并且獲得了市場的認(rèn)可和No1的市場份額。

舉個(gè)例子：

面對一個(gè)核心大功能（以連鎖系統(tǒng)為例），你落后你的競品2個(gè)版本才上線，而競品在2、3個(gè)月前已經(jīng)上線該功能并打出廣告：“市場上最好用的連鎖系統(tǒng)”。競品的連鎖版本推出后，產(chǎn)品口碑爆棚，那些擁有多家店的連鎖機(jī)構(gòu)喜出望外，爭相采購，因?yàn)槔_他們的連鎖管理的問題，終于有產(chǎn)品可以實(shí)質(zhì)性地解決它了。

本來屬于你的客戶會(huì)因?yàn)閷κ中掳姹镜木薮髢?yōu)勢而轉(zhuǎn)投競品家。而你本可以在3、4個(gè)月前就推出這個(gè)核心功能，這就是版本的機(jī)會(huì)成本，你推出需求A的方案，就會(huì)延后需求B的方案，而到底這個(gè)版本該先解決A，還是先解決B，決定著產(chǎn)品在階段性的市場競爭力。

在面對這種高度成熟的市場競爭時(shí)，每期版本選擇什么功能上線是產(chǎn)品能否成功卡位的關(guān)鍵。

二、優(yōu)先明確版本目標(biāo)

首先我想指出一點(diǎn)錯(cuò)誤的是，很多人上來就開始制定版本內(nèi)容了。根據(jù)需求優(yōu)先級高到低開始列，得出這個(gè)版本要做A、C、E、G。

這些高優(yōu)先級需求，對嗎？

選擇最高優(yōu)先級的需求集合到一個(gè)版本中，看似是對的，其實(shí)不然：

A屬于模塊1，C屬于模塊2，E屬于模塊3，G屬于模塊；從整體來看這些需求分屬不同的模塊，受益不同的業(yè)務(wù)，解決的是不同人群的需求，且這些需求基本都是平級的，似乎并沒有針對性？

一個(gè)版本，就好比一個(gè)產(chǎn)品，產(chǎn)品要有自己的優(yōu)勢，版本也要有自己的目標(biāo)和優(yōu)勢。

比如我們定義這期的版本就是為了解決：連鎖客戶的后臺(tái)統(tǒng)一管理多店的問題。

用一句話說清楚版本目標(biāo)，就像用一句話表達(dá)產(chǎn)品優(yōu)勢一樣，這是首先要明確的；沒有一個(gè)清晰的版本目標(biāo)，所有的行動(dòng)都是弱目標(biāo)感的，極易產(chǎn)生偏離。

三、制定版本內(nèi)容

接著就要考慮需求池中哪些需求應(yīng)該被安排到這期需求中，而這件事就要以版本目標(biāo)作為依據(jù)。

如果版本的目標(biāo)是解決連鎖客戶的后臺(tái)統(tǒng)一管理多店的問題，那么與之強(qiáng)關(guān)聯(lián)且符合高優(yōu)先級的需求應(yīng)該需要被優(yōu)先考慮。

這其中你要明確：為了達(dá)成這個(gè)目標(biāo)，你需要完成哪些需求才能真正意義上建立這個(gè)連鎖的優(yōu)勢。是A、C、E、G這些需求嗎？這些需求是否引起共振？它們是否能夠匹配版本目標(biāo)？

這些優(yōu)先級也很高的“非版本目標(biāo)需求”需要酌情調(diào)整排期，為“版本目標(biāo)需求”進(jìn)行適當(dāng)讓路。

四、需求研發(fā)工作量

這里主要包含研發(fā)難度和研發(fā)范圍（體量），往往B端產(chǎn)品一個(gè)版本合適的搭配是：1-2個(gè)相對獨(dú)立大功能+一些小功能。

為什么這么搭配？

這其中是有道理的。

一般saas系統(tǒng)的版本時(shí)間會(huì)控制在：

• 大版本：1～1.5個(gè)月；開發(fā)時(shí)間：15～30天；
• 小版本：15～20天；開發(fā)時(shí)間：7～14天。

而這么多開發(fā)時(shí)間差不多能包進(jìn)去的功能就是：1～2個(gè)相對獨(dú)立的大功能+一些小功能。

當(dāng)然我們知道每個(gè)需求對應(yīng)的研發(fā)難度和范圍邊界都不一樣，具體需要研發(fā)人員準(zhǔn)確評估后才能確定下來，但是一般經(jīng)驗(yàn)成熟的產(chǎn)品經(jīng)理大致能估算自己的需求設(shè)計(jì)所對應(yīng)的大致開發(fā)時(shí)間。

即基于工作量這個(gè)維度上，產(chǎn)品自己就可以大致合理地安排版本的功能；但是將每個(gè)版本的時(shí)間設(shè)置到2-3個(gè)月及以上，其實(shí)是不合時(shí)宜的。

目前整個(gè)市場的節(jié)奏都是偏快的：競品的迭代速度很快；客戶的業(yè)務(wù)發(fā)展很快；新需求的爆發(fā)很快。所以2-3個(gè)月的版本速度并不能很好地適應(yīng)現(xiàn)在的市場環(huán)境。

五、關(guān)于研發(fā)人員的工作排期

隨著現(xiàn)在微服務(wù)化大行其道，很多saas系統(tǒng)的研發(fā)團(tuán)隊(duì)都會(huì)根據(jù)產(chǎn)品進(jìn)行模塊拆分，并安排相應(yīng)的研發(fā)人員專門負(fù)責(zé)1～N個(gè)模塊地開發(fā)和維護(hù)。

這就帶來一個(gè)什么問題？核心模塊，或者和其他模塊多耦合的模塊，在每個(gè)版本、每個(gè)需求設(shè)計(jì)中，幾乎都會(huì)涉及到。這就導(dǎo)致了業(yè)務(wù)關(guān)系較為復(fù)雜的模塊的研發(fā)工作量非常大，而其他一些非核心模塊的研發(fā)工作量就會(huì)來的比較間歇性，相對較少。

如果一個(gè)版本的需求對應(yīng)的模塊都集中在了A、B兩個(gè)模塊，那么負(fù)責(zé)A、B模塊的研發(fā)就會(huì)忙死，而負(fù)責(zé)C、D、E模塊的開發(fā)就會(huì)空死——這其實(shí)也是非常不合理的，不利于資源的優(yōu)化配置。

所以在考慮完上述3點(diǎn)后，還要考慮這個(gè)比較現(xiàn)實(shí)的下游團(tuán)隊(duì)的工作安排問題。

可能很多產(chǎn)品經(jīng)理覺得：這不是開發(fā)做的事嗎？跟我有什么關(guān)系？

換個(gè)角度，如果版本需求提交給研發(fā)后，因?yàn)檫@個(gè)原因?qū)е滦枨蟊淮蚧兀阍僦匦逻M(jìn)行版本規(guī)劃，無疑是double了工作量。

六、敏捷迭代

敏捷迭代，換個(gè)通俗易懂的詞來說就是：小步快跑——通過1-4周小版本的迭代來快速地完善產(chǎn)品，并投放市場進(jìn)行驗(yàn)證，繼而收集市場需求再進(jìn)行快速迭代。

其實(shí)這個(gè)好處大家是比較容易理解的，說白了就是我先不投入全部精力，我把一個(gè)長周期拆分成一個(gè)個(gè)小周期，做完一個(gè)小周期，看一下效果，再做完一個(gè)小周期，再看下效果，不斷地去修正上個(gè)小周期的設(shè)想，最終讓產(chǎn)品逐漸走向正確的方向。

相比那些動(dòng)不動(dòng)做上一年半載的版本迭代，敏捷迭代可以讓整個(gè)迭代過程更加可控，讓每個(gè)小周期的沉沒成本變得更小，這非常像馬克思主義哲學(xué)中的理論和實(shí)踐的關(guān)系。

當(dāng)然敏捷迭代之所以非?；?，還有一個(gè)很重要的原因是：時(shí)代變快了。

快速發(fā)展的時(shí)代導(dǎo)致快速變化的需求，繼而對產(chǎn)品的變化要求也越來越快，而敏捷恰恰迎合了這樣一種市場節(jié)奏。

那么，我們每個(gè)版本都該用敏捷迭代嗎？

其實(shí)這個(gè)問題沒有唯一答案，可能不需要用，可能每個(gè)版本都用，可能穿插著用——對每家企業(yè)、每條業(yè)務(wù)、每個(gè)團(tuán)隊(duì)來說都需要綜合考量。

如何決策？

版本的目標(biāo)是第一原因，如果這個(gè)版本目標(biāo)非常宏大，必然需要聚合2-3個(gè)大功能，那么就不可能把版本周期壓縮的很小，而為了敏捷丟失版本目標(biāo)，其實(shí)是非常愚蠢的。

七、結(jié)尾

在制定一個(gè)版本的具體需求內(nèi)容時(shí)，我們需要慎重考慮以下4點(diǎn)：

1. 版本目標(biāo)；
2. 版本需求和目標(biāo)的匹配關(guān)系；
3. 需求研發(fā)工作量（難度和體量）；
4. 模塊對應(yīng)的研發(fā)人員工作排期。

你學(xué)會(huì)了嗎？

#專欄作家#

司馬特小隊(duì)，公眾號(hào)：司馬特小分隊(duì)，人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗(yàn)，多年B端產(chǎn)品管理經(jīng)驗(yàn)。具有多個(gè)從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗(yàn)；主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關(guān)的硬核知識(shí)點(diǎn)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

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