產(chǎn)品迭代始于產(chǎn)品計(jì)劃，但多數(shù)情況下變化要比計(jì)劃快，造成延期，甚至多數(shù)產(chǎn)品人都遇到過(guò)這種場(chǎng)景。那么怎樣讓我們的迭代保持長(zhǎng)期健康、穩(wěn)定呢？

“迭代怎么又延期了？”

“需求池的需求越來(lái)越多，什么時(shí)候能處理完??？”

“開發(fā)一個(gè)小需求能出這么多問(wèn)題，也是醉了！”

“每次開發(fā)過(guò)程中，總會(huì)有各種各樣的需求插入，這怎么可能不延期？”

……

上述問(wèn)題是否你也在年少時(shí)抱怨過(guò)，或者身邊有人這樣抱怨過(guò)？

產(chǎn)品迭代始于產(chǎn)品計(jì)劃，但多數(shù)情況下變化要比計(jì)劃快，造成延期，甚至多數(shù)產(chǎn)品人都遇到過(guò)這種場(chǎng)景。那么怎樣讓我們的迭代保持長(zhǎng)期健康、穩(wěn)定呢？

這就需要我們培養(yǎng)一項(xiàng)專業(yè)能力：培養(yǎng)自己產(chǎn)品迭代的節(jié)奏感。感知變化、迎接變化、將變化作為我們新的計(jì)劃，做產(chǎn)品迭代的節(jié)奏大師。

一、正常迭代節(jié)奏特征

產(chǎn)品迭代的“節(jié)奏大師”，往往會(huì)讓迭代有如下特征：

1）長(zhǎng)期健康、穩(wěn)定、時(shí)間可控

2）是對(duì)相關(guān)渠道來(lái)的反饋的解決

3）每次迭代的結(jié)果都要比上一次要更好、更接近目標(biāo)

了解完成必備特征后，接下來(lái)重點(diǎn)講一下如何控制迭代節(jié)奏，減少迭代錯(cuò)亂、延期問(wèn)題的產(chǎn)生。

二、嚴(yán)格控制輸入節(jié)奏

下圖是2個(gè)小孩子在玩游戲機(jī)，我們可以看到要想完成一個(gè)游戲，需要有手柄（輸入）、處理器（處理過(guò)程）、顯示器（輸出），三者缺一不可。類比產(chǎn)品迭代，迭代完成一個(gè)版本就相當(dāng)于是輸出，而開發(fā)的過(guò)程就相當(dāng)于處理器，而迭代的周期制定和需求的管理是我們的輸入。輸入間接決定輸出的質(zhì)量，所以嚴(yán)格控制產(chǎn)品迭代的輸入，把好第一道關(guān)卡。

版本迭代的輸入目前主要來(lái)源于三個(gè)方面：迭代周期的確定、需求池需求的控制、插入需求的處理。

2.1 迭代周期的確定

依據(jù)筆者的經(jīng)驗(yàn)來(lái)看，做到以下三條最好：

1）迭代版本選擇合適的固定周期

迭代版本一般需要固定周期，固定周期能夠養(yǎng)成合理的迭代習(xí)慣，開發(fā)工作量穩(wěn)定，不會(huì)存在過(guò)度飽和與工作量不飽和的情況。

2）迭代版本周期不宜過(guò)長(zhǎng)（3周及以上）

筆者公司有的產(chǎn)品線一個(gè)月評(píng)審一次需求，每次接近20個(gè)較大需求，評(píng)審時(shí)間1天半；這就造成了開發(fā)過(guò)程中重要點(diǎn)的遺漏，以及邏輯的重新梳理，浪費(fèi)很多時(shí)間，使得不得已而延期。

3）版本周期不宜過(guò)短（1周及以下，MVP產(chǎn)品例外）

一周以下的迭代版本最怕遇到產(chǎn)品經(jīng)理本周緊急事項(xiàng)處理，耽誤了下版本需求的整理，從而使得下版本需求不飽和，造成開發(fā)工作量的降低。

最好周期是2周，使產(chǎn)品經(jīng)理能夠合理調(diào)節(jié)時(shí)間，既可以處理需求，同時(shí)也可更詳細(xì)了解需求背景，過(guò)程中也可以解決較緊急事務(wù)。

2.2 需求池需求的控制

需求池的控制主要體現(xiàn)在以下幾個(gè)方面：

1）產(chǎn)品經(jīng)理要做“需求池”，而不是“疊加池”

不要將用戶、業(yè)務(wù)部門、管理者以及數(shù)據(jù)分析得來(lái)的需求直接放入需求池中，要根據(jù)公司情況經(jīng)過(guò)某些層次的篩選才可進(jìn)入需求池，比如：與產(chǎn)品模式相違背的一定需要拋離出去。

