編輯導(dǎo)語：在項目實施過程中，產(chǎn)品經(jīng)理會成為項目負責(zé)人并承擔(dān)其項目經(jīng)理的身份及責(zé)任，那產(chǎn)品經(jīng)理是如何管理版本迭代的？本文作者從項目管理角度，整理項目實施過程中的迭代管理，我們一起來看一下。

一、制定迭代計劃

1. 為什么要制定迭代計劃

首先以圖1為例，簡單說明迭代與開發(fā)工作的關(guān)系。

圖中迭代B是從開發(fā)、測試到正式發(fā)版的一個工作周期，版本是開發(fā)過程中的實際產(chǎn)出，迭代任務(wù)根據(jù)實際情況安排計劃后；通過多次開發(fā)與測試，最后以一個穩(wěn)定版本交付至客戶，就完成了一次迭代。

圖1 迭代與版本的關(guān)系

如果系統(tǒng)以迭代的方式不斷完善，有以下幾個優(yōu)勢：

1）減少錯誤成本

由于客戶的需求不斷變化，部分需求也無法在規(guī)劃的初期就完全確定，通過迭代的方式不斷地讓客戶試用反饋，可以更準確地把握客戶的需求，最終以更少的成本達成客戶期望。

2）提高進度把控

當產(chǎn)品經(jīng)理規(guī)劃或搭建一個系統(tǒng)時，由于任務(wù)多時間跨度長，前期工作會不斷影響后續(xù)任務(wù)的進度；因此通過迭代計劃把項目分解成若干階段，降低對項目把控的難度。

3）限定范圍

由于資源是有限的，要達到資源利用的最大收益，需要把資源用到關(guān)鍵節(jié)點，解決當前最重要的問題；而且限定范圍更利于建立短期目標，團隊成員在落實工作時將更有方向，可以感知項目當前的進度并提前做好規(guī)劃。

4）管理客戶期望

當系統(tǒng)投入項目現(xiàn)場使用之后，客戶會迫切地期望完善系統(tǒng)功能；但由于團隊資源有限，需要制定工作計劃，確保團隊工作符合上級期望。

5）維持系統(tǒng)穩(wěn)定

系統(tǒng)上線運行后，快速的更新迭代是客戶關(guān)注的，但更重要的是客戶能在穩(wěn)定的系統(tǒng)上處理業(yè)務(wù)，一味的追求系統(tǒng)更新，增加了團隊工作量的同時還會增加系統(tǒng)出問題的風(fēng)險；因此以迭代形式統(tǒng)一更新，既能減少了團隊的工作量又能提高系統(tǒng)質(zhì)量。

2. 如何制定迭代計劃

1）確定工作范圍

制定迭代首先需要根據(jù)項目現(xiàn)狀、需求池、待辦事項、客戶反饋等信息，評估任務(wù)優(yōu)先級并輸出具體的工作范圍。

2）預(yù)估工作時間

確定范圍后，初步預(yù)估工作量并與主要負責(zé)人（領(lǐng)導(dǎo)或客戶等）確認計劃是否符合預(yù)期。

若不符合上級預(yù)期，根據(jù)優(yōu)先級進一步調(diào)整，必要時還要增加資源的投入。

3）制定迭代計劃

確定具體迭代任務(wù)后，根據(jù)優(yōu)先級及工作量將任務(wù)放至不同的迭代計劃中，準備投入開發(fā)的迭代必需將任務(wù)落實至具體責(zé)任人并制定詳細計劃，建立表1所示的責(zé)任人清單。

注意：由于團隊內(nèi)不同成員的個人能力存在差異，分配任務(wù)時除了考慮各成員的時間安排外，還需要注意任務(wù)難度與對應(yīng)負責(zé)人的能力是否匹配，以降低執(zhí)行時的風(fēng)險。

表1 責(zé)任人清單

二、管理迭代計劃

