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

“迭代怎么又延期了？”

“需求池的需求越來越多，什么時候能處理完?。俊?/p>

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

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

……

上述問題是否你也在年少時抱怨過，或者身邊有人這樣抱怨過？

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

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

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

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

1）長期健康、穩(wěn)定、時間可控

2）是對相關渠道來的反饋的解決

3）每次迭代的結果都要比上一次要更好、更接近目標

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

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

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

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

2.1 迭代周期的確定

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

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

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

2）迭代版本周期不宜過長（3周及以上）

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

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

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

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

2.2 需求池需求的控制

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

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

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

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

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

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

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

2.3 插入需求的處理

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 設計與開發(fā)

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

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

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

親測早會制度的好處：

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

3.3 測試及驗收

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

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

3.4 及時復盤

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

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

多問幾個為什么，為什么會發(fā)生這種問題，為什么沒有及時發(fā)現(xiàn)，為什么沒有解決，未來怎么去避免，未來怎么盡早發(fā)現(xiàn)問題。

同時整個項目組（包含自己）也需要考慮下，是因為某個人做的不夠好，環(huán)節(jié)上有疏漏，信息不全面，知識不完備，沒有責任心，還是說真的能力不夠…從各個方面去復盤這些問題，往往會有很大的成長，無論是項目、是產(chǎn)品還是個人。

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

四、注意團隊心理節(jié)奏

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

“怎么做的這么慢?。俊?/p>

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

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

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

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

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

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

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

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

總結

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

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

致讀者

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

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

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

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