<xmp id="0c8o0">
  • <nav id="0c8o0"><code id="0c8o0"></code></nav>
    <menu id="0c8o0"><tt id="0c8o0"></tt></menu>

    產品經理核心技能修煉:如何做好產品需求管理?

    管理產品需求是一項重要的產品經理基本功,如何管理產品需求清單,讓產品開發變得僅僅有條?本著“拒絕紙上談兵”的初衷,我想總結一下我的答案,以下6招優化產品需求清單,讓你“輕裝上陣”。

    產品經理核心技能修煉:如何做好產品需求管理?

    大部分產品經理都很忙,為了完成任務而疲于奔命,是生活的常態。產品需求清單就像一個“雜物箱”,寫滿了點子、用戶故事、功能需求、bug……只要是和產品有關的,統統往里裝。任務一來,先寫到產品需求清單里,有什么不對嗎?

    沒時間整理產品需求清單,也是一個問題。清單越來越長,分不清輕重緩急。許多產品經理告訴ProductPlan,他們的產品需求清單就像“無底洞”,不知從何下手。

    產品需求清單應該長啥樣?為什么要區分優先級?讓我們退一步想:為什么產品經理要用產品需求清單?

    理想狀態下,產品需求清單的內容包括:產品團隊下一步要完成的、與產品相關的任務;完成以上任務后,需要關注的事項(在一定時間范圍內)。但是,事實上,產品需求清單的內容不止于此。許多其他的任務占據了太多空間,讓清單的管理變得困難重重。

    這就是區分優先等級的原因。產品需求列表要做到結構明確,重點突出,而不是成為一個“雜物箱”。如果有人和你說:“把XX丟到產品需求列表里。”但沒有人覺得這不合理的話,那么你的產品需求列表已經淪陷了。

    ProductPlan(作者所在產品團隊)專注于優化產品經理的工作,使之井井有條,符合戰略愿景。我們發現除了產品路線圖的問題,混亂的產品需求列表也是工作效率、成果的致命傷。

    下面,就讓我們來了解一下6條優化的方法。

    將下一次迭代的內容“置頂”

    把下一次迭代的內容“置頂”,把下一個迭代的內容,作為清單的優先處理事項,避免時間表混亂。

    這樣一來,優先處理事項就有了明確的時間表——下一個迭代就要做。

    當然,首先,你要有一套機制,用來決定下一次迭代做什么,我會在下文加以闡述。

    剔除優先級低的任務

    把“優先級1”和“優先級2”的任務納入產品需求清單,其他的另外歸類(比如納入“長期任務”)。就是這么簡單粗暴。

    假如,經過多輪頭腦風暴,產品團隊列舉了20種可行的產品創意。顯然,短期之內,這20種創意不可能全部實現。那怎么辦?區分優先級別!

    選出最好的2至4個,拆解為小任務,安排團隊成員完成。

    至于其他的創意,可以先記下來,但不要納入產品需求清單(更不用說產品路線圖了)。產品需求清單要盡可能簡明扼要、現實可行。

    列出下一次迭代要做的事(優先級1),接下來幾個月要做的事(優先級2),就足夠了。

    如何處理“優先級2”的任務?請見下文。

    創建其他任務清單

    把真正緊急、有戰略價值的任務納入產品需求清單,把其他不那么緊急的事項另外歸類,會讓整個清單更具針對性、更具戰略價值。那些把清單越寫越長的產品經理——他們不知道該把非緊急事項記在哪——使用清單自然困難重重,也更有可能遺漏重要任務。請記住這句話!

    創建其他的清單非常必要,比如“好點子”清單,“長期任務”清單。

    創建任務價值打分系統

    ProductPlan的產品路線圖App內置加權打分功能,在時間、預算、人力資源有限的情況下,產品經理需要對每個任務的戰略價值打分,利用有限的資源,創造最大的價值。

    管理產品需求清單時,ProductPlan打分的指標有三個:用戶價值、營收、成本。

    把任務分為三個優先級:優先級1、優先級2、長期任務。“優先級1”的任務下一次迭代要完成,“優先級2”的任務接下來三個月要完成,剩下的都屬于“長期任務”。

    每一個任務為什么會在清單上,在哪里,都一目了然;向利益干系人、其他團隊解釋時,也會事半功倍。

    創建任務成本(時間、人力等)管理系統

    記住完成每一項任務所需的時間。這一點很重要。不僅要知道總的開發時長,還要知道每一位開發員工所需的時間。把時長(小時、天、半天)轉化為積分。比如,一個積分代表一天。完成某個用戶故事的編程工作,是一個1積分的任務,也就是要花1天的時間。

    這樣一來,產品需求清單變得一目了然,用全局的眼光安排時間和人員,也變得更簡單(不再糾結于時間單位的轉化、人數的安排)。

    注意事項1:估計任務積分時,要有全局觀。例如,修復某個bug可能只是一個0.5積分的任務,也就是要花半天的時間。

    但是,這只包括識別和修復bug的時間,不包括測試時間,也就是編寫和運行自動化測試的時間。所以,估計任務積分時,最好保守一些,寧可高估,不可低估。

    注意事項2:同一個任務,對不同的員工來說,所需時間不一定相同。

    請記住,每一個產品團隊都是獨一無二的,不論是技能、特長,還是短板。在計劃時,產品需求列表的重要性不言而喻。如果某一個任務,只有一兩位開發人員有能力做,分配任務時更要小心,不要讓別的任務干擾了他們的工作。

    定期更新

    產品需求清單是活的,不是死的——任務優先級是可變的。

    如果你遵循以上5條建議,每一次迭代結束,產品需求清單就會更新一次,“優先級2”的任務就會升格為“優先級1”的任務。

    此時,產品需求清單上的每一項任務都有特定的戰略意義。當你打開清單,判斷任務優先級是否有變動——不論出于何種原因(競爭對手情報、用戶請求、bug緊急修復)——一切都清晰明了。

    最重要的是,你不再胡亂猜測,而是開始系統性地做決定。

    本文為@即能原創,運營喵專欄作者。

    (0)
    即能即能專欄作者
    上一篇 2019-02-12 14:58
    下一篇 2019-02-13 16:03

    發表回復

    登錄后才能評論
    公眾號
    公眾號
    返回頂部
    運營喵VIP會員,暢學全部課程,點擊查看 >
    央视频直播在线直播