產(chǎn)品經(jīng)理是產(chǎn)出解決方案的崗位，但不同的人對需求、解決方案有不同的理解。這篇文章，我們看看作者對于需求分析的認識和自己的經(jīng)驗，是否有可參考的地方。

一、需求分析高效之道

需求分析思維模型（底層邏輯）

觀點：基于問題相關的人和事情、市面上的產(chǎn)品調(diào)研以及實踐經(jīng)驗總結(jié)去分析需求比較完善，而想要需求分析高效需要大量的刻意練習。

在接觸到比較多產(chǎn)品經(jīng)理之后，我發(fā)現(xiàn)產(chǎn)品經(jīng)理的思維模型有比較大的區(qū)別，有的人是僅基于問題相關的人和事情去分析需求；有的人會基于問題相關的人和事情以及市面上的產(chǎn)品調(diào)研去分析需求；還有的人會基于問題相關的人和事情、市面上的產(chǎn)品調(diào)研以及實踐經(jīng)驗總結(jié)去分析需求。最后一種方法是我最認同的，也是我認為的高效的需求分析的思維模型。

僅基于人和事情去分析需求，這個是比較入門的產(chǎn)品經(jīng)理會這樣去做，這個方法要求這個產(chǎn)品經(jīng)理有正常人的邏輯思維能力即可。這樣去做，你的系統(tǒng)沒有什么架構(gòu)可言，大多東西可能都是固定的，例如：公司說我要一個用戶畫像的功能，結(jié)果可能是用戶標簽都是固定的，某個業(yè)務線需要新增一個標簽那么我就再新增一個。這樣的產(chǎn)品方案是很初級的。

基于問題相關的人和事情以及市面上的產(chǎn)品調(diào)研去分析需求，這樣做的好處是了解市面上的產(chǎn)品是怎么做的，站在巨人的肩膀上找解決方案，一個產(chǎn)品經(jīng)理如果這個點都做不到，很可能會浪費開發(fā)資源，走很多的彎路，例如：很多書籍或者文章都有分享AI建設道路，但是還是有公司會花2~3年的時間去走完這篇文章里提到的彎路，如果產(chǎn)品經(jīng)理在初期做了充足的調(diào)研就會知道很多彎路是可以避免的，可以減少非常多開發(fā)資源的浪費。

基于問題相關的人和事情、市面上的產(chǎn)品調(diào)研以及實踐經(jīng)驗總結(jié)去分析需求，這樣的思維模型是比較完善的，能夠做出比較成熟的產(chǎn)品方案，使得業(yè)務流程跑順，也節(jié)省了開發(fā)資源。

一個比較成熟的底層思維模型并不是需求分析高效的原因所在，可能它需要花費同樣多的時間去做需求分析。做什么都最好有個前提，大多數(shù)觀點并不是完全通用的，除了一些數(shù)學或者物理里面的定律等。

打個比方，假設你是一臺電腦，雖然有了一個成熟的模型——這個是一個程序，想要高效，你應該是不斷地提升運行這個模型的效率，當你給這個模型喂了足夠多的樣本（實踐），你就會非?？斓刈R別出這個需求的本質(zhì)是什么。也就是說你做了足夠多的需求、調(diào)研了足夠的的產(chǎn)品、做了足夠多的總結(jié)，你的需求洞察力會有很好的增強，可以讓你高效地進行需求分析。

需求分析方法（表層邏輯）

觀點：邀請相關的業(yè)務方一起參會表明需求與討論產(chǎn)品方案會提升需求分析的效率。

曾經(jīng)有幾次：業(yè)務詳細描述了他的需求之后，會讓我給他輸出一個可行方案。例如：業(yè)務說：“我們平時是這樣對賬的……想讓你給我出一個方案。”這就有點像我是提供管理方案的人，我給業(yè)務提供管理方案，然后由業(yè)務判斷是否合適，如果不合適我再去思考新的方案。有的時候方案準確命中業(yè)務的需求那是比較好的結(jié)果，但是有的時候如果方案整體不是特別符合業(yè)務的方向，業(yè)務會讓我修改，修改一次還好，但是如果修改幾次，那么產(chǎn)品經(jīng)理的效率會非常低，可能有很長的一段時間都是在做這么個需求。

到這里，可能會有一個疑問：產(chǎn)品經(jīng)理不就是提供方案的嗎，這不是很合理嗎？

