如何搭建產品管理優先排序框架?

本文兩個方面——項目之間的優先級,以及項目工做之間的優先級,來說述:如何搭建產品管理優先排序框架? 框架

優先排序意味着首先作最重要的事情,在構建產品的時候,就意味着首先要作的事情是創造最大客戶價值。  測試

制定優先級決策的工藝是一個團隊最困難的技能之一,由於須要作優先排序的狀況不少,並且這一般也是產品經理的核心職責。可是,咱們能夠發現那些好的團隊,每一個人都是優先朝着同一個目標前進。cdn

 1、優先排序框架 產品管理的優先級能夠分爲兩個方面:blog

1. 項目之間的優先級:這是關於肯定咱們團隊下一步應該作什麼項目。 排序

2. 項目工做之間的優先級:這是關於如何有效地執行項目。  開發

在對項目進行有限排序的時候,咱們必須作出一個決定:咱們團隊接下來會投資什麼?  產品

接近這個問題的答案就像是完成一個謎題,應該用嚴格的流程找出全部線索,才能解出謎底。  it

在對項目中的工做進行優先排序時,咱們必須作出數百次相同的決定:這是絕對必要的嗎?  io

解決這個問題的正確方法是接受工做的混亂性,而後培養一種無情的心態,快速決定什麼是絕對必要的。 2、 項目之間的優先級 解決這個問題的流程: class

 1. 估算每一個項目的投資回報率。 

 2. 制定三個約束條件:依賴關係,時間軸和團隊組成。 

 3. 估算投資回報率(ROI) 全部項目優先級的基礎是投資回報率(ROI),其衡量咱們的團隊在一個單位時間內建立的客戶價值量。咱們肯定優先級的目標是始終作最大化客戶價值的工做。 爲了在項目之間劃分優先級,咱們須要估計兩個數據點: 1. 客戶價值 2. 完成項目所需的人天 咱們知道投資回報率(ROI)=年利潤或年均利潤/投資總額×100%,在這裏咱們項目的ROI就是客戶價值除以人天了。一旦咱們有了每一個項目的這些數據,咱們能夠簡單地比較不一樣項目的ROI而後*決定*咱們的優先事項。



 固然,估計影響程度的高低和投入精力的多少是很是困難的,由於咱們每次估算均可能出現錯誤的狀況,因此,屢次比較估算結果以後能夠發現計算ROI是肯定項目優先級的最好方法。 

 2. 制定約束條件 因爲項目的進展大多數狀況不是井井有理的,所以咱們還須要將約束條件歸入優先級決策。 

 咱們必須處理的核心約束有三部分:依賴關係,時間軸和團隊組成。 

 1)依賴關係 當須要完成一個工做以便進行另外一個工做時,就會產生一個依賴關係。 

假設咱們在移動團隊中,但願爲手機端的客戶建立一鍵式付款按鈕。咱們已經肯定這是最高投資回報率項目,所以咱們但願儘快完成。可是,要作到這一點,咱們的公司實際上須要首先接受付款的能力,而這又是另外一個團隊正在進行的工做。對其餘團隊的依賴意味着咱們沒法真正作任何事情,所以正確的優先級決定是延遲這個功能並執行咱們的下一個最高投資回報率項目。 

不少人認爲初創公司工做效率很高,是由於他們工做更努力,更有野心。但事實是,大多數速度差別來自於他們具備更少的依賴性,所以更容易完成任務。

 2)時間軸  

咱們都經歷過期間的約束,舉個例子:若是咱們的創業公司在最高投資回報率功能上線以前用完資金,那麼咱們的創業公司就宣告死亡。因此,在發生這種狀況以前,正確的優先級決定固然是作出在必定時間範圍內可實現的最高ROI項目。 

 3)團隊組成  

並不是全部團隊都是平等的,有時團隊中特定人員的組成意味着咱們須要針對項目作出不一樣的優先級決策。  

一個例子就是:擁有一個充滿了全新人員的團隊,就像一羣實習生(沒有對實習生的不尊重,50%的軟件是由他們建造的)。在這些狀況下,咱們應該警戒優先考慮對客戶有很大風險的項目,即便它是最高投資回報率的項目*。*相反,咱們一般會更優先考慮不接觸任何關鍵代碼或用戶體驗之類的項目,由於這樣能夠減小產生不良結果的狀況發生。 

幫助新手團隊熟悉業務、熟悉代碼以後取得一些小的成果,一旦他們掌握了一些生產技能,他們就能夠向更復雜的項目發展。 

 3、項目工做之間的優先級 

在項目執行期間,不少時候優先級的定義是很混亂的。並且咱們天天都須要作出決定,也沒有時間像咱們在項目之間進行優先排序時同樣慢慢分析。對於一個團隊來講,這是一個更加情緒化的時期,由於真正的客戶極可能在咱們作決定的這段時期受到影響。  

雖然全部軟件開發過程當中遇到問題是很正常的一件事情,而且隨着時間的推移問題會愈來愈多。可是,當面對一個新的問題時,若是咱們的團隊沒法快速弄清楚是否應該修復它時,那麼咱們專一於最重要工做的注意力將不斷受到干擾。  

實際上,更有效的策略是幫助團隊內化產品開發概念,並將其構建成優先級系統來肯定什麼時候修復錯誤。 

好比:咱們能夠用X軸表示錯誤影響用戶的頻率,用Y軸表示錯誤的嚴重程度,用紅點表示一個錯誤。


 以MadPecker缺陷管理爲例:我和團隊成員定義嚴重程度太高的狀況(好比:用戶不能提交BUG)以及頻率太高的狀況(好比:在這種狀況下受影響的用戶爲5%)。而後,只要團隊就錯誤落到某個區域的一系列操做達成一致,咱們就能減小處理低價值錯誤的狀況,由於落在待辦事項的錯誤並非絕對必要立刻修改的,而落在立刻解決的錯誤就是須要咱們馬上處理的。 

 4、最後 

咱們的時間就是咱們最寶貴的財富,而優先排序的目的就是讓咱們在作決定的時候更加果斷,在工做的時候更有效率,由於總有一種方法能夠比你目前的計劃更快地實現你的目標 

本人創業團隊產品MadPecker,主要作BUG管理、測試管理、應用分發, 

網址:[www.madpecker.com],有須要的朋友歡迎試用、體驗!  

本文爲MadPecker團隊產品經理編寫,轉載請標明出處 

相關文章
相關標籤/搜索