起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識關于需求管理的產品工作流程方法論
筆者在前文《關于洞察挖掘產品需求的思考與總結》中介紹了收集和挖掘需求的方法。本篇將接前文，介紹在獲取到一些需求之后，如何進行需求管理？
在相對成熟的產品團隊里，需求管理是產品經理的核心工作之一，團隊內可使用云協作類的應用軟件進行協作管理。我們從以下幾個方面來討論需求管理：
一、需求方案初判
作為產品經理，需要在溝通需求時，對需求的實現方案、所耗成本和資源、預期效果、是否有實現同樣目標的低成本替代方案等，有一定的判斷力，即需求方案初判。
舉一個案例：
距離活動日只剩3天，某客戶部門提出要增加一個需求：活動日當天，做一個購買套餐，加價1元即可獲贈會員的優惠活動。
分析當時的客觀情況：
- 前后端開發人員都在滿負荷的開發周期中，較困難調動人員臨時支撐新增加的需求；
- 之前的訂單體系中不支持在一個訂單里同時購買套餐和會員，此前未考慮類似這樣的需求的拓展性，服務端有一定的開發量，客戶端也需要開發適配并更新線上版本，產品、設計、開發、測試、審核發布一共只有3天時間；
- 業務部門對此需求上線后可創造收益的預期暫不明確。
綜合來看，如期實現這個需求的難度較高。那么有沒有替代方案可以滿足該部門的需求呢？
經再次溝通了解到，該部門的活動方案所涉及到的用戶基本都會有電話和微信溝通，只要工作人員在活動日通過電話溝通確認用戶購買這一促銷方案，微信發送公司的收款二維碼，讓用戶掃碼支付1元后，由工作人員在后臺批量為用戶開通會員即可。
換用了一個思路，便用很輕的方式解決了該客戶部門的緊急需求。
其實從產品的角度來看，這也算是一個產品MVP。如果該活動經分析，效果和成本可以有很好的平衡，即可作為一個需求，再排期到版本里進行開發，實現線上所有用戶都能自助購買這一促銷優惠方案。
在這個案例里，產品經理對當時產品開發資源、時間緊急度、替代方案的思考，就是對一個需求的方案初判的過程。對每一個需求都有這樣的思考和判斷過程，會更合理的對待需求和待解決的問題。
當然，在產品經理做了需求方案的初判之后，和業務部門的溝通也是非常重要的。共同站在產品和公司的立場出發是跨部門溝通與合作的基礎原則，溝通確認性價比最高的方案，讓產品和功能以更敏捷的方式推向市場，試錯迭代，快速優化。
二、需求優先級
在通過需求的初判之后，會擋掉一些不合理或可以采取更輕的解決方案的需求，對于留下來的需求，需要記錄進需求池。
在記錄進需求池的時候，需要對需求的優先級進行排序標注，有兩種常見的排序方法。一種是基于四象限法則，另一種則是基于KANO模型。
1. 四象限法則
有些情況下，因為需求的來源和影響因素不同，在排期上總會不易協調。
營銷部門需要我們配合做活動，業務部門著急需要滿足大客戶的要求，開發需要留出做加固，運營部門需要解決用戶投訴的體驗問題……
所以有時產品經理抉擇起來會很痛苦，需要綜合權衡排期和利弊，考慮最合理并且能說服別人的理由。
最常用的判斷方法是 Stephen Covey提出的緊急重要四象限法則，如圖所示：
我們把重要并且緊急的需求排在最前，重要但不緊急的需求其次，不重要但緊急的需求再次，最后是不重要不緊急的需求。
在判斷需求是否重要時，可以參考如下：
- 不做，會造成問題和負面影響
- 做了，會產生正向的效應和影響
- 跟戰略布局有關
- 跟核心用戶利益有關
- 跟大部分用戶權益有關
- 跟效率、成本、收入、利潤有關
- 跟用戶體驗有關
在判斷需求是否緊急，可以參考如下：
- 不做，錯誤會持續發生并造成嚴重影響
- 不做，短期內可控但長期會有糟糕的影響
- 做了，立刻能解決很多問題、產生正面的影響
- 做了，在一段時間后可以有良好的效果
2. KANO模型
另外一種很常用的方法是東京理工大學教授狩野紀昭（ Noriaki Kano）提出的KANO模型，是對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。如圖所示：
基于四象限法則或KANO模型，可以完成需求優先級的判斷。通常我們會用P1、P2、P3、P4來標注不同的優先級，P1優先級最高，P4最低。
三、需求來源和負責人
確認完需求的優先級之后，將需求記錄進需求池。我個人在帶領團隊工作中，使用的需求池管理模版很簡潔，如圖所示：
需要在需求池To-do List中需要記錄的一些字段都是非常重要的。我們在前文中有提到挖掘需求的幾種不同方式，再加上各個部門提出的多樣的需求，因而需求的來源是較復雜的。
我們在記錄的時候，將“需求來源”廣義定義為：需求的來源方，或產品經理所挖掘需求的方式和其成立的結論支撐。
需求來源和需求負責人的記錄，是為了在出現人員變動或排期較長已經記不清的情況下，能夠通過當時的需求負責人和需求來源的方式推演復現需求。
此外，需求負責人需對需求從提出到設計開發到上線數據分析的全過程負責，通過表格也能夠一目了然每一項具體需求的責任人是誰。
四、需求排期
我們這里所討論的需求排期，指的是還未進入設計和開發階段的需求排入到具體開發版本的情況。
之后筆者在寫到需求評審完成之后，交付開發的時候所描述的需求排期，指的是已經進入到設計開發階段的需求實現的生產要素UI設計、前端開發、后端開發、測試各需要的時間以及適當并行分工的情況。
在確認了該需求被記錄進To-do List的時候，產品經理需要綜合該產品線的全局需求優先級情況，對該需求進行版本排期，并根據版本排期推算大致的可上線時間范圍。
這么做的原因主要是：需求所涉及到的業務、運營、市場等部門，往往需要根據大致的可上線時間，做提前的安排和規劃。尤其是連接線下業務的功能，需要線下提前部署準備好功能上線后的工作。
產品經理在確認需求的版本排期的時候也需要和涉及到的相關部門負責人員溝通，并在溝通后以以郵件的形式確認并通知。
做好產品，從產品思維階梯到工作流程執行都需要有適合自己的方法論，筆者會從建立思維框架、需求挖掘、需求管理、產品方案設計、原型設計、產品需求文檔編寫、UI設計、評審與會議、跟進協調開發測試、產品發布、數據分析與需求驗證、數據驅動與敏捷開發的流程節點，分享自己的方法論，不定期更新，感謝閱讀。
下一篇文章，主要和大家分享《產品工作流程與方法論—產品方案設計》。
#專欄作家#
吉倩倩，人人都是產品經理專欄作家，專注于互聯網產品與運營領域的研究和總結，在用戶研究，需求分析，產品設計，數據研究，產品運營方面有深刻的思考。
本文原創發布于人人都是產品經理，未經許可，不得轉載。
題圖來自 Unsplash，基于 CC0 協議
期待你的新文章《產品工作流程與方法論—產品方案設計》
寫得很好！有幾種方法論來指導，融會貫通后會得心應手，補充些實例和故事就更好了。