作者：簡水
原創(chuàng)發(fā)表于微信公眾號：產(chǎn)品經(jīng)理簡水

產(chǎn)品設(shè)計完成后验夯，PRD文檔芦圾、交互設(shè)計稿和產(chǎn)品原型已經(jīng)準(zhǔn)備好了昔案，接下來就要到開發(fā)環(huán)節(jié)了。

但是愚隧，想要讓開發(fā)接受產(chǎn)品需求沒有那么容易蒂阱，因為開發(fā)和測試人手不夠，沒有時間奸攻。沒有時間蒜危！沒有時間虱痕！

大的互聯(lián)網(wǎng)公司的開發(fā)和測試好幾萬人睹耐，為啥還一直喊著缺人？

其實真的是人手不夠部翘。

公司看起來人多硝训，但是分?jǐn)偟礁鱾€業(yè)務(wù)線，再到具體的業(yè)務(wù)組，就沒剩下幾個人了窖梁。

業(yè)界公認(rèn)的產(chǎn)品經(jīng)理和開發(fā)人員的比例是1：5赘风。

你可以看看自己對口的開發(fā)人員有幾個？產(chǎn)品經(jīng)理再考慮一下自己身上背的KPI纵刘，就知道人員永遠(yuǎn)都是短缺的邀窃。

各個團(tuán)隊負(fù)責(zé)人的一個重要工作就是求簡歷，招人假哎！

圖片來自Unsplash

1 產(chǎn)品需求管理

產(chǎn)品是要做滴瞬捕，開發(fā)團(tuán)隊的接收能力也是有限滴。

這個時候舵抹，我們就需要引入產(chǎn)品需求管理的流程肪虎。

產(chǎn)品需求管理，說穿了惧蛹，就是推遲甚至砍掉一部分產(chǎn)品需求扇救，而且是合理合法通過規(guī)范化的手段進(jìn)行操作。

盡管這些產(chǎn)品需求已經(jīng)通過了可行性評估和立項階段香嗓，當(dāng)時大家討論認(rèn)為是要做的產(chǎn)品迅腔，但還是有可能被砍掉。

1.1 產(chǎn)品需求會靠娱，一般是1-2周時間開一次钾挟。時間太短的話，開發(fā)人員手上的活還沒有結(jié)束饱岸；時間太長掺出，產(chǎn)品需求積壓太嚴(yán)重。需求會上苫费，主要確定哪些產(chǎn)品需求要做汤锨？哪些產(chǎn)品需求需要推遲？哪些產(chǎn)品需求要砍掉百框？這個一般也叫PK會闲礼，產(chǎn)品經(jīng)理需要陳述產(chǎn)品定位，說明產(chǎn)品價值铐维，為自己的產(chǎn)品代言柬泽。只有在PK中勝出，開發(fā)才能接受產(chǎn)品需求嫁蛇。

1.2 產(chǎn)品需求管理流程锨并。這個主要是跟蹤產(chǎn)品需求的進(jìn)度，明確需求的狀態(tài)睬棚，以及在狀態(tài)變更時發(fā)郵件同步給相關(guān)的干系人第煮。一般是一個公司內(nèi)部的線上管理工具解幼。如果沒有專門的工具，使用excel表格維護(hù)包警，群發(fā)郵件也可以應(yīng)付撵摆。

1.3 產(chǎn)品需求變更。是指項目開發(fā)或測試過程中害晦，發(fā)生的需求變更的情況特铝。這種情況有主觀原因，也有客觀原因引起壹瘟。如：產(chǎn)品方案的邏輯或功能有問題苟呐；遇到技術(shù)難題無法解決；或競爭對手推出了新功能俐筋。需求變更是項目延期的一個很大風(fēng)險牵素，應(yīng)盡量避免主觀原因的需求變更，天馬行空款的產(chǎn)品經(jīng)理要記得控制自己要創(chuàng)造的欲望澄者。

2 項目管理

2.1 PM vs PD笆呆，項目 vs 產(chǎn)品。PM是項目經(jīng)理粱挡，PD是產(chǎn)品經(jīng)理赠幕，兩者關(guān)心的內(nèi)容不同。PM只對項目負(fù)責(zé)询筏，監(jiān)督項目資源和項目目標(biāo)的完成情況榕堰。PD關(guān)心產(chǎn)品開發(fā)是否按照設(shè)計不折不扣的執(zhí)行，以及遇到問題怎么對產(chǎn)品進(jìn)行微調(diào)嫌套。項目和產(chǎn)品是多對多的關(guān)系逆屡，一個項目可能包含多個產(chǎn)品，一個完整的產(chǎn)品也可以分多個項目完成踱讨。

2.2 項目kickoff魏蔗。經(jīng)過產(chǎn)品需求會，開發(fā)同意接收這個產(chǎn)品需求后痹筛，還需要進(jìn)行產(chǎn)品需求評審莺治、技術(shù)方案的評審以及測試用例評審。產(chǎn)品需求評審帚稠，由產(chǎn)品經(jīng)理召集谣旁，主要向開發(fā)、測試人員把需求講清楚滋早。技術(shù)方案評審會榄审，由項目開發(fā)負(fù)責(zé)人召集，介紹技術(shù)方案馆衔，評估所需資源瘟判，并給出具體的時間計劃怨绣。技術(shù)方案通過評審后角溃，項目正式kickoff拷获。產(chǎn)品經(jīng)理此時就會把主要精力投入到產(chǎn)品下一個迭代的設(shè)計中了。

