起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識是什么原因導致了技術團隊對需求理解的不到位？
近日，陰雨連綿，影響到人的精氣神。
運營中心抱怨：我們都提出了需求，也和產品經理說了，產品說可以做，但是技術部門為什么老是不能滿足我們的需求。
技術中心抱怨：我們人手不足，而且已經有很多高優先級的需求了，運營提的需求還排不上號。
老板抱怨：項目總監（技術中心負責人）你對需求理解不透徹，運營中心提的需求優先級很高，你們需求分析和項目排期都拍腦袋的？
于是，老板接連兩天召開了兩次運營和技術的會議，希望解決兩個中心在日常工作中出現的溝通不暢問題。
是什么原因導致了溝通不暢，技術團隊對需求理解的不到位呢？
在作者看來，可以簡單歸為三個因素
- 一是業務流程
- 二是職責范圍
- 三是人
先來看看流程
在會議中，項目總監列出了當前的研發工作流程，沒記錯的話步驟如下：
聰明的你，可能發現了什么問題吧。
沒錯，在提出需求與技術評估之間，缺了一個重要環節——需求分析和評審。
在作者看來，合乎正義的研發流程，應該是這樣的：
具體到不同公司，可能會根據實際情況對流程做出刪減。
但需求分析和評審，無論在哪里都應該是不能省略或輕易帶過的。因為這關系到往后整個技術團隊對需求的理解是否充分，整個開發過程對需求的執行是否順暢，乃至整個功能和產品的落地是否能按需完成。
那么該如何進行需求分析呢？
一是獲取需求
可以分為“定性和定量，說和做”兩種維度來獲取，定性的說即用戶訪談，定性的做即可用性測試，定量的說即問卷調查，定量的做即數據分析（可參閱蘇杰的《需求采集的“Z方法”》）。除此以外，產品經理還可以通過競品分析，了解市場對手對用戶需求的滿足情況，以及制作簡單的產品需求收集表，對外來需求進行規范化獲取。
二是將獲取到的外在需求轉化為內在需求
很多時候需求方都是以直接提供解決方案的方式，將需求傳達到產品經理處的。產品經理應該從需求提出的原因、場景、實現成本和可獲價值等維度進行分析，才能為內在需求提供更優的解決方案。譬如，運營人員提出“想在App增加一個紅包功能”，這時產品經理就不能簡單照做，因為這只是一種解決方案，而不是內在需求。通過分析，得知內在的需求是，運營人員想通過一個活動或功能來提升App的用戶活躍度和粘度。而要達到這個目的，其實還有多種方案，將不同方案的開發成本與產出價值進行比較估算，再擇優而選。
三是對不同的需求排列優先級
較為常用的方法是四象限法則，即根據重要和緊急兩個維度，劃分為既重要又緊急、重要但不緊急、緊急但不重要、既不緊急也不重要四個象限，將不同的需求歸入到相應的級別當中。至于如何判斷哪種程度屬于重要，哪種程度程度屬于緊急，就需要產品經理通過與老板和各個部門溝通，以取得一個獲得多方共識的判斷標準。
最后是對需求進行整理歸檔。建立起產品經理自己的需求管理文檔，便于需求實現過程的跟蹤和日后回溯。
在進行需求分析后，還應該組織相關的部門和人員進行需求評審。
有時候，產品經理完成需求分析，沒有經過評審就直接動手做原型，到了原型評審，才連需求一同過審，這樣就極容易出現在評原型時由于需求大幅變動，導致功夫白費的情況，吃力不討好。
因此保險的做法是，在需求分析后就組織需求評審。通過需求評審，確定本次策劃需要完成的功能點一二三四，避免到原型評審時再回頭討論需求，而只對原型是否滿足之前確認的功能點進行評審。這里有一個技巧，就是在需求評審（或原型評審）前就與相關人員進行溝通，爭取在會議前就對需求（或原型）達成接近意見，降低在評審中遇到阻力的幾率。
正因為沒有重視需求分析和評審的流程環節，才導致了運營和技術在事后經常圍繞需求發生扯皮的情況，明明我們運營提的需求很重要，你們技術為什么總沒滿足？
再來看看職責
你可能會說，需求分析沒做好，溝通協調沒到位，那肯定是產品經理的責任了。
也沒錯，因為產品經理要做的事，首先就是分析需求合理性，如果覺得需求靠譜，就應該組織相關部門進行需求評審和技術評估，如果評審有爭議，還應該繼續往上匯報。
我問產品小伙伴：你之前沒有組織需求評審的？小伙伴說沒有。
我問為什么？小伙伴說：我們產品部，是屬于技術中心下面的，比技術和運營中心低級，技術中心Boss是項目總監，總監都沒組織需求評審，我去越級組織不好啦。
我說那技術和運營對需求出現分歧，你也沒有繼續往上級的產品決策者匯報咯？小伙伴說：越級上報更不好了，運營提的需求，已經和項目總監說過，他決定做不做就行了。
旁邊的運營經理聽到說：那我們還不如直接找項目和技術談，都不用找你們產品了。
嗯，真有道理啊。
從以上的對話中，可以引申出關于職責范圍的幾個問題。
一是需求評審要不要有？
很明顯，如前文所述，這是產品研發流程中必不可少的一環，必須要有。
二是由誰來組織需求評審，項目經理還是產品經理？
要回答這個問題，必須先弄清楚項目經理和產品經理的職責分別是什么。
項目經理（Project Manager），在于將目標轉化為可量化可實現的項目進度計劃，關鍵詞是項目的范圍、時間、質量、成本——通過資源管理對項目的開發過程和按預期完成計劃負責，偏重于執行。
產品經理（Product Manager），在于將可行的用戶需求轉化為可用的產品功能，關鍵詞是產品的需求、用戶、價值——通過需求管理對產品誕生后是否受用戶認可負責，偏重于策劃。
因此不難看出，只要是涉及到產品需求的討論或評審，都應該由產品經理組織，而不應該礙于職位高低，將需求評審的發起權假手于人。
三是由誰來決定需求做還是不做以及需求優先級
理想的情況是，一個產品從0到1到N，產品經理全程參與。從初期的產品理念定位到往后的需求推動，產品經理都能根據自己對產品全局的理解做出判斷和把控，決定做什么，不做什么。
現實的情況是，很多產品經理都是在產品研發中段（0.X）乃至產品成型后（1.X，2.x，3.x）才加入團隊的。因而產品經理對產品全局的了解和把控不可能比團隊早期成員更清楚，這時最佳的工作方式就是把自己定位為需求接收者，通過時間不斷加深對產品的認識，再逐漸過渡到需求推動者的角色。
更現實的情況是，在中小型公司，最大的產品經理其實是公司老板。當產品經理無法或無權決定某個需求做還不是不做，哪個先做哪個后做時，就應該去找更高級的產品決策者來溝通決定，而不應該讓更偏重開發排期的項目人員來決定。因為從上面對項目經理的職責描述可以看出，項目工作的重點本身就不在于需求調研分析，而在于根據產品經理給出的需求優先級，調配資源去排期實施。
要一人同時兼顧產品需求調研和項目計劃執行，無異于讓其左右互搏，難免顧此失彼。所以才會出現本文開始，老板抱怨項目總監對需求理解不充分的情況，所謂術業有專攻，要其透徹理解需求，還不如讓其轉職產品。
最后，所有問題其實都可以歸結為人的問題
規則是死人是活，不同人在不同情況，對事情往往會有不同的處理方法，但在此就不展開討論了，遇到問題想辦法解決就是。
如果你是文中的產品經理、項目總監或者老板，會如何解決呢？
作者：pmsky（微信公眾號：pmskywx），互聯網產品經理，曾涉足在線教育、物聯網等領域，目前從事跨境電商。
本文由 @pmsky 原創發布于人人都是產品經理?，未經許可，禁止轉載。
很有收獲，求更新。
較理想化
道理流程都是對的，但…既然產品經理叫做產皮汪/產品狗，意味著最起碼要“聽話”。
最簡單的場景：
上級領導拍了一個需求，若你講出1/2/3/4/5點說明此需求不合適，上級領導會認為跟你溝通太消耗成本；而若上級領導一拍出來，你就接手做了，上級領導會認為你沒有自己的想法。
我倒是贊成，規則是死的，人是活的，但還有一點，可能作者忽略了，產品經理做的是否“爽”，直接取決于其上級的領導水平。這里延展開說一下，為什么大多創業公司都會死掉，其中一個因素就是但凡創業的人其產品思想都認為自己天下第一，因此是聽不見產品經理多少意見的。
這里面還涉及到這樣一個心理：若老板認為這個需求要做，產品否決；老板會這樣想，若按照自己的想法做，成功了，算自己的，順帶證明自己牛逼，失敗了，以后也能作為自己的一個“經驗”到處去“炫耀”。而按照他人的想法做，成功了，說明自己比產品經理sb，失敗了，到時候后悔自己沒有堅持。
扯遠了，總之，作者的做法在公司資源比較充足的情況下是沒有問題的。在其他公司，受太多因素影響，最主要的依舊是人！還是人，得擁有權力的人相信作者這一套才是。
需求什么的，如果有數據，數據分析，再做個報告給老板。如果市場上同質化的產品很多了，做個競品分析，明確下產品市場定位，再把報告給老板看。哎，用事實，數據說話。
一針見血
目前我的狀況就是，自己是產品，兼職項目，策劃者和執行者的身份在同一人身上，左右為難
me too ,外包公司
外包公司+1