文章分三部分展開描述如何進行產品的需求管理，希望對大家有所啟發。
這是產品硬技能知識中需求分析系列的最後一篇文章，之前已經發布了5篇，分為兩部分，一部分是與用戶需求相關的內容，見下圖所示：
需求往往來源於痛點，當我們發現了一個痛點後，通過用戶研究的方法，發現了痛點背後龐大的市場；市場很大，而我們能力有限，這時候我們就要找到自己能解決的哪一部分，並瞭解這部分用戶的需求，這個過程就是定義用戶需求的過程，在這個過程中我們要弄清楚這裡的用戶角色、使用場景、用戶的問題，這三個方面綜合起來也就是我們常說的用戶需求，在這裡要注意、痛點、市場需求和用戶需求並不是同一個東西。
另一部分是與產品需求相關的內容，見下圖：
當我們弄清楚了用戶需求後，就需要提供一個產品解決方案來解決用戶的需求，在提供解決方案的時候，我們不能只考慮用戶需求，還需要考慮戰略的需求，老闆的需求，產品運營的需求，業務人員的需求，競爭的需求，作為產品經理自己本身的價值觀需求等，基於這些需求，我們來構建產品，在這個產品方案裡面會有很多產品的功能，這個功能就是我們常說的產品需求。
當我們確認了產品需求後，產品就從需求階段進入到了實施階段，接下來就是怎麼管理產品的需求，我們分三部分來講：
- 交付需求
- 制定需求實施計劃
- 控制需求變更
一. 交付需求
產品經理本身不能對產品方案進行實施，需要協調研發，測試，設計等工作人員來共同完成產品需求，這個時候我們就需要將自己梳理的產品需求，傳達給我們需要協調的這些人，這個過程就是交付需求的過程，一般分下面兩個步驟：
第一步：提交需求
提交需求就是把產品需求完整清晰的告知給需要協作的小夥伴，讓他們清楚的瞭解產品的需求， 一般通過以下三個交付物來告知：
1.產品流程圖
產品流程圖是說明產品操作和相應過程的文檔，一般有兩類：
一類是業務流程圖，基於業務邏輯來設計，一般包含主要流程和功能模塊，用來說明產品的架構；
另一類是功能流程圖，一般基於用戶任務來設計，包含人物角色，操作過程的關鍵節點，狀態，判斷，結果等，可以參考下面兩個簡單的小例子（只是為了說明問題，不代表真實流程）：
2.產品原型
上面的流程圖主要偏重於對產品後端和邏輯的描述，而產品原型的作用正好與流程圖互補，偏重於對產品界面信息架構，跳轉邏輯和交互功能的展示說明，通過產品原型，可以將抽象的產品具體化，讓產品更容易被理解，產品原型一般由線框圖構成，在業界大部分人使用axure來製作，有的公司有交互設計師，原型製作工作由交互設計師來承擔，大部分互聯網公司是沒有交互設計師的，所以產品原型一般由產品經理來完成，一般長下面這樣:
3. 產品需求文檔
產品需求文檔，英文Product Requirement Document，簡稱prd, 主要以文字形式來闡述產品的詳細需求，與流程圖，產品原型配合使用來說明產品需求，核心內容是對要實現的每個產品功能及裡面用戶角色、前置條件、後置條件、界面、流程，數據統計等內容的描述，主要面向研發人員，使用word來撰寫和閱讀。 以上這三種交付物是產品經理協作過程中比較常見的交付物，尤其是在大公司中這些是必備的。但這不是強制的標準，很多中小公司都沒有產品文檔這個部分，有的直接用產品原型標註文字說明來做文檔，有的是用excell來寫文檔，所以具體的交付物根據自己所處公司的實際要求來看，這些交付物的目的是為了輔助溝通，不管什麼樣的交付物，只要能達到簡單，快速，高效溝通的目的就可以。
第二步. 評審需求
在提交了產品需求後，需要組織研、運營、設計、測試等人員對產品需求評審，在評審過程中，對產品的目標、背景、問題、思路、解決方案等進行介紹，評審的目的一個是為了讓產品更完善，更具有可行性，另一個目的，也是讓所有參與實施的人員對產品需求認可，目標達成一致，只有被所有參與人員認可並評審通過的產品需求才能被開發，評審是產品工作中非常重要的環節，如果這部分工作做不好，開發過程中的摩擦和修改需求的概率非常大。
二. 制定需求實施計劃
需求評審通過後，就可以開始實施了，在實施前需要和具體的執行人一起來確定執行計劃，一般包含下面幾種情況
1.和研發確定開發計劃，主要包含：
- 誰來做？
- 什麼時候開始做？
- 什麼時候完成？
- 什麼時候測試？
- 什麼時候測試版上線？
- 什麼時候正式版上線？
2.和設計人員確定UI設計計劃，主要包含：
- 誰來設計？
- 什麼時候開始設計？
- 什麼時候出主風格？
- 什麼時候完成設計？
3.和運營人員確定運營計劃，主要包含：
- 誰來運營？
- 什麼時候開始試運營？
- 運營計劃和資源準備？
在這裡面特別要注意下面三點：
第一：明確干係人，每一項需求的實現工作都要具體到某個人，不能似是而非，否則最後出了問題都找不到人；
第二：明確工作中的關鍵時間節點，比如研發什麼時候開始，什麼時候測試，什麼時候結束等問題；
第三：在計劃中要考慮風險因素，和執行成員事先商量好規避的辦法，比如在計劃安排上考慮到後面需求變更，人員變更，技術實現困難等因素，在排期上時間安排的寬鬆一點，這樣有意外情況發生也有時間來調整，另外在執行過程中，可以和團隊小夥伴商量使用每天10分鐘站立晨會的方式對執行過程的工作內容進行把控，讓每個人講一下前一天工作的進展，有沒有延期或者有沒有什麼自己解決不了的，然後再講一下今天的工作計劃，有沒有什麼困難需要幫助，通過對每一天工作內容和進度的把控來保證產品需求能被按照計劃來實現，這個方法在很多互聯網公司使用。
三. 管理需求變更
在需求評審完成後，產品會進行封版，需求池也會凍結，不論什麼需求，都不會加在這個版本里面了，原則上是不能再改變需求了，但是有時候因為一些客觀因素，需求變更又是不可避免的，比如市場環境的變化，之前考慮不周，功能被遺忘，技術實現比預估的困難等因素，所以管理產品需求變更也是產品需求管理一項重要的工作，下面來說說怎麼管理需求變更。
1. 分析需求
需求變更常見的類型有三種，新增，刪除和更改，當產生了新的需求的時候，首先我們使用之前講的需求分析的方法，從痛點－用戶需求－產品需求－到評審這樣一個流程來對需求進行分析，確認需求的價值，看看這個需求是真需求還是偽需求，只有靠譜的需求才有變更的必要和討論的意義，在這裡要防止拍腦袋變更需求，拍腦袋一兩次是可以的，經常隨意改變需求，自己的信譽會下降，而且能力也會被同事質疑。
2. 分析變更的可行性
變更需求通常意味著要調整資源、重新分配任務，並修改前期的工作成果，有時要付出較大的代價，如果動不動就變更需求，項目也許永遠不能按時完成，要不要變更需求，我們可以從以下三個方面來評估：
第一.考慮變更需求對用戶使用的影響：
產品最終是要推向市場面向用戶的，要不要改，首先得考慮對用戶使用的影響，如果一個需求屬於無差異型需求，有沒有對用戶使用都沒有影響，那這樣的需求就沒必要存在，更沒必要變更，如果一個需求屬於基礎型需求，比如社交網站沒有用戶上傳頭像功能，這對社交網站來說是功能的缺陷，沒有頭像，用戶體驗不到社交的氛圍，這樣的需求就得考慮變更。
第二.考慮需求變更帶來的成本因素：
需求變更意味著在計劃外要做很多工作，額外的工作就需要額外的投入，如果本來2個月可以完成的開發的產品，需求變更後，變成了3個月，就多了一個月的人力，物力，財力的投入，不論是大公司還是小公司，每個項目都有預算，如果因為需求變更導致預算超支，即使產品開發完成也得不償失，所以在評估需求是否要變更的時候，要考慮變更帶來的成本大小。
第三.考慮市場的機會成本：
大多數需求變更都會影響產品的上線時間，產品上線時間直接決定了後面投入市場運營，推廣的時間，如果錯過了某個有利的時間窗口期，產品是完善了，但是同樣喪失了市場推廣的有利機會，這樣也是不可取的，所以在考慮變更需求的時候，也要考慮市場因素，不能單純的看功能。
3. 變更需求
變更的需求被評估，確定要進行需求變更後，就可以執行需求變更了，這時候需要做兩方面的工作
- 第一部分是自己獨立完成的工作，需要進行需求變更後的產品流程，功能，原型，文檔製作和變更工作。
- 第二部分是協調其它參與人，及時把需求變動告知相關人員，讓其對工作做出對應的調整。
做完以上兩個工作，需求變更才算真正完成。
四.小結
需求分析系列文章到這裡就結束啦，大家可以翻閱以前的文章進行學習和練習，師父領進門，修行在個人，後面怎麼使用就看大家的了。