產(chǎn)品經(jīng)理們在處理來自不同地方的需求時，有著不同的工作方式和方法：分類管理、定期維護等不一而足。那么，對于需求的整個生命周期來說，我們究竟應(yīng)該怎么做呢？

下面是我的經(jīng)驗。

一.?獲取階段

需求的來源有很多。業(yè)務(wù)越復(fù)雜，需求就越雜。一個淘寶，產(chǎn)品需求就可以拆分成分類、檢索、排序、商品展示、營銷活動、支付、配送、售后等等。

你的職級越高，也代表著身邊人提需求的可能性越大。初入行的產(chǎn)品專員或助理，主要是得到被安排的任務(wù)；初級產(chǎn)品經(jīng)理，需求來源主要是用戶和上級；產(chǎn)品負責(zé)人，需求來源就要增加老板和其他相關(guān)部門； 而作為老板，誰都可能跟他提產(chǎn)品需求。

所以在獲取到需求這一時刻，就必須做一個判斷，并且記錄。如果不做判斷堆在那里，等做的時候根本沒辦法梳理出頭緒，可能大部分時間都在疲于折騰需求清單。記錄當(dāng)然是為了方便回溯。獲取到的再小的需求也記下來，不要指望你隨時能想起來每天聽過的每個需求。

做判斷的內(nèi)容具體是什么呢？

第一，判斷需求本身的重要性

同樣是頁面寫錯了一個字，把「登錄」寫成「登陸」，和把「獎勵 15 元」寫成「獎勵 50 元」，重要性不言而喻吧。有個大致的預(yù)估。

第二，考慮需求來源

需求來源會表明一些事情，要慎重思考。比如老板提到的，未必是目前你能理解的，但他認為特別重要，就暫且把這個當(dāng)成特別重要的，這是政治任務(wù)。再比如是用戶提到的，但細想他并不是目標(biāo)用戶，他的需求就不必太關(guān)注。

第三，簡要得到需求背景

我自己工作中有三類需求絕對不記：沒說清楚原因的，不記（你做個 XX 出來，別管那么多）；不說清邏輯的，不記（啊，這里我也沒搞懂，你先看看）；不是實際遇到的，不記（哎，我覺得可能有人會這樣用）。

需求背景沒搞清楚，完全是浪費時間。有一句話的記錄，但不說背景，也是浪費時間。記的時候，我會確保格式是問題 + 方案，「XXX 在用我們的 XX 功能時，感覺 XXX，我們可以嘗試 XXX 這樣的方案」。

最后，依據(jù)這三個因素，判斷屬于大致哪個類別的。一般的需求管理都會分 P0-P3 或者 P1-P4，總之先打個標(biāo)簽。這里的技巧是盡量標(biāo)記為比估計的更重要一層的需求，就是你感覺是 P2 的，暫且先標(biāo)為 P1。這樣以防錯漏，低優(yōu)先級的標(biāo)成高的沒關(guān)系，但高優(yōu)先級的標(biāo)低了會出現(xiàn)麻煩。這時候的預(yù)估往往不準(zhǔn)確，但沒關(guān)系，等后面第二步再說。

比如這樣：

二. 討論 / 設(shè)計階段

隔一段時間，我們會開需求討論會，整理需求池，也就是記錄所有獲取到需求的表單。

我們會詳細討論每個需求的情況，確認幾個事項：

1.?需求的優(yōu)先級

之前的判斷是粗估，這里的判斷就要精細了。一般需求的重要程度很難量化，尤其來源復(fù)雜的情況下。營銷部門著急要我們配合做活動，不做就少賺好多錢，業(yè)務(wù)部門著急要我們配合做一套自動化結(jié)賬工具，做了能節(jié)省很多成本… 有時抉擇很痛苦。

這里還是用最常用的判斷方法，緊急重要四象限法則（請自行百度「四象限法則」）。重要程度大致按這種排序：

