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

大家對產品經理的日常工作有所了解嗎？產品經理在日常工作中又怎么樣做好產品的進度管理呢？大家一起來看一下下面這篇文章了解一下吧！

管理產品進度，保證產品準時上線是產品經理日常工作之一，傳統的產品研發思路是將所有功能都研發完成之后再上線，研發周期可能橫跨數月甚至數年，所以留給產品經理的進度管理空間通常比較充裕，產品經理只要確保產品能夠在截止日期前上線即可，期間對需求的規劃和管理相對比較靈活。

而互聯網產品，尤其是 MVP 產品的研發思路，要求以敏捷開發的思路來對產品進行研發，功能以版本形式進行迭代發布，每個版本的研發周期可能只有1-2周甚至更短。

因此對產品經理的進度管理能力提出了更高的要求，一方面要求產品經理精準規劃好當前版本的需求，同時需要產品經理對產品的迭代方向要有精準的把控，能夠同時進行未來多個版本的規劃。

另一方面，產品經理還需要把控好每個版本上線的時間，既要確保當前版本的準時上線，又要確保下一版本的任務能夠準時銜接，避免出現版本發布后，開發沒有任務做的情況。

也就是說， 產品經理既要把控好版本的研發進度，同時又要把控好產品的規劃進度，確保產品研發與規劃間的無縫銜接。

本文結合產品版本管理的思路，分享產品經理在日常工作中如何做好產品的進度管理。

一、定義任務

定義任務指的是明確當前需要研發的版本的目標，但這有點太抽象，換個思路，要定義版本的任務，首先需要明確當前版本需要實現什么業務目標，進而明確為了實現業務目標需要實現哪些功能，最后明確為了實現功能需要實現哪些需求。

這樣，問題最后就轉換成了當前版本需要實現哪些需求，而需求管理正是產品經理所擅長的領域。

舉個例子，假設當前版本的業務目標是實現用戶的注冊登錄，這個業務目標可以拆分成兩個功能點，分別是用戶注冊和用戶登錄。

用戶注冊的功能點可以進一步拆分成賬號密碼注冊、手機號注冊以及第三方賬號注冊的需求，也可以將“第三方賬號”注冊列為功能點，將需要實現的第三方平臺賬號對接作為具體需求，劃分顆粒度可以根據具體產品來決定，用戶登錄功能也是同樣拆分成多個需求。

二、確定優先級

關于如何確定需求優先級，我在《從10大管理看產品經理的日常工作——產品需求管理》（下稱《產品需求管理》）一文中有介紹過可以按四象限評分、需求關聯（依賴）度、開發難度、開發周期等多種維度進行多維評分來確定需求優先級，此處不再贅述，這里想再補充另外一種確定需求優先級的方法——緊前關系繪圖法。

在《產品需求管理》一文中分享過，需求的依賴條件一般有需求依賴、設備依賴、政策依賴、開發依賴、環境依賴、安全依賴等，緊前關系繪圖法就是通過確定每個需求之間的依賴關系，最終推導出每個需求之間優先級順序的方法。

這種方法一般會綜合多維度進行劃分，對于依賴關系比較密切的需求可以快速劃分出它們之間的優先級。

以購物車為例，假設現在需要做針對購物車功能實現以下需求：

添加購物車、刪除購物車、清空購物車、購物車支付、修改商品數量、選擇商品、統計選擇商品數量、統計選擇商品金額。

如果要對這一堆功能劃分優先級，基本上除了“添加購物車”需求是最先能夠被確定的之外，其他需求的優先級就很難定，好像先做誰都可以，這個時候，我們就可以通過“緊前關系繪圖法”來推導優先級。

首先我們在圖上把所有需求先畫出來。

然后找到每一個需求的“緊前關系”，記住，一定是要找緊前關系，就是實現當前的需求之前需要先實現的需求，如果你找“緊后關系”，你會發現，除了“添加購物車”需求第一個做，其他功能都可以作為“添加購物車”的“緊后關系”，就會變成如下圖所示：

這樣的優先級是沒有太大的參考價值的，所以需要找緊前關系，找緊前關系需要遵循的原則是：每個需求都需要找到緊前關系，并且是聯系最緊密的那個需求。

針對上述需求，我們可以來嘗試找一下每個需求的緊前關系，如下圖：

從上圖我們可以發現，原本我們以為做了“添加購物車”的需求之后，直接做“購物車支付”的需求也可以，但通過緊前關系來進行推導，發現實現“購物車支付”需求，需要先實現“統計選擇的購物車商品金額”的需求，而在此之前，需要實現“選擇購物車商品”的需求，在這之前，才是“添加購物車”需求。

我們按思維導圖的形式把這個圖重新梳理一下，就可以得到一個“緊前關系圖”：

通過上圖，我們除了可以知道每個需求的優先級以及他們之間的依賴關系，我們甚至可以在圖中找出本次開發任務的主線，比如我們此次的業務目標是讓用戶可以將商品添加到購物車并支付，那么我們只要找到最終目標“購物車支付”，然后順著緊前關系一直往前找，就會找到本次開發任務的主線，如下圖：