2）需求池量化評(píng)分確定優(yōu)先級(jí)

需求少可以直接四象限進(jìn)行分類確定；需求較多時(shí)需要進(jìn)行量化評(píng)分，建立量化模型（可參考系列第一篇文章《如何創(chuàng)建需求池》），將優(yōu)先級(jí)從高到低納入版本。

3）“化整為零” && “化零為整”

學(xué)會(huì)重大版本的需求拆解與小需求的版本組合（用于優(yōu)先級(jí)評(píng)分較低，但是和本次優(yōu)先級(jí)較高需求關(guān)聯(lián)性比較大的時(shí)候，可以通過(guò)組合一起迭代）。

2.3 插入需求的處理

筆者這邊的插入需求一般來(lái)源于老板、業(yè)務(wù)部門、業(yè)務(wù)系統(tǒng)產(chǎn)品、使用用戶；對(duì)于業(yè)務(wù)部門、業(yè)務(wù)系統(tǒng)產(chǎn)品、使用用戶的需求可以直接通過(guò)需求池中需求評(píng)分量化的方式判斷是否插入，插入的話是否需要延期或者將版本中某個(gè)需求滯后。

但對(duì)于老板的插入需求可以這樣處理，一般創(chuàng)業(yè)公司和中大型公司的產(chǎn)品都可以看下：

對(duì)老板的需求要勇于說(shuō)“不”、切忌盲目說(shuō)“不”；老板給的需求一定要了解清楚，信息了解全面，確定目標(biāo)，同時(shí)保證跟老板的信息要同步。別著急否定老板，回去仔細(xì)思考。

1）若與老板想法一致，直接出解決方案；

2）若不一致，需要做模型；讓老板知道哪個(gè)地方可能存在問(wèn)題，造成的影響是什么，同時(shí)給老板一個(gè)備選的你認(rèn)為的正確方案；

3）若老板看完直接否掉，那一般只能按照他的方案走，畢竟老板作為CEO，站的角度可能不一樣。

三、把握開發(fā)版本節(jié)奏

接下來(lái)就是最重要的“處理器”，這是直接影響我們輸出的部分，所以我們會(huì)根據(jù)：產(chǎn)品需求處理、設(shè)計(jì)與開發(fā)、測(cè)試與驗(yàn)收以及復(fù)盤4大部分全鏈路講解。

3.1 產(chǎn)品需求處理

這是進(jìn)入到開發(fā)設(shè)計(jì)環(huán)節(jié)的第一步，也是最重要的一步，主要在于考察產(chǎn)品經(jīng)理的業(yè)務(wù)能力、需求分析、需求把控能力。首先通過(guò)第一部分，我們已經(jīng)對(duì)于需求池中的需求過(guò)濾且評(píng)分量化了，省掉了很多的麻煩。

下面就是我們需求細(xì)處理的過(guò)程，我們首先要把用戶原始需求轉(zhuǎn)換為我們的產(chǎn)品需求（不做細(xì)講，功底需要慢慢鍛煉），再將產(chǎn)品需求轉(zhuǎn)換為功能需求（這就是開發(fā)需要看的點(diǎn)）；最后輸出我們的需求文檔（腦圖、流程圖、原型圖、需求等）。

這一部分對(duì)于迭代節(jié)奏的把握主要是合理規(guī)劃版本需求量和減少需求的變更，表現(xiàn)在對(duì)技術(shù)邊界的理解、版本內(nèi)需求預(yù)估處理數(shù)量、思維邏輯的正確梳理、業(yè)務(wù)場(chǎng)景的窮舉、抽象轉(zhuǎn)化的能力、合理的目標(biāo)拆分能力、文檔的全面易讀性。

產(chǎn)品經(jīng)理在中途真的發(fā)現(xiàn)當(dāng)時(shí)想需求可能遺漏了知識(shí)點(diǎn)，先評(píng)估影響范圍大小，別盲目讓開發(fā)直接更改：小的納入下版本（減少產(chǎn)品頻繁變更需求的印象），大的及早整改（一步錯(cuò)，步步錯(cuò)）。

3.2 設(shè)計(jì)與開發(fā)

這是進(jìn)入到把握迭代節(jié)奏核心環(huán)節(jié)，主要是UED設(shè)計(jì)和前后端開發(fā)（數(shù)據(jù)平臺(tái)需要前端開發(fā)和大數(shù)據(jù)開發(fā)）的過(guò)程，掌握迭代節(jié)奏的掌握主要分如下6點(diǎn)：

