中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

一、需求分析高效之道

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

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

在接觸到比較多產品經理之后，我發現產品經理的思維模型有比較大的區別，有的人是僅基于問題相關的人和事情去分析需求；有的人會基于問題相關的人和事情以及市面上的產品調研去分析需求；還有的人會基于問題相關的人和事情、市面上的產品調研以及實踐經驗總結去分析需求。最后一種方法是我最認同的，也是我認為的高效的需求分析的思維模型。

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

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

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

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

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

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

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

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

到這里，可能會有一個疑問：產品經理不就是提供方案的嗎，這不是很合理嗎？

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

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

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

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

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

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

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

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

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

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

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

關于細節，我們常常會出現一個問題，當到達同一個目的地時，可能有2個方案都可行，然后我們會不確定是A還是B比較好，此時不知道你是怎么處理的？

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

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

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

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

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