之前已經(jīng)聊過產(chǎn)品年度規(guī)劃、需求價值評估的話題，本篇繼續(xù)細化到日常迭代執(zhí)行層面的需求排期。

需求排期是基于已排序好優(yōu)先級的需求池，在一定資源約束下，權(quán)衡多種因素，對需求進行對比和選擇，選出最優(yōu)先實現(xiàn)的一組需求并配置研發(fā)資源。一次需求排期可能是一次產(chǎn)品版本發(fā)布，也可能僅是一個研發(fā)迭代周期并不發(fā)布版本。

一、意義是什么

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

隨開發(fā)迭代節(jié)奏定期做需求開發(fā)優(yōu)先級排序，是對年度規(guī)劃的修正，是對市場變化的響應(yīng)，是為了提升短期市場收入、產(chǎn)品競爭力、議價能力、客戶響應(yīng)感知滿意度等而做的資源配置優(yōu)化決策。

二、權(quán)衡要素

除了已完成優(yōu)先級排序的待排期需求清單，還需要綜合權(quán)衡多種要素，如：

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

三、常見問題

1、決策人錯位

B端產(chǎn)品很怕過度追求用戶體驗和技術(shù)，更應(yīng)該追求收益最大化。功能型產(chǎn)品經(jīng)理很容易陷入打磨UI/UE細節(jié)，而技術(shù)負責人則容易陷入追求新技術(shù)、更好架構(gòu)、更少技術(shù)債中。最終可能忽視業(yè)務(wù)價值、缺少成本控制意識，讓產(chǎn)品看起來很牛但沒多大用。

迭代需求排期決策，應(yīng)該由承擔市場收入考核壓力最大的人來主導，或者讓主導決策的人承擔更多的市場收入考核壓力，以避免產(chǎn)品與市場脫節(jié)。

2、價值難量化

哪個需求優(yōu)先實現(xiàn)，ROI是一個重要衡量因素。但如何定義需求價值，如何評估開發(fā)成本是個難點。靠一個人或一群人拍腦袋，過于主觀，缺乏可解釋性、一致性和可衡量性。盡可能低成本的追求相對量化，有助于提高決策質(zhì)量。

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

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

3、成本虛報

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

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

4、追求方法論

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

5、迭代不均衡

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

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

6、需求變更

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

7、緊急插隊

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

8、技術(shù)不確定性

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

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