今天討論一個話題：如何拆解需求？

相信每一位產(chǎn)品同學都會遇到這樣的場景，接收到一個需求，而需求本身是一個結(jié)論或者一個方案，對于這個“正確”的結(jié)論或者方案，產(chǎn)品經(jīng)理處于極度被動而且信息失衡的狀態(tài)。

舉一個我經(jīng)歷過的真實案例，既當做是總結(jié)復盤，也同時給大家分享一下由此延伸出來的本篇主題：如何拆解需求？

OK，我們先看案例。具體業(yè)務和項目背景我就不做介紹了，大概描述一下需求框架。

我接收到的需求是這樣的：“在xxx業(yè)務里，我要做一個xxx的微信小程序”。到此，需求描述就結(jié)束了。

對于這個“需求”，產(chǎn)品經(jīng)理得到的有效信息會非常的貧乏。為什么我要對這個需求打引號呢，因為這稱不上是一個有效需求，而是一個結(jié)論性方案。

當然，從句式表達上來看，這確實是一個訴求，“我要…”這種句式表達的就是一種訴求。

但本著為用戶負責以及優(yōu)化資源配置的角度來看，這個結(jié)論性的方案真的能解決它背后的問題嗎？

那什么是結(jié)論性方案背后的問題呢？其實就是這個需求對應的場景，一個方案一定是為了解決某一個問題而存在。如果我們進一步把“場景”這個詞細化，能從如下三個角度去拆解一個需求。

1. 需求受益人；
2. 問題觸發(fā)節(jié)點；
3. 迫切程度。

從以上三個角度，我們分別定義了需求受益人、問題觸發(fā)節(jié)點、需求迫切程度，這三個角度分別對應了人、問題、優(yōu)先級。幾乎所有的需求都可以從以上三個角度來拆解，接下來分別做進一步研習。

1. 需求受益人

前文有提到，每一個需求都有其對應的場景，提到場景，人是第一要素。如果需求是為了解決一個問題，那首要回答的是，我們解決的是誰的問題。也就是說，如果需求轉(zhuǎn)化成產(chǎn)品方案，經(jīng)過研發(fā)上線變成產(chǎn)品功能，這個功能的受益人是誰？

很多時候，我們看似做了很多正確的需求，上線了很多產(chǎn)品功能，結(jié)果發(fā)現(xiàn)最后壓根沒人用。其核心原因就是需求受益人不清晰。

需求受益人不清晰的原因要么是主觀設(shè)想，要么是為了方案而方案。前者簡單說就是YY，通俗說就是“有一種冷叫你媽覺得你冷”。后者簡單說就是做設(shè)計做功能，通俗說就是“沉迷在完成任務后的成就感里”。

找到需求受益人，去感受他們的問題。

需求受益人有可能在內(nèi)部，例如一個批量操作的功能可能會讓運營人員的效率直線提升。需求受益人也有可能在外部，例如一個“隨機播放音樂”的功能能解放那些選擇困難或者沒有選擇的人。

拆解需求第一步，找到需求受益人。這些人在哪？是否真實存在？如果存在，需求對應的方案是否能讓他們產(chǎn)生感知并且能給他們帶去價值？

找到產(chǎn)品的真實用戶，加幾個用戶的微信，當你需要判斷一些需求時，或者需要做一些產(chǎn)品決策時，帶上問題和他們聊聊。另外，把自己變成產(chǎn)品用戶，場景化的感受一下用戶所需。

我現(xiàn)在做的一個toB的項目，加了一個重度核心用戶，當面對需求方的一些新想法時，我都會和這個核心用戶聊一聊，確認他是不是這個需求受益人。過程中，會得到很多的有價值信息輸入。

如果一個需求討論開始，我們都無法定義出需求受益人是誰，那很大程度上就是一個看似正確的偽需求。

2. 問題觸發(fā)節(jié)點

對于產(chǎn)品經(jīng)理而言，要用“問題眼光”來看待需求，而不要用“結(jié)論眼光”，這兩種視角會有非常大的區(qū)別。

