微信節奏大師(微信節奏大師怎么下載)

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

“迭代怎么又延期了？”

“需求池的需求越來越多，什么時候能處理完啊？”

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

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

……

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

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

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

一、正常迭代節奏特征

產品迭代的“節奏大師”，往往會讓迭代有如下特征：

1）長期健康、穩定、時間可控

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

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

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

二、嚴格控制輸入節奏

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

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

2.1 迭代周期的確定

依據筆者的經驗來看，做到以下三條最好：

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

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

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

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

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

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

最好周期是2周，使產品經理能夠合理調節時間，既可以處理需求，同時也可更詳細了解需求背景，過程中也可以解決較緊急事務。

2.2 需求池需求的控制

需求池的控制主要體現在以下幾個方面：

1）產品經理要做“需求池”，而不是“疊加池”

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

2）需求池量化評分確定優先級

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

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

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

2.3 插入需求的處理

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

但對于老板的插入需求可以這樣處理，一般創業公司和中大型公司的產品都可以看下：

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

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

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

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

三、把握開發版本節奏

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

3.1 產品需求處理

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

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

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

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

3.2 設計與開發

這是進入到把握迭代節奏核心環節，主要是UED設計和前后端開發（數據平臺需要前端開發和大數據開發）的過程，掌握迭代節奏的掌握主要分如下6點：

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

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

親測早會制度的好處：

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

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

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

3.4 及時復盤

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

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

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

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

優秀的產品是迭代出來的，優秀的人同樣也是迭代出來的！

四、注意團隊心理節奏

最近經常聽到初級產品發牢騷：

“怎么做的這么慢啊？”

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

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

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

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

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

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

【話題】當開發給你一本《人人都是產品經理》，你會不會反手就給他淘一本《21天精通C++》？

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

總結

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

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

致讀者

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

作者：Viper；微信公眾號：產品經理交流館；B端產品經理，曾經負責過海外產品的產品策劃工作，現負責大數據BI平臺

本文由 @Viper 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議