天天看點

如何做好B端産品需求排期——産品競争力提升系列(9)

作者:人人都是産品經理
之前已經聊過産品年度規劃、需求價值評估的話題,本篇繼續細化到日常疊代執行層面的需求排期。
如何做好B端産品需求排期——産品競争力提升系列(9)

需求排期是基于已排序好優先級的需求池,在一定資源限制下,權衡多種因素,對需求進行對比和選擇,選出最優先實作的一組需求并配置研發資源。一次需求排期可能是一次産品版本釋出,也可能僅是一個研發疊代周期并不釋出版本。

一、意義是什麼

需求排期本質來說更像一個投資決策行為,核心是為了追求當下最佳ROI。對于商業B端産品是為了收入增長,對于自研或定制軟體是為了上司&使用者滿意度。(下文中,會将市場收入與上司&使用者滿意度等同,統一用市場收入替代,以避免行文備援)

随開發疊代節奏定期做需求開發優先級排序,是對年度規劃的修正,是對市場變化的響應,是為了提升短期市場收入、産品競争力、議價能力、客戶響應感覺滿意度等而做的資源配置優化決策。

二、權衡要素

除了已完成優先級排序的待排期需求清單,還需要綜合權衡多種要素,如:

  • 投入回報率ROI,它是排期權衡時最重要的要素,即,在同等研發投入下,優先做預計産生收入更高的需求。
  • 影響力,即高影響力人物提出的需求,也就是所謂的上司需求。這裡的上司,可能是公司内部的高層,也可能是關鍵大客戶的高層。
  • 開發容量,即疊代周期内可投入的研發人力時間總和,影響可排入需求顆粒度大小和數量。
  • 緊急程度,如處于項目成交、驗收關鍵節點的需求,出現品質問題被回報的需求,需求承諾傳遞時間臨近的需求,需求已提出時間很長且多次催促的需求等。
  • 依賴關系,即需求存在先後依賴關系,避免傳遞半成品或重複返工等。
  • 疊代均衡度,即疊代内大小需求數量、不同類型需求數量等。
  • 需求清晰度,通常優先考慮需求分析已清晰的需求。

三、常見問題

1、決策人錯位

B端産品很怕過度追求使用者體驗和技術,更應該追求收益最大化。功能型産品經理很容易陷入打磨UI/UE細節,而技術負責人則容易陷入追求新技術、更好架構、更少技術債中。最終可能忽視業務價值、缺少成本控制意識,讓産品看起來很牛但沒多大用。

疊代需求排期決策,應該由承擔市場收入考核壓力最大的人來主導,或者讓主導決策的人承擔更多的市場收入考核壓力,以避免産品與市場脫節。

2、價值難量化

哪個需求優先實作,ROI是一個重要衡量因素。但如何定義需求價值,如何評估開發成本是個難點。靠一個人或一群人拍腦袋,過于主觀,缺乏可解釋性、一緻性和可衡量性。盡可能低成本的追求相對量化,有助于提高決策品質。

比如,每次排期選需求時,給每個決策人100個價值點數,由各個決策人給待排期的需求配置設定價值點,最後對需求價值點求均值作為排期參考。

追求絕對準确的需求價值量化值耗費時間精力,沒有必要,定價值本身也存在一定的主觀性。

3、成本虛報

業務方希望多做需求的壓迫和研發團隊希望不過度勞累的反抗普遍存在,也就造成了可能出現研發團隊評估工作量時虛高的情況。為了緩解這種問題,可以借助“開發容量”和“工時點評估”方法。

比如,一個5人開發團隊,2周為一疊代周期,我們可以定義這個開發組疊代開發容量為400工時點。在評估需求成本時,開發團隊及多角色共同參與,各自給出工時點預估,最後對工時點求平均值作為成本參考。

4、追求方法論

關于需求排期、開發優先級的方法論很多,本質都是“權衡次元+對比排序”。沒必要糾結于用哪個方法論,隻要參考決策的人對關鍵權衡要素及其權重大小達成一緻,把所有權衡思考落到相對量化的價值點上對比着排即可。

5、疊代不均衡

如果疊代内隻放少量幾個大需求,則大量小需求會積壓,整體需求傳遞周期會增加,容易給客戶一種響應慢、效率低的感覺。為了平衡外部感覺,需要做疊代内需求做均衡,适當增加一些小需求響應。

需求可以分為優化類、新功能、Bug、技術類(非功能、技術債、架構改造等)等,疊代時需要對需求類型做平衡。如果缺乏限制,可能出現研發團隊做大量技術類需求,多個疊代後市場和客戶感覺産品沒啥變化和價值增加。可以限制如:每個疊代技術類需求工作量占比不超過20%,每個疊代需要有新功能類需求,每次大版本釋出需要有賣點宣傳類需求等。

6、需求變更

疊代内需求變更可能造成時間不足、品質下降等影響疊代目标達成,需要有變更管理機制保障開發節奏。比如,有變更的需求則不計入本次疊代目标;有變更的需求則直接推遲到下個疊代,本疊代根據剩餘工作容量選擇清晰的小需求補充進來。

7、緊急插隊

疊代内可能出現需要緊急響應并釋出的需求,處理方式類似于需求變更。比如,将未開始或完成度低的需求從本疊代中踢出。通常來講,緊急需求對開發節奏影響大,需要嚴格管控,在某些大型公司甚至會有專門的緊急需求管理流程。

8、技術不确定性

有些需求很重要,業務場景也基本清晰,但技術實作有很大不确定性,這種需求要不要排入疊代?如果不排入,可能就會長期拖下去。是以,建議還是排入疊代,但不做傳遞要求。就算整個疊代該需求進展不大,也值得投入時間持續攻堅。不能因為難,就無限期拖延高價值需求。

這次話題裡,筆者最想談的是關于價值相對量化的思路,其他更多是對以往内容及本文話題完整性的補充。

本文由人人都是産品經理作者【産品曉說】,微信公衆号:【産品曉說】,原創/授權 釋出于人人都是産品經理,未經許可,禁止轉載。

題圖來自Unsplash,基于 CC0 協定。