中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

一、制定迭代計劃

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

首先以圖1為例，簡單說明迭代與開發工作的關系。

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

圖1 迭代與版本的關系

如果系統以迭代的方式不斷完善，有以下幾個優勢：

1）減少錯誤成本

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

2）提高進度把控

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

3）限定范圍

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

4）管理客戶期望

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

5）維持系統穩定

系統上線運行后，快速的更新迭代是客戶關注的，但更重要的是客戶能在穩定的系統上處理業務，一味的追求系統更新，增加了團隊工作量的同時還會增加系統出問題的風險；因此以迭代形式統一更新，既能減少了團隊的工作量又能提高系統質量。

2. 如何制定迭代計劃

1）確定工作范圍

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

2）預估工作時間

確定范圍后，初步預估工作量并與主要負責人（領導或客戶等）確認計劃是否符合預期。

若不符合上級預期，根據優先級進一步調整，必要時還要增加資源的投入。

3）制定迭代計劃

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

注意：由于團隊內不同成員的個人能力存在差異，分配任務時除了考慮各成員的時間安排外，還需要注意任務難度與對應負責人的能力是否匹配，以降低執行時的風險。

表1 責任人清單

二、管理迭代計劃

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

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

圖2 版本迭代工作流程

1. 開發進度管理

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

第一個：提高可控性

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

詳細計劃是團隊成員分配到具體任務后，根據任務細化自己的工作內容并預估完成時間的工作清單——其目的是讓產品經理通過對每個子任務節點把控，實現對整個任務進度的控制。

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

表2 任務詳細計劃

第二個：降低延期風險

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

因此要保障進度正常，需要重點關注耗時最長的任務路徑，降低此路徑延期的風險。

圖3 紅線比藍線耗時長為重點關注路徑

針對風險降低大致有以下方式：

1）確保開發對需求的正確理解

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

2）及時排查進度障礙

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

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

3）選擇更優的實現方式

需求在實現的過程中，存在多種實現方式，不同的實現方式又對應不同的難度，還會給系統帶來不同的影響，此時需要項目負責人根據現場實際情況，選擇最佳的實現方式。

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

此時如果產品經理確定接收通知的用戶都在科室節點下，使用A方案即可滿足需求，既可以在保證質量的同時，降低開發成本。

4）引起團隊重視

由于開發遠離項目一線，只專注于系統問題的處理，必要時需要適當地傳遞一線的壓力；例如現場對此需求的關注程度、影響的用戶范圍、對整個項目的意義等，以引起負責人的重視。

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

5）保障項目資源

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

6、多請下午茶

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

2. 控制任務變更

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

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

1）減少需求調整

團隊內部減少需求的調整，需要規范需求評審的過程，通過使用業務流程圖、系統流程圖、詳細的原型設計及需求規格說明文檔確保對需求完整考慮；除此之外，在評審過程中還需要開發、測試的充分參與，盡早評估實現難度。

但即使再充分的規劃，難免會在開發時發現遺漏的細節，需要對需求進行調整或補充，并根據實際情況立即處理或記錄至下一迭代優化。

2）控制新增任務

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

3. 發版管理

系統發版更新需要與客戶確認一套完整的申請流程，其主要目的是確保各環節負責人了解本次更新的時間、詳細工作、風險等內容。

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

1）用戶通告

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

2）規范更新文檔

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

3）制定發版標準

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

4）資源保障

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

表3 系統發版資源表

三、寫在最后

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

項目管理涉及范圍、進度、成本、質量、資源、溝通、風險等各類技巧的靈活運用；而本文僅提供了一個基礎的框架，希望本文可以讓剛入門的新人對版本迭代以及項目管理有一個基礎的認識。

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

表4 版本命名規則

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

題圖來自Unsplash，基于CC0協議