產品經理們在處理來自不同地方的需求時，有著不同的工作方式和方法：分類管理、定期維護等不一而足。那麼，對於需求的整個生命週期來說，我們究竟應該怎麼做呢？
下面是我的經驗。
1、獲取階段
需求的來源有很多。業務越複雜，需求就越雜。一個淘寶，產品需求就可以拆分成分類、檢索、排序、商品展示、行銷活動、支付、配送、售後等等。
你的職級越高，也代表著身邊人提需求的可能性越大。初入行的產品專員或助理，主要是得到被安排的任務；初級產品經理，需求來源主要是用戶和上級；產品負責人，需求來源就要增加老闆和其他相關部門；
而作為老闆，誰都可能跟他提產品需求。
所以在獲取到需求這一時刻，就必須做一個判斷，並且記錄。如果不做判斷堆在那裡，等做的時候根本沒辦法梳理出頭緒，可能大部分時間都在疲於折騰需求清單。記錄當然是為了方便回溯。獲取到的再小的需求也記下來，不要指望你隨時能想起來每天聽過的每個需求。
做判斷的內容具體是什麼呢？
·
判斷需求本身的重要性
同樣是頁面寫錯了一個字，把「登錄」寫成「登陸」，和把「獎勵 15 元」寫成「獎勵 50 元」，重要性不言而喻吧。有個大致的預估。
·
考慮需求來源
需求來源會表明一些事情，要慎重思考。比如老闆提到的，未必是目前你能理解的，但他認為特別重要，就暫且把這個當成特別重要的，這是政治任務。再比如是用戶提到的，但細想他並不是目標使用者，他的需求就不必太關注。
·
簡要得到需求背景
我自己工作中有三類需求絕對不記：
沒說清楚原因的，不記（你做個 XX 出來，別管那麼多）；
不說清邏輯的，不記（啊，這裡我也沒搞懂，你先看看）；
不是實際遇到的，不記（哎，我覺得可能有人會這樣用）。
需求背景沒搞清楚，完全是浪費時間。有一句話的記錄，但不說背景，也是浪費時間。記的時候，我會確保格式是問題 + 方案，「XXX 在用我們的 XX 功能時，感覺
XXX，我們可以嘗試 XXX 這樣的方案」。
最後，依據這三個因素，判斷屬於大致哪個類別的。一般的需求管理都會分 P0-P3 或者 P1-P4，總之先打個標籤。這裡的技巧是儘量標記為比估計的更重要一層的需求，就是你感覺是 P2 的，暫且先標為 P1。
這樣以防錯漏，低優先順序的標成高的沒關係，但高優先順序的標低了會出現麻煩。這時候的預估往往不準確，但沒關係，等後面第二步再說。
比如這樣：
2、討論 / 設計階段
1）需求的優先順序
2）方案的方向
有時會有大概的方向，再去跟相關部門和需求相關的同事確認。這不在本文討論範圍內，暫且不提。
3）指定負責人
前一種的好處在，模塊清晰，負責人可以對自己負責的部分足夠熟悉，但缺點是，工作量很可能不平衡，有的同事一直在忙，有的可能就比較閒，因為需求不是平均按模塊分佈的。
在我們需求分配時，大致還是按照模塊分配，但在出現工作量不平衡的情況時，會酌情調整一下，讓活少的同事予以配合。
不管怎麼樣，一定一定要指定負責人，他需要對需求負責，一直到產品上線後，出了的問題他也要承擔責任。要保證運營良好的工作責任制。
4）劃定時間節點
時間節點至少也要包括方案完成的時間。就是這個需求，能夠完好提交給開發的時間。如果沒有這個時間，對需求的管理就沒有一點意義了。
另外，如果是要跟相關部門再確認、或者要跟用戶調研、或者要統計各種數據再作判斷的需求，那還要有調研 / 討論完成的時間。
這個時間節點的劃定，主要是按照方案的複雜程度，用經驗做個簡單判斷。最長的時間週期也不能超過一周，保證需求的推動進度，因為很難有複雜程度超過一周的產品需求。對於有嚴格上線時間的需求（經常會出現，比如很苛刻的老闆需求、投資人需求、政府需求等），要倒推出最合理又富有餘地的時間節點。
討論完剛剛入池的一批需求，我們會再整理和討論其它狀態（有方案或者調研結論）的需求。這樣會議結束，每條需求都會得到更新。
我們在這個時刻，一般會讓負責的產品經理，及時更新需求狀態給需求來源方。當然，來源方 95% 的情況下會對進度不滿意，這很正常，但除非來源方有確鑿的理由，我們不會輕易調整優先級和時間節點。
3、待開發階段
可行性評審上，完成的是對需求的大致評估，要做的有這麼幾件事：
1）方案本身的可行性
2）有沒有更好的方案？
3）涉及的產品和技術環節有哪些？
4）方案的成本如何？
我在 創業公司產品經理怎麼做？ 提到過具體的方法，這裡不再贅述。大概是用這樣的表格：
提交開發之後，相當於關閉需求。原則上，本次迭代不再加入新的需求。
當然啦，如果什麼事情都是原則上那樣... 就不會出現這麼多扯皮的情況了。
在開發中，扯皮的問題歸納起來就是三種：需求太多，沒按時做完；需求有改動，導致了額外工作量以及開發的不滿；有新的緊急需求，導致發佈延期。
這三種問題，再抽象一下，導致的原因很多，大概有幾類，分別是：
1）產品方案不完整
方案不完整往往是沒有考慮全面。這個跟需求管理本身沒關係，就是在出方案的途中，看能不能把事情想全。
之前我們經常出現，做的時候技術才發現臥槽這裡有個邏輯沒想通啊。然後喊產品來一起討論的時候，大家發現需要加一些功能才能完善邏輯。最後結果就是週六加了個班，大家很不開心。
這種事情也不好追責，畢竟參與者很多，流程拖得很長。硬要說是負責需求的產品經理有問題倒也可以，但總是片面的：他也不一定知道技術上開發才發現的邏輯。
後來我們反思，各個流程中的環節都要做一些調整，才能確保最終產品方案的完整：
分析需求時，先梳理邏輯再出方案。能畫流程圖的畫流程圖，能畫邏輯圖的畫邏輯圖，能畫腦圖的畫腦圖，窮舉整體的邏輯。
討論方案時，所有產品經理參與小組討論，一起提出疑惑，發現問題。
可行性評審時，技術從邏輯角度提出質疑，發現問題。
之後再出問題，會回溯原因。如果是前兩個環節出的問題，那就是產品經理的責任；如果是產品經理未知的邏輯，那就是可行性評審中，技術的同事的責任。
2）需求方的主觀改動
這種情況基本都是需求方或者產品經理的問題：他們在提交方案前沒有完全想清楚。
有時候都開始開發了，業務部門來人說，哎我們發現這個問題好像不存在了，大家不要做了。他們覺得無所謂，還減輕了開發負擔。但對技術部門的同事來說，就好像在說「你被耍了，哈哈哈」。造成的影響是惡劣的。
產品經理在對接他們的需求時要做判斷，他們是不是完全想清楚了，是靈機一動的小點子，還是不得不解決的問題。
另外，還有一種情況，是需求方跟產品經理對接時出了問題。表述有誤，並且方案沒有跟他們核對清楚，結果產品功能上線，才發現並沒有解決問題。
我們的做法剛才多少提到了一些：要在任何需求的屬性（內容、時間點）發生變化時，跟需求方同步。讓他們知道我們的情況，也獲取他們的意見和建議。
比如這是我們的需求同步流程：
3）無法預測的客觀原因
這種是唯一一種能夠接受的原因，不需要有誰承擔責任。
比如，本來要做一個功能狙擊對手，結果做了一半，競爭對手倒閉了，那這個功能就沒有意義了，確實要廢除。
還有一些業務上的確無法預測的各種原因，導致原本存在的問題不存在了，也無可厚非。
這種情況下，產品經理最重要的是安撫技術的同事，尤其是跟他們解釋清楚背景和詳細的原因，不要讓他們誤以為是剛才提到的前兩種理由。
5 、復盤階段
需求從獲取到上線，走完生命週期之後，還要有一個很重要的復盤階段，尤其是在需求管理出過故障和問題的時候。
略靠譜的團隊，都會有復盤的機制，主要是防止問題再次發生。解決問題很簡單，如何盡量規避下次再出問題很複雜。
大致就是，要搞清楚之前出現問題的所有邏輯和流程，再去看在哪些環節可以做點什麼，去防止再次出現。這塊的內容說得多了又得寫一篇文，就不多講了。
以上就是我的經驗，僅供參考。沒有什麼流程和機制是完美的，關鍵在於怎麼去解決自己的問題。如果哪些思路給你了啓發，那就夠了。
0 comments:
張貼留言