制定迭代計劃，是團隊資源與客戶期望達成一致的過程，主要考驗項目負責(zé)人的溝通能力；但到了計劃的落實，除了考驗溝通能力之外，還需要項目負責(zé)人有強大的執(zhí)行力，及時推動問題的解決，避免最終進度的落后。

其工作流程大致如圖2所示：

圖2 版本迭代工作流程

1. 開發(fā)進度管理

把控開發(fā)進度可以從提高進度可控性以及減少延期風(fēng)險兩個維度進行。

第一個：提高可控性

提高可控性的重點，是對團隊成員工作進度的把控，主要方式是制定詳細計劃。

詳細計劃是團隊成員分配到具體任務(wù)后，根據(jù)任務(wù)細化自己的工作內(nèi)容并預(yù)估完成時間的工作清單——其目的是讓產(chǎn)品經(jīng)理通過對每個子任務(wù)節(jié)點把控，實現(xiàn)對整個任務(wù)進度的控制。

以自身經(jīng)歷的項目為例，團隊成員需要根據(jù)任務(wù)細化工作內(nèi)容，而且時間跨度不可多于3天，以保證計劃的可控。

表2 任務(wù)詳細計劃

第二個：降低延期風(fēng)險

通過表2完成詳細任務(wù)分解后，對任務(wù)之間的安排大致有如下印象，整個迭代完成最終取決于最長路徑的完成時間。

因此要保障進度正常，需要重點關(guān)注耗時最長的任務(wù)路徑，降低此路徑延期的風(fēng)險。

圖3 紅線比藍線耗時長為重點關(guān)注路徑

針對風(fēng)險降低大致有以下方式：

1）確保開發(fā)對需求的正確理解

在需求文檔中除了對功能的描述之外，還需要清楚地傳達需求的使用場景及其真正目的，同時通過詳細設(shè)計評審時發(fā)開人員對需求的復(fù)述，確保開發(fā)對需求的正確理解。

2）及時排查進度障礙

開發(fā)在實現(xiàn)需求時，容易陷進問題里面，最終消耗大量時間卻沒辦法解決問題；另外如果有第三方的對接工作，第三方的配合程度也需要重點關(guān)注。

為了減少類似情況的發(fā)生，可以通過每天15分鐘短會對團隊成員進度進行簡單了解，主要目的是排查團隊成員在需求實現(xiàn)、對接等問題上是否存在困難；例如在需求實現(xiàn)上存在疑問需要及時提供解決思路，如果是技術(shù)瓶頸或?qū)訂栴}，則要盡早協(xié)調(diào)資源處理。

3）選擇更優(yōu)的實現(xiàn)方式

需求在實現(xiàn)的過程中，存在多種實現(xiàn)方式，不同的實現(xiàn)方式又對應(yīng)不同的難度，還會給系統(tǒng)帶來不同的影響，此時需要項目負責(zé)人根據(jù)現(xiàn)場實際情況，選擇最佳的實現(xiàn)方式。

例如有一個需求，需要對特殊的用戶發(fā)送消息通知，A方案相對簡單，但只能發(fā)給科室節(jié)點下的用戶；B方案改造量較大且有性能風(fēng)險，但用戶在任何節(jié)點都可以接收消息通知。

此時如果產(chǎn)品經(jīng)理確定接收通知的用戶都在科室節(jié)點下，使用A方案即可滿足需求，既可以在保證質(zhì)量的同時，降低開發(fā)成本。

4）引起團隊重視

由于開發(fā)遠離項目一線，只專注于系統(tǒng)問題的處理，必要時需要適當?shù)貍鬟f一線的壓力；例如現(xiàn)場對此需求的關(guān)注程度、影響的用戶范圍、對整個項目的意義等，以引起負責(zé)人的重視。

實際上當各負責(zé)人知道自己工作的影響或意義，會更加主動更有責(zé)任心。

5）保障項目資源

除了降低團隊內(nèi)部風(fēng)險發(fā)生的概率，如果團隊成員不是項目的專屬資源，還會有派往其他項目的風(fēng)險；在說服上級以保障項目資源的過程中，迭代計劃可以讓領(lǐng)導(dǎo)更清晰的了解項目的規(guī)劃，更放心的把資源投入到項目當中。

