對于産品需求池中各個功能的優先級排期本就是一個複雜、繁瑣、多變的事情，希望我們能通過一些合理的方法做出相對正确的決策。同時決策力不僅是善于做決策，更要勇于做決策，勇于承擔決策所帶來的結果。本文作者對産品的優先級排序進行了分析，一起來看一下吧。
随着産品經理的逐漸成長，“決策力”會逐漸變成一項重要的能力。
我們如何在日常工作中多方評估、全面分析，最終做出相對正确的決策，帶領産品朝着更有價值、更合理的方向前行，是需要刻意培養和練習的能力之一。
以産品疊代中各個功能的優先級排序為例，無論是在大版本需求池篩選，還是在小問題中多方案抉擇，都需要我們具備良好的決策力來推進事件的執行。
最近我也在梳理明年的産品疊代需求池和疊代計劃，對于各項需求的優先級排列經常會陷入兩難，是以借此總結這個過程中可以輔助我們進行判斷的方法，希望能對有幸讀到的你帶來一些幫助。
因為很多觀點和方法我也在探索中，是以也非常希望能夠得到你的回報和建議。
01 需求來源與需求池維護
首先，我認為需求池來源于日常工作的積累，并不是需要時臨時刻意想出來的。
- 有些是産品規劃中後續需要增加的場景；
- 有些是市場調研、使用者使用過程中提出的優化或使用問題；
- 還有在市場競争和發展中需要随之變化的功能、基于競争對手帶來的新功能；
- 也有很多曾經在研發過程中因為時間、團隊構成、業務不熟悉等原因導緻的遺留問題；
- 包括很多MVP的功能子產品需要再向外完善；
- 可能還會有一些上司突發奇想或者未來想要布局的功能等等。
需求池無論采用哪種表現形式，一定要随時記錄，定期整理，否則真正到準備中長期計劃時，我們會遺忘、會遺漏很多關鍵内容。
而且我建議采用可協同的形式進行需求池維護，能夠動态拖拽就更好了，這樣可以很友善的讓我們進行優先級調整和功能分類
在此，我推薦共享文檔中的思維導圖、闆栗看闆兩個工具供大家選擇：
02 需求池内容分類拆解
其次，我們可以将需求池中上述提到的内容換一個角度，大體區分為以下幾類：
1. 傳遞過程缺失的标準化功能
基于項目傳遞制的産品研發，更大的意義在于标準化功能的快速開發和快速複制，産品成熟度越高，傳遞效率越高。是以從願景來看，研發版本應該至少超出傳遞版本兩個以上的版本号。
但在實際工作中，尤其是産品孵化初期、或者産品迅速成長期，研發版本經常會落後于傳遞版本。而且因為傳遞在面對大量定制化客戶時，還會有很多新需求，這些新需求可以作為産品标準化功能的子產品，最好由研發團隊統一設計開發，以便後續的版本把控。
即便由于多種原因最終由傳遞團隊在定制化版本中完成了新功能的開發，也需要研發團隊将此功能合并到研發版本并進行合理的标準化适配。
是以需求池中就會存在很多客戶迫切需要的功能，傳遞團隊在等着研發釋出新版本，在這期間傳遞團隊會經常受到客戶方的壓力，進而将壓力轉嫁到産品和研發團隊中。
2. 售前客戶可預見的功能
産品在市場推廣階段，會經常收到客戶的新思路或新要求，當客戶方釋出了一個相關産品新功能的交流公告，研發團隊要不要配合市場進行響應？在招投标之前客戶想要看一下系統的成熟度，或者進行标準化版本的預測試，研發團隊、産品團隊是否需要積極配合？
一個客戶提了A訴求，又一個客戶提了A訴求，A場景不斷在市場上被提起，這時作為産品團隊是否要積極尋求更優質的解決方案？
同時一旦這個項目有幸中标，且客戶新增的功能恰好屬于産品後續可疊代的标準化功能，情況又會轉變成第一種—>傳遞過程缺失的标準化功能。
而這裡面會存在一個比較沖突的現象，因為售前客戶的新需求可能是非常多的，我們是否需要逐個響應？是否有能力逐個響應？
是以這些情況所産生的需求池也需要我們從産品角度快速甄别篩選，對于需要響應的功能盡快設計方案并排期執行。
3. 合作方催辦的功能
現在我們的很多産品都不是獨立的應用，需要和很多第三方系統內建、合作，其中不乏一些多方合作的子產品，合作方經常催促我們盡快進行優化更新。當然也會遇到我們急需合作方配合改造更新的功能，這種情況下我們會更加被動。
無論哪種情況，涉及到第三方合作的功能，尤其是基于雙方簽訂了合作協定，有利益連接配接關系的合作場景，對于合作方催辦的功能我們其實也很難把優先級往後排。
也許這個功能對于産品來說不是核心功能，但是受限于企業形象，或者上司層面、老闆層面的輿情，也要盡力積極響應，并巧妙推進甚至“拖延”。
4. 産品使用過程中的阻力功能
這裡所指的并不是MVP版本，或核心流程的阻斷，因為這類阻斷正常來講都已經被及時解決了。更多的是因為存在某個功能的缺失，進而影響更大面積的産品推廣或使用者增值服務。
即現在能用，但是如果做了這個新功能，會對産品力創造較大的突破。
比如某個使用者使用頻次較高的功能産品隻做了pc端，如果能夠推出移動端對應功能，則能夠快速提升移動端的通路量，同時吸引很多對移動應用場景有實際訴求的使用者。
但這裡也有一個經常在取舍時的沖突點：雖然此功能有些缺失，此功能很重要，上線後能夠帶來一定效果，但0.5畢竟不是0，當有很多0功能需要你們優先解決時，0.5-1的更新優先級會競争過0-1的更新嗎？
至于哪個功能更重要，不同的業務模式和商業模式一定會有較大差異，在此我們不去評定到底哪個優先級更高，僅是為了說明其中的抉擇關系。
5. 重要但不緊急的功能
比如為了後續的場景拓展，為了産品在使用者價值或商業價值上能夠更上一個台階。
或者某個應用的功能架構更新，或者平台級或元件級的技術架構更新，為了能夠更好的适應後續産品的發展。
這些都屬于重要，但是不緊急的待辦事項。一般這類功能都需要較大的工作量，而且很難拆分成多個更新版本，日拱一卒的慢慢推進。否則既然功能很重要，一定會适當的加塞一點點做起來。
是以這類功能，往往在最終決策時，就把優先級往後放了。同時結合下一條，這些重要但不緊急的功能什麼時候能夠開始動工，非常考驗一個團隊的“忍耐力”和“調配力”。
但是，一味地對重要但不緊急的任務延後，不僅會讓産品疊代始終被緊急的事情牽着鼻子走，而且大機率會拖到“重要但不緊急的事情”變成“重要且緊急的事情”，進而不停的“惡性循環”。
仿佛産品疊代就像“救火隊員”一樣，哪裡着急補哪裡，哪裡更着急先救哪裡。猶如一列行駛的火車面對交叉路口，左邊撞1頭牛，右邊撞2隻狗一樣，形成“飲鸩止渴”的負面結果，進而失去了産品本身的節奏。
甚至于到最後發現最緊急的事也做不過來了，團隊一直處于持續高強度工作狀态，可問題似乎越來越多。
上半年讀的一本《時間管理大師》的書，其中所表達的最核心觀點，在我看來就是“把重要但不緊急的事情優先級調高”，進而經過自己一段時間的堅持和努力下，扭轉當下的“滅火困境”。
但說起來容易，做起來難呀！
但做起來再難，也不能不做呀！
6. 工作量這麼大，做了它就做不了其他的功能
緊接着上一條，無論是重要但不緊急的大版本更新，或者因為其他因素産生的大工作量疊代，在一個疊代周期裡，一旦我們接下了這個功能，意味着我們直接排除了其他功能。
在這種情況下，很多團隊也會把這個功能優先級滞後，将這個大工作量功能置換成多個小工作量功能，從心理上，從實際接受程度上似乎更容易被認可。畢竟新版本釋出的時候，它顯得多呀~
可是這個大工作量的功能，什麼時候才能開始呢？
或者我們可以延長版本疊代周期，将團隊分成多個小組，每個小組負責一項關鍵任務，即便走得慢，也要多條腿走路。這種模式在一定條件下是可行的，但不知道有多少個團隊能夠接受疊代周期翻倍的版本釋出呢？
7. 體驗優化的功能
我是體驗優化的外行，相對簡單的将體驗優化拆分為：UI優化、互動優化兩類。
體驗優化是我今年年初就想重點提升的能力，也希望能在工作中進行對應的嘗試，可惜臨近年底，我并沒有向前邁出幾步。
包括現階段的市場環境，對于90%的B端産品而言，功能的優先級99%大于體驗的優先級。
這也是現階段B端産品體驗更新的困境。在之前的日更内容中我也粗略的寫過一些。
當然對于這類體驗優化的功能，什麼時候能夠提高優先級呢？大機率是此類問題融入到傳遞過程、客戶回報、合同額、老闆的指令等方面時，因為這些更重要的價值而附帶出來體驗更新的落地。
話說這些更重要的價值附帶到任何功能之上，幾乎都是可以把優先級置頂的吧~
也許按照這種篩選标準和實際情況，那句“先這樣做，後面再優化吧”豈不成了“僞命題”？
因為優化類的需求，一定會被你排到最後呢~
03 初步排列
相信每個團隊針對各自的實際情況都會有不同的排序方式，我第一版的排列順序是1、4、2、3、6、5、7。而且每一個大類都會涉及到很多小功能，有些小功能又屬于“複雜綜合型”，是以真正的排序過程比這裡的描述存在更多的變化。
但是思考一番之後，又調整成了1、5、4、6、2、3、7，也許明天又變了，或者向上司彙報之後，優先級還會調整，但每次排序，都會有自己的理由和權衡在其中。
還有很多功能，可能即便在需求池裡很久了，你也不會評估它的優先級，可能當時就是突發奇想做了個記錄罷了，可能未來幾年都不會做這個功能。
而且我們客觀的知道，随着産品的不斷發展，會有越來越多的高優先級任務落到池子裡，是以當需求池達到一定數量時，該删的删，該合并的合并，“斷舍離”也是我們排期過程中的一個哲學問題。
04 再度排除
随着我們一系列的分析，可能初步彙集出很多優先級高的内容，那下一個版本我們做哪些呢？哪些是可以放到下下個版本再去考慮的呢？
雖然需要在高優先級中尋找更高，但很有可能我們發現這些功能似乎都挺重要的，一時不知道怎麼評判。這時可以采用“排除法”。
以下幾個問題幫你排除錯誤選項：
- 不做這個功能會引起什麼問題？這個問題現在能否承受——兩者權衡取其重
- 這個功能的deadline是什麼時候，能否再延長？——你不試試，怎麼知道對方的底線呢~
- 其他團隊的夥伴能否幫忙分擔——該刷臉就刷臉，請些“外援”來協助
- 這個需求有簡化的可能性嗎？——傳說中的MVP中P
- 各個功能之間是否存在關聯度和先後順序
前面幾個很好了解，重點解釋一下最後一個。
比如現在有ABC三個功能都很重要，但是A是規則類配置，B是應用A配置後的規則進行場景應用，C是通過B形成的資料沉澱進行下一步操作。雖然三個功能都是亟需的，但排期時的優先級大機率是A>B>C。
當然，小部分機率也會遇到，有些特殊場景下，客戶或傳遞團隊對于B更迫切，A的規則設定比較簡單，但B能夠為其帶來顯著的市場價值，則研發團隊直接進行B功能的開發，但前提是快速分析A功能，并手動初始化一些常見規則供B進行使用。
最後，如果我們篩選的下一版本範圍，研發團隊評估後仍然無法按期傳遞，那就是要麼大家卷起來，要麼叫上上司再砍一刀。
當然也可能随着研發團隊的人員補充、熟練度提高、管理規範越來越成熟，有些版本還是可以超額完成。同時我們也需要積極跟進研發進度，在每個版本過程中随時關注裡程碑節點，根據實際情況再進行适度的增減需求。
05 寫在最後
很多問題說起來簡單做起來很難，因為很多功能不是獨立的，互相牽扯互相影響，有時已經排好的計劃在經受外界的某個重大事件影響後，又要重新調整。
有時功能之間的互相制約加上多個客戶方的施壓，導緻傳遞、研發、産品團隊在版本排期上形成“死結”，一個個問題的梳理和解決都需要時間和人力，但這些難題在産品孵化過程，以及産品裂變過程中勢必會逐一遇到（今年上半年我就遇到了類似的情況，最終通過4個團隊合力，2個多月的奮戰最終渡過難關）。
扛過去，也許會撥雲見日；扛過去，也許會有更大的山在等着你。
優先級排期本就是一個複雜、繁瑣、多變的事情，當我們考慮問題更全面，思維角度和格局能更高一點時，做出的決策大機率不會很差。
決策力不僅是善于做決策，更要勇于做決策，勇于承擔決策所帶來的結果。
随着過程的積累，刻意的練習與複盤，相信我們都能做出越來越多相對正确的決策。
專欄作家
不想延期，公衆号：不想延期，人人都是産品經理專欄作家。半路轉行的B端泛金融産品，堅持“以實踐驗證理論，以輸出倒逼成長”的目标。點滴珍貴，重在積累
本文原創釋出于人人都是産品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。