確實很合理，我反思出來我當時最大的問題點是：我沒有要求提需求的同事拉所有相關的同事一起來商量出一個可行的方案，反而是我自己基于得到的一些可以說不夠細節(jié)的信息在構(gòu)思這個方案，這個時候是比較棘手的。

當時我不是特別在乎每個步驟是誰來處理的，因為之前我也試過這樣操作是可行的。結(jié)果就是給了一個方案之后業(yè)務不滿意，但是追問怎么不滿意，等到他回答了之后算是給了我一個大方向，然后基于這個大方向輸出方案之后，與相關的業(yè)務去評審的時候，就會出現(xiàn)很多新的需求，又需要基于這些新的需求點去完善方案。

總的來說，一整個流程下來會花費不少時間，效率會比較低。

我其實很多次也只是了解整體流程就可以做出讓業(yè)務代表滿意的方案的情況，但是實際上線之后，每一個相關的人都會給我提需求，很多時候還是我不解決他們的問題，他們就不會使用系統(tǒng)的情況。

基于這些情況之后，我總結(jié)下來，一定要找到所有相關的人來協(xié)商出一個讓各方都滿意的流程。當我把這些人都聚集起來之后按照一定的流程去讓大家說出自己的需求，然后在這個會議上我應該有一個方案的大方向，有了這個大方向之后，我后面出方案的效率會有非常大的提升。

當然，這個動作并不只是為了提高我的效率，更是一個有效的方案的很好的助力。當然有的時候你無法不基于沒法接觸到很多業(yè)務相關人就開始做方案的情況，因為我們有進度的要求，在接到需求之后了解大概的情況之后就開始做方案，然后給到各個業(yè)務相關人確認是否可行也是一個方法，但是不是產(chǎn)品經(jīng)理比較高效的方法。

所以總的來說，引導業(yè)務們協(xié)商出一個合適的流程是非常必要的，這是產(chǎn)品方案的大方向，有了這個方向之后，產(chǎn)品方案可以很快地輸出。

最后給這種情況寫一個前提：并不適用于所有情況，大多數(shù)的關于流程固化到系統(tǒng)上的需求都是適合的，需要自己加以判斷。像有一些業(yè)務方不會有這么多時間去思考這些東西，就是需要你提供方案給他，例如：總裁、總監(jiān)等等，或者是當我作為管理人員（假設我是主管）需要提供部門的管理方案的時候。

二、方案輸出高效之道：假設檢驗法

觀點：遇事不決，大膽假設，細致驗證，果斷選出你認為最好的方案。

在我們的大方向出來之后，接下來是方案的輸出，這其中會涉及到各個細節(jié)。

關于細節(jié)，我們常常會出現(xiàn)一個問題，當?shù)竭_同一個目的地時，可能有2個方案都可行，然后我們會不確定是A還是B比較好，此時不知道你是怎么處理的？

我在剛做產(chǎn)品經(jīng)理的時候，通常都是在腦子里去比較這2個方案的優(yōu)劣，然后決定出一個方案，那時候還不是思考得很深，比較表面的，有的時候會比較糾結(jié)，因而浪費了時間。

基于這么一種情況，我認為其實不用糾結(jié)，你完全可以將所有的方案都羅列出來，然后對比他們的優(yōu)劣，然后決定一個你認為的最好的方案，當然這個方案可能不會是所有人看來都是最好的。

在評審會的時候，技術也會給我提出方案，一般來說他們提的方案我很多時候都是思考過的，對比過的，因而我能說出來為什么不采用技術建議的方案。

在對比的過程中，我會有以下幾個維度：交互是否便捷、開發(fā)成本、是否符合普通人的認知。

1. 交互是否便捷：也就是能不能讓業(yè)務少操作一步，這對于我來說是重要的，我認為一個好的產(chǎn)品應該減少操作人的時間浪費，即使開發(fā)的時長會增加一點。
2. 開發(fā)成本：衡量方案的開發(fā)成本，當然這個是由我來判斷，大多數(shù)情況下我不會感到疑惑無法判斷，如果無法判斷我會請教技術同事。在大多數(shù)情況下，開發(fā)成本并沒有什么很大的變化，不影響你大膽地假設。
3. 是否符合大多數(shù)人的認知：我不希望每個人在使用這個功能的時候都會感到疑問，這是什么，那又是什么。系統(tǒng)應該盡量地跟現(xiàn)實世界對應起來，讓用戶用起來是熟悉的親切的。