6、多請下午茶

請吃飯效果更佳，自費的上不封頂。

2. 控制任務(wù)變更

控制任務(wù)變更的過程需要使用大量的溝通技巧，在此過程中負責(zé)人需要評估范圍變更的影響，通過多次溝通在團隊可承受范圍內(nèi)達成最大效益。

主要通過兩個維度進行控制：

1）減少需求調(diào)整

團隊內(nèi)部減少需求的調(diào)整，需要規(guī)范需求評審的過程，通過使用業(yè)務(wù)流程圖、系統(tǒng)流程圖、詳細的原型設(shè)計及需求規(guī)格說明文檔確保對需求完整考慮；除此之外，在評審過程中還需要開發(fā)、測試的充分參與，盡早評估實現(xiàn)難度。

但即使再充分的規(guī)劃，難免會在開發(fā)時發(fā)現(xiàn)遺漏的細節(jié)，需要對需求進行調(diào)整或補充，并根據(jù)實際情況立即處理或記錄至下一迭代優(yōu)化。

2）控制新增任務(wù)

項目在推進過程中總會有突發(fā)的工作任務(wù)，此時必需根據(jù)當前進度做好影響分析（包括目前資源安排、新任務(wù)優(yōu)先級評估與對比、對迭代進度的影響等），必要時需要做好溝通工作，例如減少原迭代任務(wù)或增加資源的投入。

3. 發(fā)版管理

系統(tǒng)發(fā)版更新需要與客戶確認一套完整的申請流程，其主要目的是確保各環(huán)節(jié)負責(zé)人了解本次更新的時間、詳細工作、風(fēng)險等內(nèi)容。

為了保障發(fā)版的順利，還需要做好以下工作：

1）用戶通告

系統(tǒng)停機更新，特別是已經(jīng)上線運行的系統(tǒng)，必需減少更新對用戶帶來的不便；因此更新前要做好通告工作，同時盡量選擇用戶量較少的時間段進行更新，避免更新過程中由于客戶使用而引發(fā)需要二次處理的問題。如果有新功能或者舊功能有較大調(diào)整，還需要提前做好用戶培訓(xùn)功能或者準備好幫助手冊。

2）規(guī)范更新文檔

在正式更新前，需要準備好更新的清單，例如迭代任務(wù)清單、測試報告、配置清單、待更新的程序包等文件，避免更新過程中遺漏更新文件或配置，具體按照實際情況與團隊達成一致。

3）制定發(fā)版標準

更新完成后需要對系統(tǒng)進行驗證并及時修復(fù)問題，需要與上級或現(xiàn)場共同制定通過標準，例如嚴重問題是否必需全部解決，其余問題處理時限及后續(xù)更新機制，版本回滾機制等，再根據(jù)現(xiàn)場實際情況考慮如何執(zhí)行。

4）資源保障

正式更新過程中，必需保證資源到位，確保發(fā)版各階段具體任務(wù)順利執(zhí)行，例如前期公告發(fā)布、數(shù)據(jù)備份；中期系統(tǒng)驗證與修復(fù)；后期系統(tǒng)巡查或用戶使用情況監(jiān)控等，建立資源表保障系統(tǒng)順利發(fā)版。

表3 系統(tǒng)發(fā)版資源表

三、寫在最后

每一次迭代就是一次小的項目管理，推動項目的前進需要依賴產(chǎn)品經(jīng)理豐富的溝通技巧以及極強的執(zhí)行能力。

項目管理涉及范圍、進度、成本、質(zhì)量、資源、溝通、風(fēng)險等各類技巧的靈活運用；而本文僅提供了一個基礎(chǔ)的框架，希望本文可以讓剛?cè)腴T的新人對版本迭代以及項目管理有一個基礎(chǔ)的認識。

最后附帶一個版本的命名規(guī)則，以供參考：

表4 版本命名規(guī)則

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

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