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

0 評論 530 瀏覽 3 收藏 9 分鐘

之前已經聊過產品年度規劃、需求價值評估的話題,本篇繼續細化到日常迭代執行層面的需求排期。

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

一、意義是什么

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

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

二、權衡要素

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

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

三、常見問題

1、決策人錯位

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

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

2、價值難量化

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

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

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

3、成本虛報

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

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

4、追求方法論

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

5、迭代不均衡

如果迭代內只放少量幾個大需求,則大量小需求會積壓,整體需求交付周期會增加,容易給客戶一種響應慢、效率低的感知。為了平衡外部感知,需要做迭代內需求做均衡,適當增加一些小需求響應。

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

6、需求變更

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

7、緊急插隊

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

8、技術不確定性

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

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

本文由人人都是產品經理作者【產品曉說】,微信公眾號:【產品曉說】,原創/授權 發布于人人都是產品經理,未經許可,禁止轉載。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!