雷鋒網(wǎng)按：本文作者pmsky（微信公眾號：pmskywx），互聯(lián)網(wǎng)產(chǎn)品經(jīng)理，曾涉足在線教育、物聯(lián)網(wǎng)等領(lǐng)域，目前從事跨境電商。

運營中心抱怨：我們都提出了需求，也和產(chǎn)品經(jīng)理說了，產(chǎn)品說可以做，但是技術(shù)部門為什么老是不能滿足我們的需求。

技術(shù)中心抱怨：我們?nèi)耸植蛔?，而且已?jīng)有很多高優(yōu)先級的需求了，運營提的需求還排不上號。

老板抱怨：項目總監(jiān)（技術(shù)中心負責人）你對需求理解不透徹，運營中心提的需求優(yōu)先級很高，你們需求分析和項目排期都拍腦袋的？

于是，老板接連兩天召開了兩次運營和技術(shù)的會議，希望解決兩個中心在日常工作中出現(xiàn)的溝通不暢問題。

是什么原因?qū)е铝藴贤ú粫常夹g(shù)團隊對需求理解的不到位呢？

在作者看來，可以簡單歸為三個因素

業(yè)務(wù)流程

職責范圍

人

先來看看流程

在會議中，項目總監(jiān)列出了當前的研發(fā)工作流程，沒記錯的話步驟如下：

聰明的你，可能發(fā)現(xiàn)了什么問題吧。

沒錯，在提出需求與技術(shù)評估之間，缺了一個重要環(huán)節(jié)——需求分析和評審。

在作者看來，合乎正義的研發(fā)流程，應(yīng)該是這樣的：

具體到不同公司，可能會根據(jù)實際情況對流程做出刪減。

但需求分析和評審，無論在哪里都應(yīng)該是不能省略或輕易帶過的。因為這關(guān)系到往后整個技術(shù)團隊對需求的理解是否充分，整個開發(fā)過程對需求的執(zhí)行是否順暢，乃至整個功能和產(chǎn)品的落地是否能按需完成。

那么該如何進行需求分析呢？

一是獲取需求

可以分為“定性和定量，說和做”兩種維度來獲取，定性的說即用戶訪談，定性的做即可用性測試，定量的說即問卷調(diào)查，定量的做即數(shù)據(jù)分析（可參閱蘇杰的《需求采集的“Z方法”》）。除此以外，產(chǎn)品經(jīng)理還可以通過競品分析，了解市場對手對用戶需求的滿足情況，以及制作簡單的產(chǎn)品需求收集表，對外來需求進行規(guī)范化獲取。

二是將獲取到的外在需求轉(zhuǎn)化為內(nèi)在需求

很多時候需求方都是以直接提供解決方案的方式，將需求傳達到產(chǎn)品經(jīng)理處的。產(chǎn)品經(jīng)理應(yīng)該從需求提出的原因、場景、實現(xiàn)成本和可獲價值等維度進行分析，才能為內(nèi)在需求提供更優(yōu)的解決方案。

譬如，運營人員提出“想在App增加一個紅包功能”，這時產(chǎn)品經(jīng)理就不能簡單照做，因為這只是一種解決方案，而不是內(nèi)在需求。通過分析，得知內(nèi)在的需求是，運營人員想通過一個活動或功能來提升App的用戶活躍度和粘度。而要達到這個目的，其實還有多種方案，將不同方案的開發(fā)成本與產(chǎn)出價值進行比較估算，再擇優(yōu)而選。

三是對不同的需求排列優(yōu)先級

較為常用的方法是四象限法則，即根據(jù)重要和緊急兩個維度，劃分為既重要又緊急、重要但不緊急、緊急但不重要、既不緊急也不重要四個象限，將不同的需求歸入到相應(yīng)的級別當中。至于如何判斷哪種程度屬于重要，哪種程度程度屬于緊急，就需要產(chǎn)品經(jīng)理通過與老板和各個部門溝通，以取得一個獲得多方共識的判斷標準。

最后是對需求進行整理歸檔。建立起產(chǎn)品經(jīng)理自己的需求管理文檔，便于需求實現(xiàn)過程的跟蹤和日后回溯。

在進行需求分析后，還應(yīng)該組織相關(guān)的部門和人員進行需求評審。

有時候，產(chǎn)品經(jīng)理完成需求分析，沒有經(jīng)過評審就直接動手做原型，到了原型評審，才連需求一同過審，這樣就極容易出現(xiàn)在評原型時由于需求大幅變動，導(dǎo)致功夫白費的情況，吃力不討好。

因此保險的做法是，在需求分析后就組織需求評審。通過需求評審，確定本次策劃需要完成的功能點一二三四，避免到原型評審時再回頭討論需求，而只對原型是否滿足之前確認的功能點進行評審。這里有一個技巧，就是在需求評審（或原型評審）前就與相關(guān)人員進行溝通，爭取在會議前就對需求（或原型）達成接近意見，降低在評審中遇到阻力的幾率。

正因為沒有重視需求分析和評審的流程環(huán)節(jié)，才導(dǎo)致了運營和技術(shù)在事后經(jīng)常圍繞需求發(fā)生扯皮的情況，明明我們運營提的需求很重要，你們技術(shù)為什么總沒滿足？

