起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識業務需求不好接？給你一份“自救指南”
作為一名產品經理，你有經歷過業務方提出一些天馬行空不切實際的需求嗎？有經歷過業務方需求描述不清晰、提完需求又反復修改的痛苦嗎？作者在本文中結合工作中遇到的問題，提出了自己的解決辦法，希望能夠對你有幫助。
產品經理的工作流程的前半部分是在承接需求，這個過程里我們會遇到很多麻煩，感受很多痛點。我想就我工作里這塊部分遇到的問題，淺談一點自己的理解，并且說一下我當下的解決辦法。
一、何為需求？價值幾何？
（一）需求是什么？
產品經理的日常就是找需求，接需求，做需求…… 但是你有沒有思考過，需求到底是個啥？
禮記里有句話說：“飲食男女，人之大欲存焉”。這句話意思是：飲食吃喝與男女情愛，是人存在的最大欲求。我們的欲望其實就是需求。
因為生活中存在太多的問題和太多不滿意，我們就會產生解決問題和讓自己滿意的欲望，然后導致人產生各種需求。
馬斯洛把人的需求分成五個層次：生理需求、安全需求、社交需求、尊重需求、自我實現需求。具體的我不再贅述，大家應該都很了解。但是不論哪個層次的需求，它們都是推動的人們各種行為的內因。
（一）價值幾何？
作為產品經理，我們之所以做一個產品，肯定是為了解決某些問題，滿足某些需求。需求之于產品經理，就像“汽車之于福特”。
你應該聽過 “用戶要一匹馬，福特給了用戶一輛車” 的故事，把“馬”變成“野馬”，這就是價值所在。
當然，我想表達的重點其實不是給了用戶什么東西。其實你也可以預想一下你給了用戶一頭驢，一頭豬之后的場景，也許現在福特就會是一個食品公司？皮革公司？重點在于發現和思考需求中的用戶價值與商業價值。
二、產品經理和需求的“愛恨情仇”
我曾經聽過梁寧老師的課，她認為產品經理需要有判斷信息，抓住要點，整合有限資源向外輸出的能力。
我是比較認同這個觀點的。因為產品工作處在信息的上游，這些信息大部分都沒有“降噪”，需求又多又雜。我們此時就需要擁有“判斷信息，抓住要點”的能力。判斷信息可以理解為是判斷需求的真偽（識別需求），抓住要點可以理解為抓住當下最關鍵的那些需求（排列優先級）。
其實產品經理日常工作的很大一部分時間就是和需求進行無休止的“纏斗”。這些需求的來源一般是來自業務，用戶，老板和產品經理本身這四個部分。在需求這一環節，我們的戰略目標就是“解決”掉當前所有需求。
- 對那些偽的、無法落地的和沒考慮清楚的需求，一律打入“冷宮”，什么時候想清楚了再來見“朕”。
- 對那些真的，可落地的，清晰且有價值的需求，咱們得一個也不能漏的納入到需求池里。但是這些需求的“牌子”也得一個個翻。我們要按照優先級，給這些需求排個序。產品的項目安排（包括產品設計和研發）都按照這個順序往下進行。
不過真實處理需求的過程中會遇到很多麻煩。需求真真假假，需求提出方還各不相同（不同的需求方溝通起來也不一樣）。我們面臨的困難有時候在于：不僅要搞定需求，也得搞定提需求的人。
我把產品經理處理需求的流程簡單分為四步，今天我們主要講第一步，也是非常重要的一步——承接需求。由于需求的來源很多，一文難以講全，所以本文先講如何承接來自業務方的需求。
產品工作簡易流程圖
三、如何承接業務方的需求
（一）什么是業務
公司多個部門協作（如運營/銷售/市場），履行不同的職責，共同達成業務目標（比如賺一個“小目標”）。其中提出需求的部門就是業務方，他們的需求就是業務需求。
（二）產品經理對待業務需求的原則
不管做人做事，都要守住原則。基于原則做事，事情才能做的長久。對待業務需求，請記住下三點原則：
1.不要參雜私人感情，一切以業務為先。
不要因為某個需求提出者和你的關系好就做這個需求，也不要因為某個提出者和你的關系差就不做這個需求。請記住需求本身的價值是你判斷的唯一標準。為了需求的一切，一切為了需求。
2.業務方盡可能多提經過一定程度思考的需求。
- 盡可能的多提出需求：《人人都是產品經理》一書中說“需求需要被盡可能多的采集”，我很認同這句話，“韓信點兵多多益善”。我們不怕接到荒謬的需求，我們怕遺漏合理的需求。如果最后大家都不提需求，最后受損的還是公司的產品和業務。
- 有一定程度思考的需求：經過思考過的需求不會不堪一擊，也不會有很明顯的漏洞，所以才具備被討論的價值。我們在和業務方討論需求的時候，也可以最大程度上聊清楚這個需求的價值。雖然我們不怕接到荒謬的需求，但是荒謬的需求會降低團隊效率。
3.產品經理要對所有的需求進行深度思考。
產品經理是一個非常需要決策能力的崗位，整個職業生涯幾乎都在做著決策。不經過深度思考就直接決策，就像海上的一個求生者喝海水，無異于飲鳩止渴?？雌饋碜隽撕芏嘈枨?，但其實對產品和業務沒有幫助，反而有可能給系統增負。所以讓你的思考為需求做一層過濾，于產品于業務都有益處。
（三）對接業務需求的痛點
和業務方溝通的時候，大家或多或少的都被困擾過，結合本人真實經歷，我總結成以下幾點：
- 需求描述不清晰（需求描述千奇百怪，理解起來很費勁）
- 每個需求都是重要又緊急，優先級失效（需求優先級個個P0，先做誰呢？）
- 想到需求就提，大部分都是不經思考的偽需求（需求質量很低，來回溝通降低效率）
- 雙方溝通不順，無法達成共識（一意孤行不聽勸，雙方不在同一個頻道）
- 提完需求，后期反復修改（看到我的眼神了嗎？這就是之后研發想刀我的眼神）
括號里的是開玩笑，不過不好好對待需求，版本上線后，你可能面臨“雖然我也不太懂，但這不是我想要的”的場景。
（四）解決痛點問題的思路
反思復盤，找到問題，根據痛點問題整理出思路：
- 讓業務方提靠譜的需求：明確標準，解決需求不靠譜的問題。 通過一套標準來幫助業務方想清楚。
- 提升團隊溝通效率：設定流程，提高溝通效率，做到信息對稱。通過一套流程來降低溝通成本，增加團隊協作效率。
（五）模版：業務提交需求模版
制定標準模版的意義：
- 降低業務方提交需求的成本：我們常常會要求業務方提交的需求經過思考，可我們卻從來沒有告訴他們怎么思考。提供一套標準，可以理解為“思考模版”。它可以很大程度上降低業務方思考需求的難度（按照模版來提需求難度就像開卷考試），畢竟這不是他們的主要工作，我們需要提供支持讓提交需求的人盡快上手。
- 提升業務方提交的需求的質量：我們常常會要求業務方提交的需求質量高一點，信息全一點，可我們卻從來沒有告訴他們什么是“高質量”。我們給標準是讓業務方把最開始在腦子里的需求按照“模版”進行思考的時候，能更清晰的了解自己想要什么，想要多少，需求目標等等，同時把思考結果記錄下來，也可確保寫作者不會少寫或者亂寫某些內容。
- 最大程度確保思維的一致：我之前有篇文章寫了“研發思維”和“產品思維”的區別，但其實“產品思維”和“業務思維”也有很大的不同。其實是所在的職能崗位不同，團隊目標，業務流程，思維方式都不一樣。每一方都是基于自己的立場去設定預期并進行溝通。很多時候你說前門樓子，他說胯骨軸子。所以讓對方通過“思考模版”的洗禮，很大程度上能確保你們思考的是同一個“頻道”。即使最后討論的時候你們還是有偏差，我相信作為產品經理的你，也一定有足夠的耐心和同理心去處理好這個需求。
標準模版的內容：
1.需求背景（包含三個點）
- 1.1:背景信息（什么場景下產生這個需求，以場景化，敘事的方式進行描述，最好可以加入一些數據進行支撐。）
- 1.2:目前存在的問題
- 1.3:當前方案及遇到的問題（無法滿足需求的原因）
2.需求目標?（講清楚需求的目標以及能帶來的價值，對優先級的設定也有指導意義。如業務目標的達成，用戶的體驗，數據決策層的指導or降本增效）
3.當前業務流程（最好用流程圖）
4.業務策略（如一次運營營銷活動，有對應的時間段，在考慮上線時間和優先級時可作為參考）
5.預期上線時間
6.優先級（需求重要性）
可參照我寫的這份例子一起查看：
其實《人人都是產品經理》一書里有一個單向需求模版，我放在下面，其實這也是一個“思考模版”。內容更多，維度也更加全面，不過我認為平時工作還是盡量簡化業務方提需求的工作，“less is more”。
這套模版不是束縛，大家可以在此基礎上增加更多想法，可以根據自己公司的不同情況進行修改。如果大家有更好的建議，也可以在評論區進行評論，歡迎大家探討。
（六）一套流程：業務需求溝通流程
流程的意義：
其實大家在產品工作的時候，會接觸到非常多的流程。諸如日常發布流程，緊急發布流程，需求變更流程等等。這些流程現在或多或少的幫助到了大家，隨著不斷完善，久而久之一套行之有效的流程就應用了起來。
但是在協作過程中，尤其是跨部門協作時，其實很少有公司有一套溝通流程，如果沒有流程的話，勢必出現這些問題：
1. 業務隨時提需求，產品感覺時間被切割的細碎，而且事情又多又亂
常常有產品吐槽，自己的時間少，被切割的細碎，難以深度思考。往往只有晚上的時間才能安靜的工作。業務方隨時提需求就是其中一個因素。
2. 經常有人提需求，但是需求內容常常重復
多個部門協作，往往一個部門有多個提需求的人，同一時間段內甚至需求還有重復。這將會造成產品經理工作的極大不便。
3. 業務方常常問需求的進度
需求是否被采納，是否進入版本規劃，是否有上線時間。這些信息都要和業務方進行同步，不然會造成信息不對稱和信任缺失，如果不重視甚至會影響團隊協作。
流程內容：
流程分兩種，一個是常規需求，一個是緊急需求。
接業務需求流程（常規需求）：
1. 同一部門固定人員提需求
固定一個需求輸出口，其實對于產品經理工作而言，好處很大。第一：先部門內部達成共識，再外部輸出給產品經理。可以降低溝通成本，減少無效溝通。第二：避免因為人員的需求描述和要求的標準不一致，導致需求的對接和落地出問題。
2. 產品經理固定時間接需求（需求討論會議）
固定時間（一個周期）的有組織的會議，取代隨時隨地單點溝通，提升溝通效率。在會議上進行需求討論。
產品經理需要準備這個周期內根據大家提交的業務需求模版整理的文檔。對應的參與人員要有業務方和產品。
3. 產品經理固定時間反饋需求
這個反饋需求是必不可少的，可以放在需求討論會后的幾天或者一周內。方式的話有多種可供選擇，如消息，郵件，亦或者是下一次的需求討論會上。
但是需要講清楚需求處在哪個階段。是否進入開發隊列，如果沒進入則講清楚原因，如果進入隊列還需要講清楚需求的排期和進度。此時對方有問題就可以單點進行溝通解決。
接業務需求流程（緊急需求）
一些非常緊急的需求，可能等不到常規需求設定的時間，就需要走另外一套流程。不過這套流程我建議少用，盡量保證常規流程的權威性。而且這種插隊需求也會影響原本的產品開發流程（研發大哥們可能會不開心）。雖然這種需求不可能完全避免，但是提高提這種需求的成本，能讓需求方更謹慎的動用這套流程。
處理方式：由需求方的固定需求對接人聯系部門直屬leader，再由有需求方直屬leader聯系產品部leader，最后決策這個需求的優先級。
當然，需求還是要符合上文中所說的提交標準的。一個再緊急的需求，也需要經過謹慎的思考。
就像一個患者肚子疼，來到醫院和醫生說快幫我把闌尾給切了，沒有任何一個醫生會不做檢查就動手術。我給大家分享一句話：“急事緩辦，緩事急辦”，希望和大家共勉。
最后說一下推動流程中的關鍵節點：
1. 首次共識流程：重點是流程的“統一”，不是一定要用“某種格式”。大家的共識是最重要的。不要固執己見的一定要某套流程，不同公司適用的場景也不一樣，所以作為產品經理要努力促進共識的產生。而且促進共識的產生也能最大程度確保流程執行時，大家都可以遵守。
2. 流程應用過程中產生問題：我們知道各種模板，規范和流程并不是與生俱來的，這些都是在需要的時候自然產生，和產品一樣，從簡單到全面。大家在過程里不斷完善。此時無需懷疑流程本身，根據反饋，具體分析后再迭代應用即可。
四、寫在最后
回想過去，在我入行最初的那一年，因為需求發生了太多的事情。
我有享受過需求滿足后各方的反饋，感覺世界因此變得更好。我也有討厭過那些徹夜難眠的思考需求的夜晚，恨方案一次次的被否定，陷入自我懷疑里。我相信大部分產品經理都曾經歷過或者正在經歷這個過程。
我現在回首再看過去的經歷，其實感慨萬千。走了太多彎路也踩過很多坑，抱著為了讓后來的朋友不再受困于當初我的窘境的想法，我寫下這篇文章，希望對你有所幫助。
同時也給大家分享幾點心得：
1. 我們產品經理的工作就是滿足需求。當自己遇到困境的時候，也要學會運用產品思維去思考自己面臨的問題，然后設法滿足這個需求。
比如在接業務需求這個場景中，既有痛點又高頻出現，就可以嘗試一些新的解決方案。我們產品經理有一項很重要的技能就是產品設計，設計是什么？維克托·帕巴奈克給出的回答是：為賦予有意義的秩序，付出有意識或直覺的努力。
設計產品是這樣，設計規則也是這樣，我們都要進行思考后賦予秩序，然后讓秩序提高我們效率。
2. 我們只能盡人事，即使你提前設定了完美的流程和方案，但是也有可能出現問題。要學會在反饋中前行，事物的發展都是螺旋上升的。建立認知，然后去實踐中獲得反饋，最后重建認知。
希望大家都能在產品工作中完成自我實現。
最后，大家一起加油！
本文由@趙青山 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
我見青山多嫵媚，料青山見我應如是。