產品經理如何將需求分析正確應用到工作中
閱讀167
需求分析的目的是在團隊開發軟體的過程當中，
在我們工作的實際當中，產品經理一聽要做新功能，就喜歡鑽牛角尖，去做競品分析、使用者分析、資料分析、調研報告等等，這些工作真要做完，快則需要兩三天，慢則需要三四周的時間，分析完以後，產品經理開始梳理業務邏輯、做方案。緊跟著整個UCD部門和開發部門對方案做評審，
那麼在繪製的環節當中我們能否不去參考競品，值得肯定的是我們的競品有可能已經是歷經了好幾年時間的打磨獲取到了百萬級千萬級的用戶，參考競品的目的是我們繞過許多彎路，當然也不能否定產品經理不參考競品就做不出好的產品。但在實際情況之下，當我們繪製完原型以後，再去跟我們競品比較的時候，我們都會忍不住將不完善的地方補充完善。
我們來舉例分析，通過上面的這張圖，我們會有這樣的一些想法，在首頁面的頂部是不是應該再加點其他內容，下面是否也放個推薦上去，這個推薦也是一些廣告位元，對產品後期的發展會帶來一定的收益，職場跟群組有一定的衝突性是否應該合併為一塊等等越來越多的問題，
到了投入開發的環節，技術這邊又會回饋出一些新的問題出來，比如某些功能需求技術起先沒有理解透徹真正做的時候發現實現起來可能需要浪費不少的時間，能否放到後面的版本再完善，某些操作許可權上考慮到了1、2、3，三種情況又會出現第4種情況，這時候砍功能變更需求，又要浪費掉不少的時間，在這樣的一個過程當中，我們浪費了大量的時間不說有可能都錯失了很多商業機會，最終開發出的軟體也許都不是我們使用者真正想要的。
我們使用者真正需要什麼，使用者只能說形式上表面上的一些東西，用戶的真實需求，是需要產品經理自己要去發掘、去提煉，提煉與發掘的過程當中產品經理不應該進行引導比如你是不是想要這樣的功能，那樣的功能你想不想要，使用者這時候是跟著產品經理的思維在走，所以產品經理訪談使用者的時候這是一種證龜成鱉的做法。
提煉與發掘的過程並不能保證這個需求就是用戶的核心需求。舉個例子，獵豹流覽器的成功並不是因為主打的要做速度最快的流覽器而成功，而是搶火車票的一個增值功能，才讓這個產品成功。
那麼產品經理究竟如何將需求分析正確應用到工作當中，最快的做法是不要將分析到的結果都用在寫文檔走流程上面，應該直接繪製原型，將原型快速呈現在我們用戶群體或者團隊面前，這樣做我們會節省很多的時間，利用定方案，變更需求的過程所需要的時間，我們的產品可能已經上線，上線後再對產品做調整，提升使用者對我們產品的滿意度。
本文由 @易辰 原創發佈於產品壹佰，未經許可，禁止轉載。
某些操作許可權上考慮到了1、2、3，三種情況又會出現第4種情況，這時候砍功能變更需求，又要浪費掉不少的時間，在這樣的一個過程當中，我們浪費了大量的時間不說有可能都錯失了很多商業機會，最終開發出的軟體也許都不是我們使用者真正想要的。我們使用者真正需要什麼，使用者只能說形式上表面上的一些東西，用戶的真實需求，是需要產品經理自己要去發掘、去提煉，提煉與發掘的過程當中產品經理不應該進行引導比如你是不是想要這樣的功能，那樣的功能你想不想要，使用者這時候是跟著產品經理的思維在走，所以產品經理訪談使用者的時候這是一種證龜成鱉的做法。
提煉與發掘的過程並不能保證這個需求就是用戶的核心需求。舉個例子，獵豹流覽器的成功並不是因為主打的要做速度最快的流覽器而成功，而是搶火車票的一個增值功能，才讓這個產品成功。
那麼產品經理究竟如何將需求分析正確應用到工作當中，最快的做法是不要將分析到的結果都用在寫文檔走流程上面，應該直接繪製原型，將原型快速呈現在我們用戶群體或者團隊面前，這樣做我們會節省很多的時間，利用定方案，變更需求的過程所需要的時間，我們的產品可能已經上線，上線後再對產品做調整，提升使用者對我們產品的滿意度。
本文由 @易辰 原創發佈於產品壹佰，未經許可，禁止轉載。