如此你會發現，即使有很多的功能沒有開發，也不會影響本次業務目標的實現，這就是在上文“定義任務”中所提到的“確定需要實現的業務”的重要性。

三、估算資源

估算資源之所以放在進度管理中，是因為資源對進度有著至關重要的影響，相同的需求，5個人開發和10個人開發，進度肯定是不一樣的。

在產品研發的不同階段，由于需求不同，因此所需的資源也不盡相同，所以估算資源需要在確定了任務和需求之后才可以進行。

資源可以分得很細，但一般習慣性將它分為兩大類：人力資源和支撐資源。

人力資源很好理解，就是本次產品研發需要的人員，核心點一般就是3個：崗位、人數、職級。

崗位指的是本次研發需要用到哪些崗位的人員，比如：產品經理、UI 設計師、前端開發工程師、后端開發工程師等。

人數指的是每個崗位需要的人數，比如：需要2名產品經理，1名 UI 設計師，2名前端開發工程師和4名后端開發工程師等。

職級指的是每個崗位人員的能力級別，比如：4名后端開發工程師中，要求至少1名高級工程師和至少2名中級工程師。

以上3個是最容易對進度的評估和控制產生影響的因素。

支撐資源則是指除了人力資源以外，一切支撐產品研發的資源。比如產品開始研發時，需要的服務器、數據庫等資源。

支撐資源也是需要根據需求進行評估，比如做驗證碼登錄，需要開通短信包資源；比如做移動支付，需要開通支付接口等。

資源的申請時間和到位時間也是估算時間的重要評價標準，比如開通移動支付，申請和審核預計需要7個工作日，并且期間有可能審核不通過，需要重新審核，這些因素都不能不考慮，否則有可能出現某個版本快做完了，發現支付沒有接，一問，說還沒申請下來，這種對于產品研發的進度管理簡直就是災難性的。

因此，在開始一個版本之前，就需要先評估好需要哪些資源，并且確認好這些資源落實的時間，確認哪些資源是必須在開始研發前到位的，哪些是可以在研發進行過程中申請和推進的。

這個時候我們會發現，我們在上一階段確定優先級的時候，只針對需要開發的需求確定了優先級，實際上在整個進度管理過程當中，申請或等待資源落實也會占用時間，因此也應該把申請資源之類的任務也放到“緊前關系圖”中。

比如我們需要在“添加購物車”需求開始的同時進行“申請開通支付接口”的任務，那就需要在在圖中添加一個“申請開通支付接口”的任務了，非需求的任務我們可以用另外的顏色標注出來，如下：

“添加購物車”和“申請開通支付接口”并列進行，沒有緊前關系，所以可以增加一個開始節點來代替，從新的圖中我們可以更加清晰地看到，“購物車支付”有兩個緊前任務，只有當這兩個緊前任務都完成的情況下，“購物車支付”任務才可以開始。

四、估算時間

確定需要開發的需求和所需資源之后，就可以對每個需求的開發時間和每個資源的落實時間進行評估，這個階段需要研發人員介入，對每個任務進行詳細評估。

評估時間一般依靠評估人員的經驗和綜合分析得到，最終需要將評估的結果反映到“緊前關系圖”中，評估時，并不是簡單的評估好每個任務所需要的時間就夠了，還要考慮到4種“關系”和兩個“量”：

4種關系：

1. 完成-開始（FS）：緊前活動完成，緊后活動才能開始。比如：“添加購物車”的功能做完之后，才可以開始做“清空購物車”的功能。
2. 完成-完成（FF）：緊前活動完成，緊后活動才能結束。比如：“統計選擇商品金額”和“選擇商品”可以同步開發，但在“選擇商品”功能開發完成之前，沒有辦法驗證“統計選擇商品金額”功能是否正確實現，所以必須在“選擇商品”的功能開發完成之后，“統計選擇商品金額”功能才能完成。
3. 開始-開始（SS）：緊前活動開始，緊后活動才能開始。比如：“統計選擇商品金額”需要等“選擇商品”開始之后才能開始，否則如果突然取消“選擇商品”這個需求，那么“選擇商品金額”這個需求就沒有意義了。
4. 開始-完成（SF）：緊后活動開始，緊前活動才能結束。假設“申請支付接口”和“獲得支付接口”是一組緊前緊后任務，在獲得支付接口之前，可能會有多次審核，因此要不斷申請，只有“獲得支付接口”的任務完成之后，“申請支付接口”的任務才能結束。

從上文的第3點和第4點可以看出，緊前緊后關系并不是絕對的，相同的緊前緊后活動在不同的場景下可以有不同的定義，對工期的評估自然也會有不同的影響。

兩個“量”：