• 不做會造成嚴重的問題和惡劣的影響的
• 做了會產(chǎn)生巨大好處和極佳效果的
• 跟重要合作對象或投資人有關(guān)的
• 跟核心用戶利益有關(guān)的
• 跟大部分用戶權(quán)益有關(guān)的
• 跟效率或成本有關(guān)的
• 跟用戶體驗有關(guān)的

緊急程度按這個排序：

• 不做錯誤會持續(xù)發(fā)生，造成嚴重影響
• 在一定時間內(nèi)可控，但長期會有糟糕的影響
• 做了立刻能解決很多問題、產(chǎn)生正面的影響
• 做了在一段時間后可以有良好的效果

大家把能考慮到的因素想全，會標(biāo)上 P1 – P4 的優(yōu)先級。

2.?方案的方向

需求有不同的解決辦法，我們會討論清楚到底用哪種解決。比如我們發(fā)現(xiàn)有刷單現(xiàn)象，可以事前提醒，告知用戶目前地理位置或訂單信息有嫌疑；可以事中限制，必須到達指定地點、拍攝當(dāng)?shù)卣掌鹊炔僮鱽硐拗朴脩?；可以事后懲戒，提供給客服或者業(yè)務(wù)部門疑似刷單的名單和證據(jù)，罰款或者封號。這幾項到底做哪個？還是做其中哪幾個？優(yōu)劣在哪？需要好好討論。

有時會有大概的方向，再去跟相關(guān)部門和需求相關(guān)的同事確認。這不在本文討論范圍內(nèi)，暫且不提。

3.?指定負責(zé)人

我之前經(jīng)歷過兩種需求分配制度。一種是每個人負責(zé)的需求范圍有清晰的邊界，那需求對應(yīng)哪個模塊，就直接分配即可；另一種是團隊作戰(zhàn)，每次指定或者認領(lǐng)，誰都有可能接手任意需求。

前一種的好處在，模塊清晰，負責(zé)人可以對自己負責(zé)的部分足夠熟悉，但缺點是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閑，因為需求不是平均按模塊分布的。

在我們需求分配時，大致還是按照模塊分配，但在出現(xiàn)工作量不平衡的情況時，會酌情調(diào)整一下，讓活少的同事予以配合。

不管怎么樣，一定一定要指定負責(zé)人，他需要對需求負責(zé)，一直到產(chǎn)品上線后，出了的問題他也要承擔(dān)責(zé)任。要保證運營良好的工作責(zé)任制。

4.?劃定時間節(jié)點

許多產(chǎn)品經(jīng)理會疏漏這點，只是覺得盡快去做，但總是做不完。

時間節(jié)點至少也要包括方案完成的時間。就是這個需求，能夠完好提交給開發(fā)的時間。如果沒有這個時間，對需求的管理就沒有一點意義了。

另外，如果是要跟相關(guān)部門再確認、或者要跟用戶調(diào)研、或者要統(tǒng)計各種數(shù)據(jù)再作判斷的需求，那還要有調(diào)研 / 討論完成的時間。

這個時間節(jié)點的劃定，主要是按照方案的復(fù)雜程度，用經(jīng)驗做個簡單判斷。最長的時間周期也不能超過一周，保證需求的推動進度，因為很難有復(fù)雜程度超過一周的產(chǎn)品需求。對于有嚴格上線時間的需求（經(jīng)常會出現(xiàn)，比如很苛刻的老板需求、投資人需求、政府需求等），要倒推出最合理又富有余地的時間節(jié)點。

討論完剛剛?cè)氤氐囊慌枨螅覀儠僬砗陀懻撈渌鼱顟B(tài)（有方案或者調(diào)研結(jié)論）的需求。這樣會議結(jié)束，每條需求都會得到更新。

