作者：簡水
原創發表于微信公眾號：產品經理簡水
產品設計完成后，PRD文檔、交互設計稿和產品原型已經準備好了，接下來就要到開發環節了。
但是，想要讓開發接受產品需求沒有那么容易，因為開發和測試人手不夠，沒有時間。沒有時間！沒有時間！
大的互聯網公司的開發和測試好幾萬人，為啥還一直喊著缺人？
其實真的是人手不夠。
公司看起來人多，但是分攤到各個業務線，再到具體的業務組，就沒剩下幾個人了。
業界公認的產品經理和開發人員的比例是1：5。
你可以看看自己對口的開發人員有幾個？產品經理再考慮一下自己身上背的KPI，就知道人員永遠都是短缺的。
各個團隊負責人的一個重要工作就是求簡歷，招人！
1 產品需求管理
產品是要做滴，開發團隊的接收能力也是有限滴。
這個時候，我們就需要引入產品需求管理的流程。
產品需求管理，說穿了，就是推遲甚至砍掉一部分產品需求，而且是合理合法通過規范化的手段進行操作。
盡管這些產品需求已經通過了可行性評估和立項階段，當時大家討論認為是要做的產品，但還是有可能被砍掉。
1.1 產品需求會，一般是1-2周時間開一次。時間太短的話，開發人員手上的活還沒有結束；時間太長，產品需求積壓太嚴重。需求會上，主要確定哪些產品需求要做？哪些產品需求需要推遲？哪些產品需求要砍掉？這個一般也叫PK會，產品經理需要陳述產品定位，說明產品價值，為自己的產品代言。只有在PK中勝出，開發才能接受產品需求。
1.2 產品需求管理流程。這個主要是跟蹤產品需求的進度，明確需求的狀態，以及在狀態變更時發郵件同步給相關的干系人。一般是一個公司內部的線上管理工具。如果沒有專門的工具，使用excel表格維護，群發郵件也可以應付。
1.3 產品需求變更。是指項目開發或測試過程中，發生的需求變更的情況。這種情況有主觀原因，也有客觀原因引起。如：產品方案的邏輯或功能有問題；遇到技術難題無法解決；或競爭對手推出了新功能。需求變更是項目延期的一個很大風險，應盡量避免主觀原因的需求變更，天馬行空款的產品經理要記得控制自己要創造的欲望。
2 項目管理
2.1 PM vs PD，項目 vs 產品。PM是項目經理，PD是產品經理，兩者關心的內容不同。PM只對項目負責，監督項目資源和項目目標的完成情況。PD關心產品開發是否按照設計不折不扣的執行，以及遇到問題怎么對產品進行微調。項目和產品是多對多的關系，一個項目可能包含多個產品，一個完整的產品也可以分多個項目完成。
2.2 項目kickoff。經過產品需求會，開發同意接收這個產品需求后，還需要進行產品需求評審、技術方案的評審以及測試用例評審。產品需求評審，由產品經理召集，主要向開發、測試人員把需求講清楚。技術方案評審會，由項目開發負責人召集，介紹技術方案，評估所需資源，并給出具體的時間計劃。技術方案通過評審后，項目正式kickoff。產品經理此時就會把主要精力投入到產品下一個迭代的設計中了。
2.3 項目跟蹤和管理。很多產品經理同時兼任了項目經理的責任，而且是同時管理多個項目。因此需要查看項目進度是否正常，是否遇到了問題？技術人員每天會同步項目進度信息，但建議產品經理還是要多主動詢問，便于及時發現問題。項目管理的工具，建議采用線上工具，這樣大家都可是看到實時統一的信息。
3 敏捷開發
互聯網產品的需求一開始并不明朗，需要經常的依據用戶使用情況進行調整，敏捷開發可以加快開發進度，及時滿足用戶需求。
敏捷開發的不足：
產品不穩定。產品更新升級頻率太高，代碼只要調整都會有風險，對產品的穩定性有一定影響。另外，開發和測試人員的工作壓力大，流程簡化后，容易出現問題。
產品后期升級維護存在問題。敏捷開發的文檔不完善，導致文檔與產品實際情況不符的情況時有發生。在團隊人員頻繁流動的今天，這給產品升級和后續開發帶來了很大麻煩，經常出現換一撥開發人員就要重構一次產品代碼的情況。
敏捷開發的一些原則：
團隊要坐在一起，面對面的溝通效率永遠都是最高的。如有必要，就找個會議室封閉開發。
晨會。每天早上團隊所有成員開站會，溝通項目進度、完成情況、遇到的問題以及今天的工作計劃。晨會的內容需要記錄下來，發布到在線項目管理工具中，方便團隊成員和干系人隨時查閱。
有問題隨時討論。對討論的問題一定要有結論、負責人和解決期限。
下班前再開一次站會，同步今天的進展情況。沒有完成的同事，還有時間加班趕一下。
產品開發的同時，產品經理和設計師要開始后續版本的設計工作，一般需要領先1-2個版本。
對于產品的線上問題，最好采用值班形式輪流負責。否則在后期會占用核心開發人員的大量時間，影響產品進度。
在產品穩定期，產品需求不多的時候，開發人員要抓緊時間進行系統改造，打好技術基礎以迎接下一輪的用戶需求爆發。
4 測試
產品測試主要是對功能和可用性的測試，目的是為了檢驗最后做出來的產品是否滿足之前產品設計的要求，另外就是檢驗產品是否有明顯的缺陷和錯誤。
測試環節主要包含測試用例的設計和評審，bug管理和用戶測試部分相關的內容。
測試是保證產品質量、維護產品良好口碑的最后一個環節，產品經理一定要對這個環節足夠重視。
4.1 測試用例：可以用思維導圖+文檔的方式，思維導圖保證覆蓋面，文檔記錄測試案例。測試用例設計完成后，需要組織評審會議。產品經理一定要參加測試用例評審會，認真核對用例和具體的測試方案。
4.2 bug管理：使用在線工具進行管理，測試人員在這里提交bug，并同步給開發人員、產品經理、設計師等團隊人員。有些bug需要產品經理確認是否為設計缺陷？
4.3 用戶測試：有內測、公測、beta版本、A/B test等多種形式。
5 一句話總結
5.1 產品需求管理
- 產品需求會：PK勝出的需求才能活下來。
- 需求管理流程：不做這個需求，真的不是我的責任。
- 產品需求變更：能不變，最好別變。
5.2 項目管理
- PM vs PD：PD也要干PM的活。
- 項目kickoff：需求終于有人接了。
- 項目管理：你不盯著，資源就會被調走了。
5.3 敏捷開發
- 敏捷開發：催的急，不敏捷不行呀。
5.4 測試
- 測試用例：一定要面面俱到。
- bug管理：有bug？程序員說：不可能！
- 用戶測試：一定要找小白用戶測試。
全文完