1. 目標(biāo)同步，保持大家的口徑思想一致；在評(píng)審時(shí)不僅要講解功能，更要在可能存在疑問(wèn)的點(diǎn)上，講解業(yè)務(wù)，立足場(chǎng)景，講解目的，加深大家的理解；
2. 進(jìn)度同步，保證相關(guān)聯(lián)的崗位（UE和前端，前端和后端等）互悉、促進(jìn)進(jìn)度；昨日計(jì)劃完成、昨日實(shí)際完成、今日計(jì)劃完成；
3. 風(fēng)險(xiǎn)同步，減少和避免延期風(fēng)險(xiǎn)，根據(jù)實(shí)際情況看是否調(diào)整迭代計(jì)劃；
4. 培養(yǎng)習(xí)慣，培養(yǎng)迭代不延期、先緊后松的理念貫徹；
5. Bug控制，提高開發(fā)自測(cè)能力，減少后續(xù)測(cè)試工作量，建bug指標(biāo)監(jiān)控系統(tǒng)，通過(guò)數(shù)據(jù)看到每次的進(jìn)步；
6. 工作飽和度，為保證開發(fā)工作量飽和程度，版本間重疊2天，即負(fù)責(zé)上版本的問(wèn)題和新版本的開發(fā)。

對(duì)于開發(fā)過(guò)程中最重要的一個(gè)內(nèi)容是早會(huì)制度（站立會(huì)），這是把握開發(fā)節(jié)奏最重要的一步，建議規(guī)模10-25人使用，主要講述昨日工作內(nèi)容（建議共享文檔寫日?qǐng)?bào)，同步所有人）、今日計(jì)劃內(nèi)容、對(duì)接事項(xiàng)以及本次是否存在延期可能，輪流講述，所有人參與。

親測(cè)早會(huì)制度的好處：

1. 判斷迭代節(jié)奏是否正常，減少需求延期風(fēng)險(xiǎn)；
2. 增加團(tuán)隊(duì)溝通，心往一處想，及時(shí)糾正理解偏差；
3. 開發(fā)任務(wù)細(xì)分解，更有助于評(píng)估開發(fā)工作量（細(xì)分看本質(zhì)）；
4. 早會(huì)的作用往往比一杯“星巴克”還提神。

3.3 測(cè)試及驗(yàn)收

產(chǎn)品測(cè)試及產(chǎn)品驗(yàn)收最重要的在于本次上線核心內(nèi)容的把控，需要分清你的產(chǎn)品屬于哪個(gè)階段，屬于哪種類型，屬于什么版本，分清當(dāng)前迭代的主次。

比如：我們做偏業(yè)務(wù)較強(qiáng)B端產(chǎn)品的迭代，產(chǎn)品驗(yàn)收一般在能用（V 1.0.0）、好用（滿足業(yè)務(wù)需求）、易用（學(xué)習(xí)成本低）層次篩選，對(duì)于我們上線這個(gè)功能的第一版本，主要是邏輯走通、功能完善就好，相比之下能用占比更強(qiáng)。所以我們測(cè)試和驗(yàn)收的邏輯均保持在能用，有基礎(chǔ)的體驗(yàn)即可；不過(guò)分追求好用和易用，后者是慢慢優(yōu)化的內(nèi)容，千萬(wàn)不要把時(shí)間浪費(fèi)在了易用測(cè)試上，這樣往往得不償失。

3.4 及時(shí)復(fù)盤

希望大家能夠記住一句話：避免問(wèn)題比解決問(wèn)題更重要、更易于節(jié)奏提升！

為了避免問(wèn)題，保持正常的產(chǎn)品迭代進(jìn)度，我們需要及時(shí)復(fù)盤，不僅是對(duì)項(xiàng)目的復(fù)盤，更是對(duì)人員的復(fù)盤，對(duì)自己的復(fù)盤。這個(gè)時(shí)候不是查找問(wèn)題是誰(shuí)產(chǎn)生的，主要是尋找問(wèn)題發(fā)生的原因，以及后續(xù)怎么有效避免此類問(wèn)題。

多問(wèn)幾個(gè)為什么，為什么會(huì)發(fā)生這種問(wèn)題，為什么沒(méi)有及時(shí)發(fā)現(xiàn)，為什么沒(méi)有解決，未來(lái)怎么去避免，未來(lái)怎么盡早發(fā)現(xiàn)問(wèn)題。

同時(shí)整個(gè)項(xiàng)目組（包含自己）也需要考慮下，是因?yàn)槟硞€(gè)人做的不夠好，環(huán)節(jié)上有疏漏，信息不全面，知識(shí)不完備，沒(méi)有責(zé)任心，還是說(shuō)真的能力不夠…從各個(gè)方面去復(fù)盤這些問(wèn)題，往往會(huì)有很大的成長(zhǎng)，無(wú)論是項(xiàng)目、是產(chǎn)品還是個(gè)人。