2.3 項目跟蹤和管理减细。很多產(chǎn)品經(jīng)理同時兼任了項目經(jīng)理的責(zé)任，而且是同時管理多個項目。因此需要查看項目進(jìn)度是否正常著洼，是否遇到了問題易茬？技術(shù)人員每天會同步項目進(jìn)度信息，但建議產(chǎn)品經(jīng)理還是要多主動詢問萧吠，便于及時發(fā)現(xiàn)問題左冬。項目管理的工具，建議采用線上工具纸型，這樣大家都可是看到實時統(tǒng)一的信息拇砰。

圖片來自Unsplash

3 敏捷開發(fā)

互聯(lián)網(wǎng)產(chǎn)品的需求一開始并不明朗，需要經(jīng)常的依據(jù)用戶使用情況進(jìn)行調(diào)整狰腌，敏捷開發(fā)可以加快開發(fā)進(jìn)度除破，及時滿足用戶需求。

敏捷開發(fā)的不足：

1. 產(chǎn)品不穩(wěn)定琼腔。產(chǎn)品更新升級頻率太高瑰枫，代碼只要調(diào)整都會有風(fēng)險，對產(chǎn)品的穩(wěn)定性有一定影響丹莲。另外光坝，開發(fā)和測試人員的工作壓力大，流程簡化后甥材，容易出現(xiàn)問題教馆。

2. 產(chǎn)品后期升級維護(hù)存在問題。敏捷開發(fā)的文檔不完善擂达，導(dǎo)致文檔與產(chǎn)品實際情況不符的情況時有發(fā)生土铺。在團(tuán)隊人員頻繁流動的今天，這給產(chǎn)品升級和后續(xù)開發(fā)帶來了很大麻煩板鬓，經(jīng)常出現(xiàn)換一撥開發(fā)人員就要重構(gòu)一次產(chǎn)品代碼的情況悲敷。

敏捷開發(fā)的一些原則：

1. 團(tuán)隊要坐在一起，面對面的溝通效率永遠(yuǎn)都是最高的俭令。如有必要后德，就找個會議室封閉開發(fā)。

2. 晨會抄腔。每天早上團(tuán)隊所有成員開站會瓢湃，溝通項目進(jìn)度理张、完成情況、遇到的問題以及今天的工作計劃绵患。晨會的內(nèi)容需要記錄下來雾叭，發(fā)布到在線項目管理工具中，方便團(tuán)隊成員和干系人隨時查閱落蝙。

3. 有問題隨時討論织狐。對討論的問題一定要有結(jié)論、負(fù)責(zé)人和解決期限筏勒。

4. 下班前再開一次站會移迫，同步今天的進(jìn)展情況。沒有完成的同事管行，還有時間加班趕一下厨埋。

5. 產(chǎn)品開發(fā)的同時，產(chǎn)品經(jīng)理和設(shè)計師要開始后續(xù)版本的設(shè)計工作捐顷，一般需要領(lǐng)先1-2個版本荡陷。

6. 對于產(chǎn)品的線上問題，最好采用值班形式輪流負(fù)責(zé)套菜。否則在后期會占用核心開發(fā)人員的大量時間亲善，影響產(chǎn)品進(jìn)度。

7. 在產(chǎn)品穩(wěn)定期逗柴，產(chǎn)品需求不多的時候蛹头，開發(fā)人員要抓緊時間進(jìn)行系統(tǒng)改造，打好技術(shù)基礎(chǔ)以迎接下一輪的用戶需求爆發(fā)戏溺。

圖片來自Unsplash

4 測試

產(chǎn)品測試主要是對功能和可用性的測試渣蜗，目的是為了檢驗最后做出來的產(chǎn)品是否滿足之前產(chǎn)品設(shè)計的要求，另外就是檢驗產(chǎn)品是否有明顯的缺陷和錯誤旷祸。

測試環(huán)節(jié)主要包含測試用例的設(shè)計和評審耕拷，bug管理和用戶測試部分相關(guān)的內(nèi)容。

測試是保證產(chǎn)品質(zhì)量托享、維護(hù)產(chǎn)品良好口碑的最后一個環(huán)節(jié)骚烧，產(chǎn)品經(jīng)理一定要對這個環(huán)節(jié)足夠重視。

4.1 測試用例：可以用思維導(dǎo)圖+文檔的方式闰围，思維導(dǎo)圖保證覆蓋面赃绊，文檔記錄測試案例。測試用例設(shè)計完成后羡榴，需要組織評審會議碧查。產(chǎn)品經(jīng)理一定要參加測試用例評審會，認(rèn)真核對用例和具體的測試方案。

4.2 bug管理：使用在線工具進(jìn)行管理忠售，測試人員在這里提交bug传惠，并同步給開發(fā)人員、產(chǎn)品經(jīng)理稻扬、設(shè)計師等團(tuán)隊人員卦方。有些bug需要產(chǎn)品經(jīng)理確認(rèn)是否為設(shè)計缺陷？

4.3 用戶測試：有內(nèi)測腐螟、公測愿汰、beta版本困后、A/B test等多種形式乐纸。

5 一句話總結(jié)

5.1 產(chǎn)品需求管理

• 產(chǎn)品需求會：PK勝出的需求才能活下來。
• 需求管理流程：不做這個需求摇予，真的不是我的責(zé)任汽绢。
• 產(chǎn)品需求變更：能不變，最好別變侧戴。

5.2 項目管理

• PM vs PD：PD也要干PM的活宁昭。
• 項目kickoff：需求終于有人接了。
• 項目管理：你不盯著酗宋，資源就會被調(diào)走了积仗。

5.3 敏捷開發(fā)

• 敏捷開發(fā)：催的急，不敏捷不行呀蜕猫。

5.4 測試

• 測試用例：一定要面面俱到寂曹。
• bug管理：有bug？程序員說：不可能回右！
• 用戶測試：一定要找小白用戶測試隆圆。

全文完