我們在這個時刻，一般會讓負責(zé)的產(chǎn)品經(jīng)理，及時更新需求狀態(tài)給需求來源方。當(dāng)然，來源方 95% 的情況下會對進度不滿意，這很正常，但除非來源方有確鑿的理由，我們不會輕易調(diào)整優(yōu)先級和時間節(jié)點。

三. 待開發(fā)階段

有了確切方案，我們會盡快跟研發(fā)的同事做可行性評審。這一步必不可少。我感覺題主出現(xiàn)的「落不了地」和「頻繁更改」的問題，要著重在這個步驟里解決。

可行性評審上，完成的是對需求的大致評估，要做的有這么幾件事：

1.?方案本身的可行性

在技術(shù)方案上，是不是能夠完成？就是讓技術(shù)部門評估這個問題。

2.?有沒有更好的方案？

一定要跟技術(shù)部門灌輸清晰的需求背景，讓他們也想一些可行的方案。方案未必是完整、準(zhǔn)確的，但他們提供的思路，一般是可行性較高的。

3.?涉及的產(chǎn)品和技術(shù)環(huán)節(jié)有哪些？

這個需要相關(guān)的同事仔細討論。尤其是很多公司產(chǎn)品線比較多，有可能存在牽一發(fā)動全身的情況，如果相關(guān)的產(chǎn)品同事和技術(shù)同事不知情，必然會延期，必然會扯皮，必然會造成麻煩，必然會有各種改動。即便是再小的產(chǎn)品，也要分前后端，讓技術(shù)的同事來判斷有哪些人需要知情和參與評估。

4.?方案的成本如何？

看方案需要多少人、多少資源、多少時間來完成，也要看方案在技術(shù)層面耗費的不太明顯的成本，比如服務(wù)器成本、帶寬成本，給用戶造成的流量成本等。

有了這樣的討論，會議輸出的，就是比較嚴謹?shù)目蓤?zhí)行方案（或草稿）了。

如果會上遇到各種問題，要確認解決問題的時間節(jié)點。

四. 開發(fā)階段

開發(fā)需求的次序，我們不是完全按照需求池里的需求優(yōu)先級來的。剛才說到，在可行性評估會上，我們會核算大致的需求成本，那成本結(jié)合需求的優(yōu)先級，就可以得出需求的性價比了。

我在 創(chuàng)業(yè)公司產(chǎn)品經(jīng)理怎么做？?提到過具體的方法，這里不再贅述。大概是用這樣的表格：

提交開發(fā)之后，相當(dāng)于關(guān)閉需求。原則上，本次迭代不再加入新的需求。

當(dāng)然啦，如果什么事情都是原則上那樣… 就不會出現(xiàn)這么多扯皮的情況了。

在開發(fā)中，扯皮的問題歸納起來就是三種：需求太多，沒按時做完；需求有改動，導(dǎo)致了額外工作量以及開發(fā)的不滿；有新的緊急需求，導(dǎo)致發(fā)布延期。

這三種問題，再抽象一下，導(dǎo)致的原因很多，大概有幾類，分別是：

1.?產(chǎn)品方案不完整

方案不完整往往是沒有考慮全面。這個跟需求管理本身沒關(guān)系，就是在出方案的途中，看能不能把事情想全。

之前我們經(jīng)常出現(xiàn)，做的時候技術(shù)才發(fā)現(xiàn)臥槽這里有個邏輯沒想通啊。然后喊產(chǎn)品來一起討論的時候，大家發(fā)現(xiàn)需要加一些功能才能完善邏輯。最后結(jié)果就是周六加了個班，大家很不開心。

這種事情也不好追責(zé)，畢竟參與者很多，流程拖得很長。硬要說是負責(zé)需求的產(chǎn)品經(jīng)理有問題倒也可以，但總是片面的：他也不一定知道技術(shù)上開發(fā)才發(fā)現(xiàn)的邏輯。

后來我們反思，各個流程中的環(huán)節(jié)都要做一些調(diào)整，才能確保最終產(chǎn)品方案的完整：

