產品周期化迭代的流程和注意事項

1、產品周期化迭代的流程和注意事項當產品基礎框架開發(fā)完成，進入成熟期后，產品的周期化迭代就變得非 常重要。所謂產品迭代，就是在一定時間內，對該產品一定量的新需求加以 評估、篩選、開發(fā)、測試以及上線的一系列行為的總稱。而產品迭代的周期 化，即是指固定產品迭代的流程，一般為一到兩周。那么，為什么要進行周期化的產品迭代呢？這是因為，固定的周期有助 于為項目團隊形成規(guī)范，從而提高開發(fā)效率。如果迭代被周期所限制，那么 團隊就會被引導去選擇一個能與這個周期長度相適應的開發(fā)量，而不是盲目增加需求或放不開手腳。而在固定周期內，當確定開發(fā)量時，我們經常需要對一定量的需求進行篩選，固定不變的周期可以幫助我們逐漸找到適

2、合自己的節(jié)奏，也可以幫助我們對需求進行優(yōu)先級排序。此外，固定的迭代周期還有助于在整個迭代過 程中，加強項目團隊的時間觀念，從而形成規(guī)范，比如周一主要由誰來做什 么工作，周二由誰來做什么工作，以此類推。在產品迭代的流程中，產品經理其實更多地扮演了項目經理的角色，需 要跟進整個迭代的進度，也需要及時協(xié)調各方資源，保證迭代成功進行。我 個人認為，產品經理作為產品的“爹”，作為對產品直接負責的角色，跟進 產品的開發(fā)和測試本來就無可厚非。 具備必要的項目管理能力，不應該是產 品經理的加分項，而應該是對其最低限度的要求。F F 面我們簡單梳理下一個固定周期中，產品進行迭代的流程。1.1. 需求初定先由產品

3、經理從需求池當中取出部分需求，作為本周期內需要開發(fā)的內 容，并進行優(yōu)先級排序，一般 POPO、P1P1、P2P2 三級即可。優(yōu)先級分類太多，很 容易導致在不同需求的優(yōu)先級排序上造成不必要的時間浪費。排序完成后， 產品經理還可以先預估一下開發(fā)成本， 如果感覺開發(fā)負擔太重，那么就有必 要砍掉一些優(yōu)先級或投入產出比低的需求。2.2. 需求評估召集設計同學、技術同學和測試同學，進行本周期的需求評估，以確定 最終的開發(fā)內容，以及各部門工作的排期。這部分流程最好能通過一次稍微 正式些的會議來進行。在會議這種正式場合上，大家表達意見一般都是經過 認真思考的，給出排期時也會較為謹慎，而且有利于形成規(guī)范。會議結

4、束后， 可以發(fā)一封郵件給整個項目團隊，說明會議內容與排期確定情況，越詳細越 好。這樣將項目流程初步落實到紙面上， 一定程度上可以防止迭代規(guī)劃流于 空談。3.3. 需求落地（設計與開發(fā)）這是一個至關重要的環(huán)節(jié)，直接決定著本周期內的需求迭代能否成功。在上一個流程即需求評估階段， 我們已經確定了最終的開發(fā)內容， 但這并不 代表迭代進入這個階段后我們就沒事可做了。作為產品經理，我們在產品生命周期的每一個階段，都需要保持活躍。而這個階段我們需要做的，就是跟 進產品的設計、開發(fā)進度，以保證產品能夠在擬定的期限內開發(fā)完成，達到 可測試水平。不過，“跟進”并不等于“監(jiān)督”，我們是產品經理而不是包工頭。不需要整

5、天跟在設計和技術同學后頭問“ XXXX 需求做得怎么樣了”，一方面無 益于項目的實際進度，另一方面也會讓別人覺得你自身能力不夠， 卻只會一 味要求別人，從而影響到你們在項目當中的合作。4.4. 需求測試在這個環(huán)節(jié)，我們要將本周期內開發(fā)完成的需求全部提交測試。需求測試分為兩部分，第一部分是產品經理自測整體邏輯， 也就是說不需要關注細 節(jié)與極限問題，只要邏輯總體上沒有問題，此部分測試便可通過。第二部分 是提交 QAQA 測試，簡稱“提測”。與需求落地環(huán)節(jié)一樣，這個階段中的產品 經理看似無事可做，實則不可或缺。我們需要跟進測試進度，在測試同學對 提測內容和邏輯有疑問時，需要及時解答。5.5. 產品上

6、線到需求測試為止的工作全部完成，即意味著本周期內需要開發(fā)的需求已經全部實現，且沒有任何問題，產品可以上線。不過上線后，產品經理還需 要進行一次線上回測，最大限度地確保產品不存在任何問題。 如果不幸測試 出了在測試環(huán)節(jié)未能及時發(fā)現的 BUGBUG, 定要第一時間提給技術同學去修 復，未能修復的也需要告知運營同學， 并協(xié)助運營同學做好對用戶的解釋與 安撫工作。產品上線標志著一個迭代周期的結束， 同時也意味著產品經理需 要開始梳理下一個周期的迭代內容。我們可以看到，一個產品的迭代實際上是循環(huán)往復不間斷的。要在連續(xù)更替的迭代周期當中做好每一個階段的工作也不是一件容易的事情。那么我們來梳理一些需要注意的