先說“結(jié)論眼光”，很多時候，我們的需求方或者用戶提過來的大部分都是一些結(jié)論性方案。例如要開發(fā)一個什么功能，或者要修改現(xiàn)有的邏輯。

此時，如果產(chǎn)品經(jīng)理不加拆解判斷就接受的話，很有可能做了一個正確但無用方案。

而這種損害就是一個連鎖效應，接收結(jié)論、制定方案、產(chǎn)品設(shè)計、技術(shù)研發(fā)、產(chǎn)品上線，牽動的都是一系列資源的投入。

好不容易上線了，發(fā)現(xiàn)現(xiàn)實情況和當初的設(shè)想差距過大，然后再經(jīng)過方案調(diào)整、產(chǎn)品設(shè)計、技術(shù)研發(fā)、產(chǎn)品上線。

這么來看，產(chǎn)品經(jīng)理如果不扮演好守門員的角色，對公司資源的消耗就會非常嚴重，最終，也無法帶來用戶價值。

接下來，我們再說“問題眼光”，產(chǎn)品經(jīng)理以探究問題的角度去拆解需求，也就是說，對應需求所解決的問題是在哪個環(huán)節(jié)節(jié)點？我們制定的產(chǎn)品方案是在什么節(jié)點對之前有了提升性的補充？

這時候，需求會轉(zhuǎn)變成問題。面對需求方，不要跟我說你想做什么，而是告訴我你遇到了什么問題，而且是在什么時候在完成什么動作時遇到了這個問題。這就是問題出發(fā)節(jié)點，也是需求的原始起點。

找到這個點，才是真正解決問題的開始。很多時候，需求方自己是明白有問題的，基于自己的理解加工后，都會習慣性的得出結(jié)論性方案，然后把方案本身當成了需求。

找到問題觸發(fā)節(jié)點，探究原始問題，才能get到真正要解決的問題是什么。以免陷入爭論和解決一個看似正確的錯誤問題。

3. 迫切程度

迫切程度對應了需求的優(yōu)先級，優(yōu)先級不是單一維度的考量，而是綜合多方因素整體衡量?？梢酝ㄟ^重要緊急四象限去劃分優(yōu)先級。

涉及到需求迫切程度，直接決定的是資源的分配，包括設(shè)計資源、研發(fā)資源、運營資源。在明確需求受益人和問題觸發(fā)節(jié)點之后，迫切程度的判斷就是需求拆解的最后一個環(huán)節(jié)。

提供幾個判斷需求迫切程度的考慮點，首先是對應需求是否處于關(guān)鍵業(yè)務路徑上。

例如電商業(yè)務中，從商品瀏覽到下單支付的核心路徑上，期間的每個節(jié)點都是關(guān)鍵節(jié)點。如果對應需求是落在這些節(jié)點上，都是可以優(yōu)先考慮解決的，也就是可以提上相對靠前優(yōu)先級的。

另外，對于一些關(guān)鍵性的Bug，例如阻礙用戶完成關(guān)鍵業(yè)務路徑的一些問題，是需要立刻馬上解決的。除此之外，對于新特性、優(yōu)化項或者補充性功能，都可以作為次要優(yōu)先級在后期迭代。

最后

上述提供了如何拆解一個需求的三個角度，面對一個需求，分別從需求受益人、問題觸發(fā)節(jié)點、迫切程度來進行分析。可能認知有限而略顯片面，從我自己的認知里，這三個考量點基本能覆蓋我經(jīng)歷過的一些需求。希望對你有用，也歡迎你留言來說一說，你是如何拆解一個需求的。

#專欄作家#

唐韌（Ryan），《產(chǎn)品經(jīng)理必懂的技術(shù)那點事兒》作者，人人都是產(chǎn)品經(jīng)理專欄作家，微信公眾號：唐韌，國內(nèi)早期移動開發(fā)者，轉(zhuǎn)型產(chǎn)品經(jīng)理，目前在創(chuàng)業(yè)公司負責產(chǎn)品工作。

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

題圖來自 Pexels，基于 CC0 協(xié)議