再來看看職責

你可能會說，需求分析沒做好，溝通協(xié)調(diào)沒到位，那肯定是產(chǎn)品經(jīng)理的責任了。

也沒錯，因為產(chǎn)品經(jīng)理要做的事，首先就是分析需求合理性，如果覺得需求靠譜，就應(yīng)該組織相關(guān)部門進行需求評審和技術(shù)評估，如果評審有爭議，還應(yīng)該繼續(xù)往上匯報。

我問產(chǎn)品小伙伴：你之前沒有組織需求評審的？小伙伴說沒有。

我問為什么？小伙伴說：我們產(chǎn)品部，是屬于技術(shù)中心下面的，比技術(shù)和運營中心低級，技術(shù)中心Boss是項目總監(jiān)，總監(jiān)都沒組織需求評審，我去越級組織不好啦。

我說那技術(shù)和運營對需求出現(xiàn)分歧，你也沒有繼續(xù)往上級的產(chǎn)品決策者匯報咯？小伙伴說：越級上報更不好了，運營提的需求，已經(jīng)和項目總監(jiān)說過，他決定做不做就行了。

旁邊的運營經(jīng)理聽到說：那我們還不如直接找項目和技術(shù)談，都不用找你們產(chǎn)品了。

嗯，真有道理啊。

從以上的對話中，可以引申出關(guān)于職責范圍的幾個問題。

一是需求評審要不要有？

很明顯，如前文所述，這是產(chǎn)品研發(fā)流程中必不可少的一環(huán)，必須要有。

二是由誰來組織需求評審，項目經(jīng)理還是產(chǎn)品經(jīng)理？

要回答這個問題，必須先弄清楚項目經(jīng)理和產(chǎn)品經(jīng)理的職責分別是什么。

項目經(jīng)理（Project Manager），在于將目標轉(zhuǎn)化為可量化可實現(xiàn)的項目進度計劃，關(guān)鍵詞是項目的范圍、時間、質(zhì)量、成本——通過資源管理對項目的開發(fā)過程和按預(yù)期完成計劃負責，偏重于執(zhí)行。

產(chǎn)品經(jīng)理（Product Manager），在于將可行的用戶需求轉(zhuǎn)化為可用的產(chǎn)品功能，關(guān)鍵詞是產(chǎn)品的需求、用戶、價值——通過需求管理對產(chǎn)品誕生后是否受用戶認可負責，偏重于策劃。

因此不難看出，只要是涉及到產(chǎn)品需求的討論或評審，都應(yīng)該由產(chǎn)品經(jīng)理組織，而不應(yīng)該礙于職位高低，將需求評審的發(fā)起權(quán)假手于人。

三是由誰來決定需求做還是不做以及需求優(yōu)先級

理想的情況是，一個產(chǎn)品從0到1到N，產(chǎn)品經(jīng)理全程參與。從初期的產(chǎn)品理念定位到往后的需求推動，產(chǎn)品經(jīng)理都能根據(jù)自己對產(chǎn)品全局的理解做出判斷和把控，決定做什么，不做什么。

現(xiàn)實的情況是，很多產(chǎn)品經(jīng)理都是在產(chǎn)品研發(fā)中段（0.X）乃至產(chǎn)品成型后（1.X，2.x，3.x）才加入團隊的。因而產(chǎn)品經(jīng)理對產(chǎn)品全局的了解和把控不可能比團隊早期成員更清楚，這時最佳的工作方式就是把自己定位為需求接收者，通過時間不斷加深對產(chǎn)品的認識，再逐漸過渡到需求推動者的角色。

更現(xiàn)實的情況是，在中小型公司，最大的產(chǎn)品經(jīng)理其實是公司老板。當產(chǎn)品經(jīng)理無法或無權(quán)決定某個需求做還不是不做，哪個先做哪個后做時，就應(yīng)該去找更高級的產(chǎn)品決策者來溝通決定，而不應(yīng)該讓更偏重開發(fā)排期的項目人員來決定。因為從上面對項目經(jīng)理的職責描述可以看出，項目工作的重點本身就不在于需求調(diào)研分析，而在于根據(jù)產(chǎn)品經(jīng)理給出的需求優(yōu)先級，調(diào)配資源去排期實施。

要一人同時兼顧產(chǎn)品需求調(diào)研和項目計劃執(zhí)行，無異于讓其左右互搏，難免顧此失彼。所以才會出現(xiàn)本文開始，老板抱怨項目總監(jiān)對需求理解不充分的情況，所謂術(shù)業(yè)有專攻，要其透徹理解需求，還不如讓其轉(zhuǎn)職產(chǎn)品。

最后，所有問題其實都可以歸結(jié)為人的問題。

規(guī)則是死人是活，不同人在不同情況，對事情往往會有不同的處理方法。但在此就不展開討論了，遇到問題想辦法解決就是。

如果你是文中的產(chǎn)品經(jīng)理、項目總監(jiān)或者老板，會如何解決呢？

雷峰網(wǎng)特約稿件，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。