優(yōu)秀的產(chǎn)品是迭代出來(lái)的，優(yōu)秀的人同樣也是迭代出來(lái)的！

四、注意團(tuán)隊(duì)心理節(jié)奏

最近經(jīng)常聽(tīng)到初級(jí)產(chǎn)品發(fā)牢騷：

“怎么做的這么慢啊？”

“怎么做成這樣了”“這不是我要的那樣??？”

在思考別人問(wèn)題的同時(shí)要考慮自己的問(wèn)題，也要考慮大家的情緒，本身進(jìn)入到一段開發(fā)中，大家的精神都是緊繃的，這樣就更需要一個(gè)情緒調(diào)節(jié)者，最低也是感同身受者。

無(wú)論哪種產(chǎn)品都應(yīng)該注重用戶體驗(yàn)，哪怕B端也是（注重不是著重），而是一種換位思考；用戶不僅僅是使用你產(chǎn)品的人，同樣，開發(fā)也是你的用戶。團(tuán)隊(duì)心理節(jié)奏搭建起來(lái)，那么你的迭代節(jié)奏也會(huì)是一種升華。

你應(yīng)該懂得，筆者也在第二部分說(shuō)到過(guò)，處理器是很重要的一部分，同樣開發(fā)產(chǎn)品中開發(fā)可以類比處理器，如果處理器過(guò)熱，會(huì)導(dǎo)致輸出卡頓、延遲各種現(xiàn)象，同樣，開發(fā)亦然。

不僅開發(fā)，我們需要注重整個(gè)團(tuán)隊(duì)的情緒；同時(shí)不僅要做產(chǎn)品的主人翁也要做團(tuán)隊(duì)的情緒主心骨。我們要懂得對(duì)方想什么，換位思考，這是產(chǎn)品的一項(xiàng)軟能力，通過(guò)了解對(duì)方的想法，去合理應(yīng)對(duì)每一個(gè)人。對(duì)人要以尊重為基礎(chǔ)，必要時(shí)可以“哄”，千萬(wàn)不能產(chǎn)生對(duì)立感覺(jué)（不是說(shuō)弱勢(shì)），否則只會(huì)讓你越加寸步難行（除非你是老板）。

經(jīng)過(guò)幾個(gè)月磨合，我們的團(tuán)隊(duì)整體就會(huì)很融洽，雖然評(píng)審爭(zhēng)論是避免不了的，這是常態(tài)，但那不是情緒的爭(zhēng)論，而是工作的爭(zhēng)論，讓產(chǎn)品做的更好的爭(zhēng)論！這種爭(zhēng)論往往有助于迭代節(jié)奏的提升。

【話題】當(dāng)開發(fā)給你一本《人人都是產(chǎn)品經(jīng)理》，你會(huì)不會(huì)反手就給他淘一本《21天精通C++》？

雖然是個(gè)玩笑，這個(gè)問(wèn)題也體現(xiàn)了一個(gè)人的目標(biāo)感，你的工作核心目標(biāo)到底是為了做一個(gè)好產(chǎn)品，還是為了較真，還是為了那傷身又傷心的撕逼呢？

總結(jié)

本文主要以游戲機(jī)的例子入手，詳細(xì)講解了從輸入（嚴(yán)控需求輸入）、到處理器（版本開發(fā)過(guò)程和團(tuán)隊(duì)心理建設(shè)），再到輸出（長(zhǎng)期健康、穩(wěn)定、時(shí)間可控的迭代），三方面講解了如何控制版本節(jié)奏，做產(chǎn)品迭代的節(jié)奏大師。

可能每一個(gè)部分并沒(méi)有擴(kuò)展很深，一方面考慮到各個(gè)公司可能對(duì)每一方面的做法是不一樣的，一方面是怕大家看了詳細(xì)的案例固定思維，所以筆者主要在大范圍方面進(jìn)行講解，給大家想象的留白；希望對(duì)大家思維的開闊有所幫助。

致讀者

后續(xù)定期更新《習(xí)慣養(yǎng)成記》系列文章，主要講述產(chǎn)品經(jīng)理在實(shí)際工作中各個(gè)環(huán)節(jié)方法論的總結(jié)，同時(shí)也會(huì)新增其他系列類文章（如數(shù)據(jù)、增長(zhǎng)等），可以關(guān)注作者，不錯(cuò)過(guò)任何一篇讓我們互相成長(zhǎng)的新文章。

作者：Viper；微信公眾號(hào)：產(chǎn)品經(jīng)理交流館；B端產(chǎn)品經(jīng)理，曾經(jīng)負(fù)責(zé)過(guò)海外產(chǎn)品的產(chǎn)品策劃工作，現(xiàn)負(fù)責(zé)大數(shù)據(jù)BI平臺(tái)

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

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