0
| 本文作者： 劉飛 | 2016-05-11 17:06 |
按：本文作者劉飛，前錘子科技產(chǎn)品經(jīng)理。
產(chǎn)品經(jīng)理們?cè)谔幚韥碜圆煌胤降男枨髸r(shí)，有著不同的工作方式和方法：分類管理、定期維護(hù)等不一而足。那么，對(duì)于需求的整個(gè)生命周期來說，我們究竟應(yīng)該怎么做呢？
下面是我的經(jīng)驗(yàn)。
需求的來源有很多。業(yè)務(wù)越復(fù)雜，需求就越雜。一個(gè)淘寶，產(chǎn)品需求就可以拆分成分類、檢索、排序、商品展示、營(yíng)銷活動(dòng)、支付、配送、售后等等。
你的職級(jí)越高，也代表著身邊人提需求的可能性越大。初入行的產(chǎn)品專員或助理，主要是得到被安排的任務(wù)；初級(jí)產(chǎn)品經(jīng)理，需求來源主要是用戶和上級(jí)；產(chǎn)品負(fù)責(zé)人，需求來源就要增加老板和其他相關(guān)部門； 而作為老板，誰(shuí)都可能跟他提產(chǎn)品需求。
所以在獲取到需求這一時(shí)刻，就必須做一個(gè)判斷，并且記錄。如果不做判斷堆在那里，等做的時(shí)候根本沒辦法梳理出頭緒，可能大部分時(shí)間都在疲于折騰需求清單。記錄當(dāng)然是為了方便回溯。獲取到的再小的需求也記下來，不要指望你隨時(shí)能想起來每天聽過的每個(gè)需求。
做判斷的內(nèi)容具體是什么呢？
判斷需求本身的重要性
同樣是頁(yè)面寫錯(cuò)了一個(gè)字，把「登錄」寫成「登陸」，和把「獎(jiǎng)勵(lì) 15 元」寫成「獎(jiǎng)勵(lì) 50 元」，重要性不言而喻吧。有個(gè)大致的預(yù)估。
考慮需求來源
需求來源會(huì)表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他認(rèn)為特別重要，就暫且把這個(gè)當(dāng)成特別重要的，這是政治任務(wù)。再比如是用戶提到的，但細(xì)想他并不是目標(biāo)用戶，他的需求就不必太關(guān)注。
簡(jiǎn)要得到需求背景
我自己工作中有三類需求絕對(duì)不記：
沒說清楚原因的，不記（你做個(gè) XX 出來，別管那么多）；
不說清邏輯的，不記（啊，這里我也沒搞懂，你先看看）；
不是實(shí)際遇到的，不記（哎，我覺得可能有人會(huì)這樣用）。
需求背景沒搞清楚，完全是浪費(fèi)時(shí)間。有一句話的記錄，但不說背景，也是浪費(fèi)時(shí)間。記的時(shí)候，我會(huì)確保格式是問題 + 方案，「XXX 在用我們的 XX 功能時(shí)，感覺 XXX，我們可以嘗試 XXX 這樣的方案」。
最后，依據(jù)這三個(gè)因素，判斷屬于大致哪個(gè)類別的。一般的需求管理都會(huì)分 P0-P3 或者 P1-P4，總之先打個(gè)標(biāo)簽。這里的技巧是盡量標(biāo)記為比估計(jì)的更重要一層的需求，就是你感覺是 P2 的，暫且先標(biāo)為 P1。這樣以防錯(cuò)漏，低優(yōu)先級(jí)的標(biāo)成高的沒關(guān)系，但高優(yōu)先級(jí)的標(biāo)低了會(huì)出現(xiàn)麻煩。這時(shí)候的預(yù)估往往不準(zhǔn)確，但沒關(guān)系，等后面第二步再說。
比如這樣：
隔一段時(shí)間，我們會(huì)開需求討論會(huì)，整理需求池，也就是記錄所有獲取到需求的表單。
我們會(huì)詳細(xì)討論每個(gè)需求的情況，確認(rèn)幾個(gè)事項(xiàng)：
1）需求的優(yōu)先級(jí)
之前的判斷是粗估，這里的判斷就要精細(xì)了。一般需求的重要程度很難量化，尤其來源復(fù)雜的情況下。營(yíng)銷部門著急要我們配合做活動(dòng)，不做就少賺好多錢，業(yè)務(wù)部門著急要我們配合做一套自動(dòng)化結(jié)賬工具，做了能節(jié)省很多成本... 有時(shí)抉擇很痛苦。
這里還是用最常用的判斷方法，緊急重要四象限法則（請(qǐng)自行百度「四象限法則」）。重要程度大致按這種排序：
不做會(huì)造成嚴(yán)重的問題和惡劣的影響的
做了會(huì)產(chǎn)生巨大好處和極佳效果的
跟重要合作對(duì)象或投資人有關(guān)的
跟核心用戶利益有關(guān)的
跟大部分用戶權(quán)益有關(guān)的
跟效率或成本有關(guān)的
跟用戶體驗(yàn)有關(guān)的
緊急程度按這個(gè)排序：
不做錯(cuò)誤會(huì)持續(xù)發(fā)生，造成嚴(yán)重影響
在一定時(shí)間內(nèi)可控，但長(zhǎng)期會(huì)有糟糕的影響
做了立刻能解決很多問題、產(chǎn)生正面的影響
做了在一段時(shí)間后可以有良好的效果
大家把能考慮到的因素想全，會(huì)標(biāo)上 P1 - P4 的優(yōu)先級(jí)。
2）方案的方向
需求有不同的解決辦法，我們會(huì)討論清楚到底用哪種解決。比如我們發(fā)現(xiàn)有刷單現(xiàn)象，可以事前提醒，告知用戶目前地理位置或訂單信息有嫌疑；可以事中限制，必須到達(dá)指定地點(diǎn)、拍攝當(dāng)?shù)卣掌鹊炔僮鱽硐拗朴脩?；可以事后懲戒，提供給客服或者業(yè)務(wù)部門疑似刷單的名單和證據(jù)，罰款或者封號(hào)。這幾項(xiàng)到底做哪個(gè)？還是做其中哪幾個(gè)？?jī)?yōu)劣在哪？需要好好討論。
有時(shí)會(huì)有大概的方向，再去跟相關(guān)部門和需求相關(guān)的同事確認(rèn)。這不在本文討論范圍內(nèi)，暫且不提。
3）指定負(fù)責(zé)人
我之前經(jīng)歷過兩種需求分配制度。一種是每個(gè)人負(fù)責(zé)的需求范圍有清晰的邊界，那需求對(duì)應(yīng)哪個(gè)模塊，就直接分配即可；另一種是團(tuán)隊(duì)作戰(zhàn)，每次指定或者認(rèn)領(lǐng)，誰(shuí)都有可能接手任意需求。
前一種的好處在，模塊清晰，負(fù)責(zé)人可以對(duì)自己負(fù)責(zé)的部分足夠熟悉，但缺點(diǎn)是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閑，因?yàn)樾枨蟛皇瞧骄茨K分布的。
在我們需求分配時(shí)，大致還是按照模塊分配，但在出現(xiàn)工作量不平衡的情況時(shí)，會(huì)酌情調(diào)整一下，讓活少的同事予以配合。
不管怎么樣，一定一定要指定負(fù)責(zé)人，他需要對(duì)需求負(fù)責(zé)，一直到產(chǎn)品上線后，出了的問題他也要承擔(dān)責(zé)任。要保證運(yùn)營(yíng)良好的工作責(zé)任制。
4）劃定時(shí)間節(jié)點(diǎn)
許多產(chǎn)品經(jīng)理會(huì)疏漏這點(diǎn)，只是覺得盡快去做，但總是做不完。
時(shí)間節(jié)點(diǎn)至少也要包括方案完成的時(shí)間。就是這個(gè)需求，能夠完好提交給開發(fā)的時(shí)間。如果沒有這個(gè)時(shí)間，對(duì)需求的管理就沒有一點(diǎn)意義了。
另外，如果是要跟相關(guān)部門再確認(rèn)、或者要跟用戶調(diào)研、或者要統(tǒng)計(jì)各種數(shù)據(jù)再作判斷的需求，那還要有調(diào)研 / 討論完成的時(shí)間。
這個(gè)時(shí)間節(jié)點(diǎn)的劃定，主要是按照方案的復(fù)雜程度，用經(jīng)驗(yàn)做個(gè)簡(jiǎn)單判斷。最長(zhǎng)的時(shí)間周期也不能超過一周，保證需求的推動(dòng)進(jìn)度，因?yàn)楹茈y有復(fù)雜程度超過一周的產(chǎn)品需求。對(duì)于有嚴(yán)格上線時(shí)間的需求（經(jīng)常會(huì)出現(xiàn)，比如很苛刻的老板需求、投資人需求、政府需求等），要倒推出最合理又富有余地的時(shí)間節(jié)點(diǎn)。
討論完剛剛?cè)氤氐囊慌枨螅覀儠?huì)再整理和討論其它狀態(tài)（有方案或者調(diào)研結(jié)論）的需求。這樣會(huì)議結(jié)束，每條需求都會(huì)得到更新。
我們?cè)谶@個(gè)時(shí)刻，一般會(huì)讓負(fù)責(zé)的產(chǎn)品經(jīng)理，及時(shí)更新需求狀態(tài)給需求來源方。當(dāng)然，來源方 95% 的情況下會(huì)對(duì)進(jìn)度不滿意，這很正常，但除非來源方有確鑿的理由，我們不會(huì)輕易調(diào)整優(yōu)先級(jí)和時(shí)間節(jié)點(diǎn)。
有了確切方案，我們會(huì)盡快跟研發(fā)的同事做可行性評(píng)審。這一步必不可少。我感覺題主出現(xiàn)的「落不了地」和「頻繁更改」的問題，要著重在這個(gè)步驟里解決。
可行性評(píng)審上，完成的是對(duì)需求的大致評(píng)估，要做的有這么幾件事：
1）方案本身的可行性
在技術(shù)方案上，是不是能夠完成？就是讓技術(shù)部門評(píng)估這個(gè)問題。
2）有沒有更好的方案？
一定要跟技術(shù)部門灌輸清晰的需求背景，讓他們也想一些可行的方案。方案未必是完整、準(zhǔn)確的，但他們提供的思路，一般是可行性較高的。
3）涉及的產(chǎn)品和技術(shù)環(huán)節(jié)有哪些？
這個(gè)需要相關(guān)的同事仔細(xì)討論。尤其是很多公司產(chǎn)品線比較多，有可能存在牽一發(fā)動(dòng)全身的情況，如果相關(guān)的產(chǎn)品同事和技術(shù)同事不知情，必然會(huì)延期，必然會(huì)扯皮，必然會(huì)造成麻煩，必然會(huì)有各種改動(dòng)。即便是再小的產(chǎn)品，也要分前后端，讓技術(shù)的同事來判斷有哪些人需要知情和參與評(píng)估。
4）方案的成本如何？
看方案需要多少人、多少資源、多少時(shí)間來完成，也要看方案在技術(shù)層面耗費(fèi)的不太明顯的成本，比如服務(wù)器成本、帶寬成本，給用戶造成的流量成本等。
有了這樣的討論，會(huì)議輸出的，就是比較嚴(yán)謹(jǐn)?shù)目蓤?zhí)行方案（或草稿）了。
如果會(huì)上遇到各種問題，要確認(rèn)解決問題的時(shí)間節(jié)點(diǎn)。
開發(fā)需求的次序，我們不是完全按照需求池里的需求優(yōu)先級(jí)來的。剛才說到，在可行性評(píng)估會(huì)上，我們會(huì)核算大致的需求成本，那成本結(jié)合需求的優(yōu)先級(jí)，就可以得出需求的性價(jià)比了。
我在 創(chuàng)業(yè)公司產(chǎn)品經(jīng)理怎么做？ 提到過具體的方法，這里不再贅述。大概是用這樣的表格：
提交開發(fā)之后，相當(dāng)于關(guān)閉需求。原則上，本次迭代不再加入新的需求。
當(dāng)然啦，如果什么事情都是原則上那樣... 就不會(huì)出現(xiàn)這么多扯皮的情況了。
在開發(fā)中，扯皮的問題歸納起來就是三種：需求太多，沒按時(shí)做完；需求有改動(dòng)，導(dǎo)致了額外工作量以及開發(fā)的不滿；有新的緊急需求，導(dǎo)致發(fā)布延期。
這三種問題，再抽象一下，導(dǎo)致的原因很多，大概有幾類，分別是：
1）產(chǎn)品方案不完整
方案不完整往往是沒有考慮全面。這個(gè)跟需求管理本身沒關(guān)系，就是在出方案的途中，看能不能把事情想全。
之前我們經(jīng)常出現(xiàn)，做的時(shí)候技術(shù)才發(fā)現(xiàn)臥槽這里有個(gè)邏輯沒想通啊。然后喊產(chǎn)品來一起討論的時(shí)候，大家發(fā)現(xiàn)需要加一些功能才能完善邏輯。最后結(jié)果就是周六加了個(gè)班，大家很不開心。
這種事情也不好追責(zé)，畢竟參與者很多，流程拖得很長(zhǎng)。硬要說是負(fù)責(zé)需求的產(chǎn)品經(jīng)理有問題倒也可以，但總是片面的：他也不一定知道技術(shù)上開發(fā)才發(fā)現(xiàn)的邏輯。
后來我們反思，各個(gè)流程中的環(huán)節(jié)都要做一些調(diào)整，才能確保最終產(chǎn)品方案的完整：
分析需求時(shí)，先梳理邏輯再出方案。能畫流程圖的畫流程圖，能畫邏輯圖的畫邏輯圖，能畫腦圖的畫腦圖，窮舉整體的邏輯。
討論方案時(shí)，所有產(chǎn)品經(jīng)理參與小組討論，一起提出疑惑，發(fā)現(xiàn)問題。
可行性評(píng)審時(shí)，技術(shù)從邏輯角度提出質(zhì)疑，發(fā)現(xiàn)問題。
之后再出問題，會(huì)回溯原因。如果是前兩個(gè)環(huán)節(jié)出的問題，那就是產(chǎn)品經(jīng)理的責(zé)任；如果是產(chǎn)品經(jīng)理未知的邏輯，那就是可行性評(píng)審中，技術(shù)的同事的責(zé)任。
2）需求方的主觀改動(dòng)
這種情況基本都是需求方或者產(chǎn)品經(jīng)理的問題：他們?cè)谔峤环桨盖皼]有完全想清楚。
有時(shí)候都開始開發(fā)了，業(yè)務(wù)部門來人說，哎我們發(fā)現(xiàn)這個(gè)問題好像不存在了，大家不要做了。他們覺得無所謂，還減輕了開發(fā)負(fù)擔(dān)。但對(duì)技術(shù)部門的同事來說，就好像在說「你被耍了，哈哈哈」。造成的影響是惡劣的。
產(chǎn)品經(jīng)理在對(duì)接他們的需求時(shí)要做判斷，他們是不是完全想清楚了，是靈機(jī)一動(dòng)的小點(diǎn)子，還是不得不解決的問題。
另外，還有一種情況，是需求方跟產(chǎn)品經(jīng)理對(duì)接時(shí)出了問題。表述有誤，并且方案沒有跟他們核對(duì)清楚，結(jié)果產(chǎn)品功能上線，才發(fā)現(xiàn)并沒有解決問題。
我們的做法剛才多少提到了一些：要在任何需求的屬性（內(nèi)容、時(shí)間點(diǎn)）發(fā)生變化時(shí)，跟需求方同步。讓他們知道我們的情況，也獲取他們的意見和建議。
比如這是我們的需求同步流程：
3）無法預(yù)測(cè)的客觀原因
這種是唯一一種能夠接受的原因，不需要有誰(shuí)承擔(dān)責(zé)任。
比如，本來要做一個(gè)功能狙擊對(duì)手，結(jié)果做了一半，競(jìng)爭(zhēng)對(duì)手倒閉了，那這個(gè)功能就沒有意義了，確實(shí)要廢除。
還有一些業(yè)務(wù)上的確無法預(yù)測(cè)的各種原因，導(dǎo)致原本存在的問題不存在了，也無可厚非。
這種情況下，產(chǎn)品經(jīng)理最重要的是安撫技術(shù)的同事，尤其是跟他們解釋清楚背景和詳細(xì)的原因，不要讓他們誤以為是剛才提到的前兩種理由。
需求從獲取到上線，走完生命周期之后，還要有一個(gè)很重要的復(fù)盤階段，尤其是在需求管理出過故障和問題的時(shí)候。
略靠譜的團(tuán)隊(duì)，都會(huì)有復(fù)盤的機(jī)制，主要是防止問題再次發(fā)生。解決問題很簡(jiǎn)單，如何盡量規(guī)避下次再出問題很復(fù)雜。
大致就是，要搞清楚之前出現(xiàn)問題的所有邏輯和流程，再去看在哪些環(huán)節(jié)可以做點(diǎn)什么，去防止再次出現(xiàn)。這塊的內(nèi)容說得多了又得寫一篇文，就不多講了。
以上就是我的經(jīng)驗(yàn)，僅供參考。沒有什么流程和機(jī)制是完美的，關(guān)鍵在于怎么去解決自己的問題。如果哪些思路給你了啟發(fā)，那就夠了。
【作者介紹】劉飛，原嘟嘟美甲聯(lián)合創(chuàng)始人，錘子科技產(chǎn)品經(jīng)理，除了是雷鋒網(wǎng)的專欄特約作者，也是產(chǎn)品經(jīng)理干貨集裝箱的人人都是產(chǎn)品經(jīng)理的專欄作家，豆瓣《最好的時(shí)代：可能是最真誠(chéng)的創(chuàng)業(yè)日記》作者。文能提筆抒騷情，武能切圖畫交互。微信公號(hào)：劉言飛語(yǔ)（ID：liufeinotes）
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
