在日常工作中，產(chǎn)品經(jīng)理或多或少兼任“項目經(jīng)理”的角色，不僅需要參與產(chǎn)品規(guī)劃、開發(fā)到發(fā)布全過程，途中還需負(fù)責(zé)處理突發(fā)情況、團(tuán)隊資源協(xié)調(diào)等問題。在這種情況下，有一套合理規(guī)范的項目迭代流程尤為重要，那么，一個版本從規(guī)劃到發(fā)布的完整過程是怎樣的呢？
在小步快跑，快速迭代的移動互聯(lián)網(wǎng)時代，大家都希望在迭代速度上取得優(yōu)勢，第一時間搶占用戶。但很多公司可能會因此而忽略甚至跳過一些應(yīng)有的流程，一味求快，使得版本迭代效果大打折扣。
合理流程和快速迭代之間并不矛盾，遵循一個規(guī)范化的迭代流程，能夠讓團(tuán)隊達(dá)成同一認(rèn)知、加強(qiáng)時間觀念，從而提高迭代質(zhì)量和效率，保證項目順利進(jìn)行。
在日常工作中，產(chǎn)品經(jīng)理或多或少兼任“項目經(jīng)理”的角色，不僅需要參與產(chǎn)品規(guī)劃、開發(fā)到發(fā)布全過程，途中還需負(fù)責(zé)處理突發(fā)情況、團(tuán)隊資源協(xié)調(diào)等問題。在這種情況下，有一套合理規(guī)范的項目迭代流程尤為重要，那么，一個版本從規(guī)劃到發(fā)布的完整過程是怎樣的呢？
一個較為完整的迭代流程，應(yīng)該包含以下幾個階段：
一、版本規(guī)劃階段
產(chǎn)品是火車頭，提前做好規(guī)劃，是保證方向明確、開發(fā)節(jié)奏有條不紊的前提。合理的迭代節(jié)奏要求產(chǎn)品經(jīng)理的規(guī)劃提前當(dāng)前開發(fā) 1~2 個版本。這樣做的好處，一方面是讓團(tuán)隊知道下一步具體做什么，有助開發(fā)提前考慮代碼框架，避免后期返工，另一方面是可以快速開啟下一版本迭代，同時提高項目的可控程度。
在版本規(guī)劃階段，需要明確版本目的、做哪些需求、具體怎么實現(xiàn)，初階產(chǎn)品最好跟產(chǎn)品內(nèi)部討論確認(rèn)一遍，避免方向性錯誤。
這個階段的重點在于圍繞迭代目的進(jìn)行需求篩選和真?zhèn)闻袛啵磧?yōu)先級進(jìn)行排序，同時注意合理規(guī)劃需求量，避免迭代周期太短或者過長。一般情況下，穩(wěn)定的版本迭代周期控制在2~4周內(nèi)。
二、需求評審階段
梳理好迭代需求后，就進(jìn)入需求評審階段，工作主要分兩部分：需求確認(rèn)和原型評審。
1. 需求確認(rèn)
目的是在團(tuán)隊內(nèi)討論迭代方案的合理性和可行性，及時發(fā)現(xiàn)問題，避免返工修改。如果時間比較緊，不方便召集團(tuán)隊集體討論，就需要在版本規(guī)劃階段主動聯(lián)系對接人員進(jìn)行討論確認(rèn)。
2. 原型評審
方案通過后，開始繪制原型，并召開原型評審。評審會議上需要明確版本目的，先講為什么，再講怎么做，讓每一位成員都能對版本需求有個全面的理解，減少后續(xù)不必要的溝通。
對于功能復(fù)雜或比較大的版本，在初次評審后，往往會發(fā)現(xiàn)比較多的問題，需要會后重新確認(rèn)和修改方案，進(jìn)行二次評審。產(chǎn)品經(jīng)理在這一階段要做的是認(rèn)真考慮多方意見，給出一個合理完善的方案。
三、工期評估階段
在需求評審?fù)ㄟ^后，一般會給半天到一天的時間用于評估工期。評估的時間節(jié)點包括設(shè)計、開發(fā)、提測、驗收和發(fā)布，如果涉及海外市場，還需評估文案潤色翻譯時間。
評估完成后由產(chǎn)品經(jīng)理匯總，并基于迭代節(jié)奏協(xié)調(diào)開發(fā)時間和需求量，確認(rèn)最終的需求和各個時間節(jié)點，同步給整個團(tuán)隊。
最終需求確認(rèn)下來后，就可以創(chuàng)建當(dāng)前版本的需求池，并分配對應(yīng)的研發(fā)人員和開發(fā)時間。需求池形式根據(jù)不同公司而異，一般是使用第三方版本迭代平臺，如 TAPD、禪道和 JIRA 等，進(jìn)行需求管理、狀態(tài)流轉(zhuǎn)和進(jìn)度跟蹤。
如有必要，還需維護(hù)一份版本迭代文檔，記錄本次迭代相關(guān)信息，方便后續(xù)回溯。文檔內(nèi)容一般包括：各對接人員、版本需求、相關(guān)文檔（原型、需求文檔、埋點、翻譯文案、設(shè)計稿）及各個時間節(jié)點。
四、開發(fā)測試階段
工期確認(rèn)后，產(chǎn)品正式進(jìn)入迭代開發(fā)周期，測試同事開始準(zhǔn)備測試用例，并召集開發(fā)和產(chǎn)品一起討論，確認(rèn)對需求理解無誤。另外，產(chǎn)品經(jīng)理或開發(fā)需要將該版本新增文案按照 key:value 格式整理好，遞交翻譯。
到這一步，產(chǎn)品經(jīng)理在前期的主要工作也已經(jīng)完成得差不多了，但作為版本迭代最重要的環(huán)節(jié)，產(chǎn)品經(jīng)理需要全程跟進(jìn)，保證需求按時按要求實現(xiàn)，發(fā)現(xiàn)問題及時協(xié)調(diào)處理。
理想狀態(tài)下，設(shè)計師需要在正式開發(fā)前輸出設(shè)計稿，保證研發(fā)進(jìn)度，但實際情況往往不可控，需要在資源和時間協(xié)調(diào)上作出讓步。折衷的方法是研發(fā)先進(jìn)行框架開發(fā)，最后套 UI，或是設(shè)計師按優(yōu)先級先出幾稿頁面，剩下的與研發(fā)并發(fā)進(jìn)行。
等到版本提測后，產(chǎn)品經(jīng)理需要跟進(jìn)功能完成情況和bug修復(fù)情況，判斷沒有完成的功能和bug是要加班、砍需求還是規(guī)劃到下個版本，并著手準(zhǔn)備版本更新日志，遞交翻譯，為發(fā)布做準(zhǔn)備。
五、驗收階段
這一階段很多時候都會被忽略，認(rèn)為測試通過就可以發(fā)布版本了。事實上，產(chǎn)品驗收和視覺還原是保證產(chǎn)品交付質(zhì)量的重要前提。因此，在測試完畢后，一般需要預(yù)留1-2天時間，對新版本進(jìn)行驗收，確保需求按要求實現(xiàn)，設(shè)計師需要進(jìn)行視覺還原，保證視覺效果。
六、發(fā)布階段
開發(fā)完成驗收后的 bug 修復(fù)后，提交發(fā)布包，進(jìn)行一輪回歸測試，由產(chǎn)品驗收通過后，與相關(guān)運(yùn)營人員進(jìn)行對接發(fā)布版本。
版本發(fā)布后，一般情況下還需對線上的新版本進(jìn)行一輪驗證，沒問題就可以推送版本升級通知。另外，需要整理更新日志和發(fā)布結(jié)果同步給團(tuán)隊成員，整理上一版本遺留問題、進(jìn)行版本復(fù)盤、準(zhǔn)備后續(xù)效果評估及下一版本迭代工作。
總結(jié)
以上是一個較為完整且經(jīng)過團(tuán)隊驗證的周期化版本迭代流程。
團(tuán)隊內(nèi)部有一套較為規(guī)范的流程，能規(guī)避很多不必要的錯誤。但切記，不要為了走流程而規(guī)范流程，沒有任何一套流程可以適用到所有團(tuán)隊，很多時候都需要根據(jù)特殊情況靈活調(diào)整。無論你制定的流程多么規(guī)范，能夠經(jīng)得起團(tuán)隊驗證、適合產(chǎn)品當(dāng)前階段的流程才是最好的。
文末小彩蛋
關(guān)注公眾號「給予醬」，后臺回復(fù)“流程”
可獲得以上迭代流程泳道圖一張
歡迎小伙伴一起討論交流！