• 分析需求時，先梳理邏輯再出方案。能畫流程圖的畫流程圖，能畫邏輯圖的畫邏輯圖，能畫腦圖的畫腦圖，窮舉整體的邏輯。
• 討論方案時，所有產(chǎn)品經(jīng)理參與小組討論，一起提出疑惑，發(fā)現(xiàn)問題。
• 可行性評審時，技術(shù)從邏輯角度提出質(zhì)疑，發(fā)現(xiàn)問題。

之后再出問題，會回溯原因。如果是前兩個環(huán)節(jié)出的問題，那就是產(chǎn)品經(jīng)理的責(zé)任；如果是產(chǎn)品經(jīng)理未知的邏輯，那就是可行性評審中，技術(shù)的同事的責(zé)任。

2.?需求方的主觀改動

這種情況基本都是需求方或者產(chǎn)品經(jīng)理的問題：他們在提交方案前沒有完全想清楚。

有時候都開始開發(fā)了，業(yè)務(wù)部門來人說，哎我們發(fā)現(xiàn)這個問題好像不存在了，大家不要做了。他們覺得無所謂，還減輕了開發(fā)負擔(dān)。但對技術(shù)部門的同事來說，就好像在說「你被耍了，哈哈哈」。造成的影響是惡劣的。

產(chǎn)品經(jīng)理在對接他們的需求時要做判斷，他們是不是完全想清楚了，是靈機一動的小點子，還是不得不解決的問題。

另外，還有一種情況，是需求方跟產(chǎn)品經(jīng)理對接時出了問題。表述有誤，并且方案沒有跟他們核對清楚，結(jié)果產(chǎn)品功能上線，才發(fā)現(xiàn)并沒有解決問題。

我們的做法剛才多少提到了一些：要在任何需求的屬性（內(nèi)容、時間點）發(fā)生變化時，跟需求方同步。讓他們知道我們的情況，也獲取他們的意見和建議。

比如這是我們的需求同步流程：

3.?無法預(yù)測的客觀原因

這種是唯一一種能夠接受的原因，不需要有誰承擔(dān)責(zé)任。

比如，本來要做一個功能狙擊對手，結(jié)果做了一半，競爭對手倒閉了，那這個功能就沒有意義了，確實要廢除。

還有一些業(yè)務(wù)上的確無法預(yù)測的各種原因，導(dǎo)致原本存在的問題不存在了，也無可厚非。

這種情況下，產(chǎn)品經(jīng)理最重要的是安撫技術(shù)的同事，尤其是跟他們解釋清楚背景和詳細的原因，不要讓他們誤以為是剛才提到的前兩種理由。

五. 復(fù)盤階段

需求從獲取到上線，走完生命周期之后，還要有一個很重要的復(fù)盤階段，尤其是在需求管理出過故障和問題的時候。

略靠譜的團隊，都會有復(fù)盤的機制，主要是防止問題再次發(fā)生。解決問題很簡單，如何盡量規(guī)避下次再出問題很復(fù)雜。

大致就是，要搞清楚之前出現(xiàn)問題的所有邏輯和流程，再去看在哪些環(huán)節(jié)可以做點什么，去防止再次出現(xiàn)。這塊的內(nèi)容說得多了又得寫一篇文，就不多講了。

以上就是我的經(jīng)驗，僅供參考。沒有什么流程和機制是完美的，關(guān)鍵在于怎么去解決自己的問題。如果哪些思路給你了啟發(fā)，那就夠了。

#專欄作家#

劉飛，原嘟嘟美甲聯(lián)合創(chuàng)始人，錘子科技產(chǎn)品經(jīng)理，人人都是產(chǎn)品經(jīng)理專欄作家，豆瓣《最好的時代：可能是最真誠的創(chuàng)業(yè)日記》作者。文能提筆抒情，武能切圖畫交互。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，不得轉(zhuǎn)載。