7、事項，希望能在產品迭代過程當中對大家有些幫助。1 1 科學設置迭代周期長度產品迭代一般是以周為單位， 每個周期為一到兩周。 這樣的時間設置最 為接地氣，也最為科學，短于一周，分配給各個環(huán)節(jié)的時間都太緊，會導致 各項工作都草草了事。長于兩周，各個環(huán)節(jié)的工作在時間上難以把控，很容 易造成迭代不能如期完成，難以形成穩(wěn)定有效的規(guī)范。2.2.將信息傳達落實到位任何工作能落實到紙面上，盡量落實，并讓大家周知。例如，每次需求 評審都使用原型與文檔輔助講解；會議記錄整理后用郵件發(fā)出；BUGBUG 通過jirajira 等項目管理應用統(tǒng)一提出等等，一方面避免了口頭溝通易忘的風險，可 以幫助各部門同學記住重要信息

8、， 另一方面也可以借此規(guī)范迭代流程， 明確 各自責任，防止出現問題時互相推諉的現象發(fā)生。而且，落實到紙面上的信息，比如已經確定的產品策略、開發(fā)排期等等， 如非極其特殊的情況，盡量不要更改。即使只更改過一次，也會讓其他部門 同學覺得“這個產品經理不靠譜，已經敲定的事還變來變去”，從而讓紙面 上的規(guī)定失去效力。嚴重者甚至會引發(fā)團隊間的信任危機， 對以后的周期化 迭代絕對是有弊無利的。3.3.優(yōu)雅地跟進項目進度前面我們說到了，對其他部門工作的跟進，不等于監(jiān)督他們的工作，即 沒必要整天追著設計和技術同學問“ XXXX 需求怎么樣了”。那么我們該如何 做，既不讓他們感到厭煩，還能隨時把握項目的最新進度呢

9、？有幾點可供借 鑒：將本周期內的需求逐條整理，歸納成一份列表，每晚用郵件分享當天的 迭代進度，標注出當天該列表中需求的完成情況 （當然要明確各項需求的責 任人）。綁定需求的開發(fā)環(huán)境，隨時跟進最新的開發(fā)進度。這樣如果開發(fā)上有漏 洞，就可以第一時間獲知到并與技術同學溝通。其實，大部分的設計和技術同學還是很負責任的， 有沒搞懂的邏輯問題 都會主動來問你（不然工作沒法繼續(xù)進行）。所以最基本的是，一開始就把 所有需求點和其他部門同學都溝通清楚，從根本上免去不必要溝通的麻煩。4.4. 建立應急機制迭代周期化需要有一套應急策略，比如開發(fā)或測試工作沒有如期完成， 影響了下一階段的工作，此時應該如何做，是砍掉部

10、分相對不重要的需求，還是犧牲上線時間，視具體情況而定。5.5. 適當地貢獻出你的碎片時間在兩輪迭代周期之間，通常會有周末之類的空缺，這個時候產品經理還 是有很多事可做的，比如收集用戶反饋，整理下期需求等等。這一條看似有 些苛刻，不過細細一想也可以接受。畢竟就算在工作時間，我們也會偷偷刷 微博，而工作時間之外我們也同樣不可能完全放開自己的工作。6.6.關于正確的心態(tài)與做法我個人認為，一個迭代周期當中，產品經理應該本著一種“打雜心態(tài)”來協(xié)調和推進整個項目。下面我來解釋一下何謂“打雜心態(tài)”。舉個例子，設計同學在工作時，他會覺得除了按要求設計產品，其他事 情都不屬于自己的工作范圍，也就是他的“雜事”。

11、技術同學在編碼時，也 會覺得除了編碼這一本職工作之外，其他事情都屬于“雜事”?！半s事”的 分類有很多，其他部門的工作可以算作“雜事”，因需求的模糊而去找產品 經理溝通也可以算作“雜事”。而“雜事”由誰來處理呢？產品經理自然當仁不讓。我們可以這么想： 在產品迭代的各個階段，都有相應的階段主體，他們的工作對這個階段的迭 代，起著決定性的作用。在需求初定階段，可能產品經理是主體，但進入了 需求開發(fā)階段，設計與技術同學就變成了主體，進入了測試階段，測試同學 當然就是主體。如果一個階段的主體為太多的雜事所累，那他進行的這部分 迭代工作情況當然不會很理想。作為跟進產品迭代每個階段的角色，我們必須在迭代進入特定階段的時 候，盡量協(xié)助充當這個階段主體的同學，為他們免去盡可能多的雜事，換句 話說也就是替他們“打雜”。這樣做的好處如下：一方面，我們可以規(guī)范迭代流程