1. 提前量：相對于緊前活動，緊后活動可以提前的時間量。比如“統計選擇商品金額”活動可以提前3天開始，不用等“選擇商品”活動開始，這個“3天”就是提前量，在算工期的時候，可以減去這個時間。
2. 滯后量：相對于緊前活動，緊后活動需要推遲的時間量。比如“開通支付接口”申請提交后，需要等7天完成審核，之后才能對接支付通道，這個“7天”，就是滯后量，在算工期的時候，需要加上這個時間。

由此我們會發現，不僅是每個任務的時間會影響整體工期，緊前緊后的關系以及提前量和滯后量也會影響整體工期，評估后，同樣需要將每個活動的時間、它們之間的關系以及提前量或滯后量標注在“緊前關系圖”中，如下：

關于“緊前關系繪圖法”的一些基本概念，本文就介紹到這里，各位如果對此比較感興趣，可以去網上查找資料深入學習，在此基礎上結合“關鍵路徑法”，可以計算出整個項目的工期，甚至每個活動的最早開始時間、最早完成時間、最晚開始時間、最晚完成時間以及總浮動時間等。

五、制定進度計劃

由于互聯網產品的迭代速度極快，現在已經幾乎沒有產品經理會為了某個版本去專門制定一份書面計劃，但不是說可以不做計劃，一般推薦用項目管理軟件來管理每個版本的計劃。

目前市面上有很多項目管理軟件，一般都是以需求或任務為單位，對需要完成的需求或任務進行詳細描述，并指派負責人員以及規劃好開始和結束時間，各成員在開發需求或執行任務過程中需對計劃更新。

通過管理軟件看板就可以清晰了解到每個需求或任務的狀態以及完成度，做的比較細的項目管理軟件甚至還會提供各種維度的數據統計報表，如下是某項目管理軟件的部分界面截圖：

六、監控進度

監控進度的節點稱為“監控點”或“里程碑”，一般在制定進度計劃時會約定將某個任務完成或某個具體的日期作為“監控點”，在任務完成或到達約定日期時，對產品研發進度進行監控，根據版本的大小，監控點可能很密，也可能很少，一周一更的產品甚至有可能沒有設置監控點，只在最后進行驗收。

得益于項目管理軟件的應用，監控產品研發進度也變得更加直觀和簡單，關于監控進度的工作，主要記住以下幾點就可以了：

1. 判斷當前產品研發進度的狀態：進度超前、正常還是落后。
2. 對可能引起進度變更的因素施加影響，使其朝有利方向發展，比如申請開通支付接口過程中，有可能資料審核不通過，需要重新提交資料，容易影響到后面支付功能的開發，所以一定要及時關注動態，確保不會因為申請過程延誤太長時間而影響到產品研發。
3. 判斷項目進度是否已經發生變更，并在變更發生時，使用變更控制流程對其進行管理。

變更控制流程在之前的《從10大管理看產品經理的日常工作——產品整體管理》中有提過，這里不再贅述。

七、控制進度

控制進度主要是在進度超前和進度落后時介入。

進度超前未必是一件好事，當進度超前時，需要進行“3個核實”：

1. 核實產品是否按照設計正確實現。比如是否有規劃好的需求沒有開發。
2. 核實產品質量是否達到既定指標。比如查詢性能是否達到合理的指標，查詢時間是否在預先確定的范圍內。
3. 核實進度計劃是否合理。比如制定計劃時，是否將原本3天可以實現的需求寫成5天。

如果核實發現問題，需要進行干預，比如要求按照設計優化產品，或重新修正進度計劃等，如果經過以上“3個核實”都沒有發現問題，那么這個進度超前，就目前為止來講，就是一件好事。

進度落后就一定不是一件好事，當進度落后時，同樣需要進行“3個核實”：

1. 核實造成進度落后的原因。
2. 核實實際落后的進度。
3. 核實落后的進度是否已經對整體的進度產生影響。

核實原因是為了解決問題，核實落后進度是為了提供針對性的改進方案，核實對整體進度的影響是為了確認是否需要調整整體的進度計劃。

針對落后的進度，一般有以下幾種改進方法：

1. 趕工。就是加班，但注意這種方式可能會影響成員情緒，需要做好人力資源管理（關于產品研發過程中的人力資源管理后續有機會整理專門的文章分享）。
2. 快速跟進。將原本按順序進行的任務改為并列進行，可能會有返工危險，需要做好產品質量管理（后續有機會專門分享）。
3. 使用高素質人才。將初級工程師暫時替換成高級工程師，以期提高工作效率，降低返工風險。
4. 改進技術。比如使用更加成熟或更加容易維護的系統框架。
5. 加強質量管理。產品質量管理需要在整個產品研發過程中持續關注，確保不會因為早期沒有發現的產品質量問題而導致后期需要返工。
6. 在獲得批準后，刪減部分依賴程度較小的需求。比如上文舉例的，業務目標是實現添加購物車并支付，后來發現相關的幾個需求實現難度比想象復雜，進度嚴重落后，則可以在經過審批并獲得同意后，將與業務目標依賴性較小的需求刪掉，放到后續的版本完成。

以上便是本文的全部內容，感謝閱讀。