本篇重點向產品上游（多指代運營同學）如何優雅的向產品團隊提需求。我們知道需求描述越精準、需求的邏輯層次越分明、需求的上下文等關聯考慮越到位，這份需求的可評估性越高、下游接盤者不遺漏考慮的風險越小、落地執行的效率也是最高的。

本篇重點向產品上游（多指代運營同學）如何優雅的向產品團隊提需求。我們知道需求描述越精準、需求的邏輯層次越分明、需求的上下文等關聯考慮越到位，這份需求的可評估性越高、下游接盤者不遺漏考慮的風險越小、落地執行的效率也是最高的。

最重要的是，能提優質需求的同學也是團隊中最優秀的parnter，我們經常講團隊協作，其實“富有同理心，不對下游挖坑，交付產物質量高”是最大誠意的團隊協作，您說是么？

除此之外，產品、研發同學對運營需求的“熱愛度不夠”與“平臺的發展一定繞不開出色的運營”之間的矛盾，希望通過此次分享，將供需雙方拉到一起，統一共識，明確角色邊界，促進良性協作，將矛盾在萌芽狀態提前化解調，做到產品運營是一家O(∩_∩)O哈哈~

閱讀對象：運營同學、產品同學；

第一講：需求之坑：產品與運營的愛恨情仇

故事1：開始機械傳達領導的指示、中途綁架領導墊背、結果烏煙瘴氣

視覺稿設計完，需求方沒有領導發話不確認，前端干完了要大改，前端工程師吐血，下游測試檔期錯亂~

1. 小張，盡快確認~
2. 小張，盡快確認~
3. 小張，我在等領導的信（兄弟，你在綁架領導）~

結論及危害：提需求者機械的傳遞領導交辦的任務，自己不下功夫調研、思考、梳理需求或淺嘗輒止的蜻蜓點水，把自己也當領導以“任務式”或“簡陋表面描述式”向下游提需求。

除此之外，面對下游對某些細節的確認或產物的確認時，把領導拉出來當擋箭牌，直接綁架領導。

由此可見，此類員工看似好人一個，實則危害極大，是團隊中最大的敗類，如有可能，應立刻“斬立決”，從團隊中清除。

備注：上面的場景多指不專業的運營同學，不少產品同學有時候也容易機械的執行需求。如果把上述運營同學和產品同學放在某個需求開發中，后果可堪設想——“四不像需求”+“雞肋功能”+“團隊裂痕”+“士氣受挫”。

故事2：只管張嘴要、其它都不管了

活動已上線，APP的logo閃屏活動頁未替換，還是上個活動的。

1. 需求方自己不用，提的需求是“崗位應酬”，所有工作都依賴“產品-研發-測試-客服”保姆式服務；
2. 產品和測試組沒有作業list，靠經驗和記性，想到哪算哪，導致最后兩環的防線未防住。

結論及危害：產生這種結果一般有如下幾個原因：

• 其一：時差原因，項目交付距離提需求日已過去一周或更長，需求方對當前交付需求的重視程度（考慮細節）降低了（容易忘考慮）；
• 其二：前送后緊、前期很重視，后面用時放松了；
• 其三：思維懶惰，以為需求上線后就完事大吉，而忘記運營需求會伴隨很多運營的運營配置工作在其中；
• 其四：團隊真空，產品同學和運營同學相互指望對方或者產品未盡培訓提醒之責任或者運營團隊缺乏基本的作業流程（上線前相關配置項要統一發布）。

其危害是“平臺烏龍”被用戶、被客服、被老板diss整個團隊。

故事3：錯把自己當領導 or 業余外行

某天運營說領導讓上個邀請撒錢活動，該活動需要在幾號前完成，活動的頁面長這個樣子。產品經理蒙圈了，你這需求完了？？？下面這些東西是我自己拍板后，和你或者你的領導想的不一樣，咋辦？

（1）登錄、未登錄場景？

（2）薅羊毛防刷策略？

（3）相關業務場景的入口設在哪里？

• 入口1（發起方）
• 入口2（查看方）
• 入口3（賬戶中心）
• 入口4（管理方）
• 入口5：通知
• 入口6：客服
• 入口7：運營公告
• 入口8：現有活動是否沖突
• 入口9：老活動安排下線
• 入口10：渠道合作是否影響
• 入口11（追蹤）

結論及危害：和上面故事一多少有些相似，但和故事一有本質不同，故事一是“他懂+他偷懶+他怕擔責”；故事二是“他外行或把自己當領導了”。

這里的場景多是極其復雜的業務需求，提需求者多是外行，朋友圈或某個競品看到個活動頁，就誤以為很簡單，咱們也馬上搞一個。其危害是容易造成團隊裂痕，產品團隊給出的工期評估與之相差甚遠，自己以為產品團隊在忽悠或放水，久而久之會產生裂痕。

正向想，逆向想、框架想、現有想、執行想、反饋想，想清楚再提

相信產品同學在日常生活中都會經常遇到上述幾個場景，故事場景中運營有時候是運營，有時候就是產品自己。

這些低質挖坑需求一般都難逃如下幾個：

1. 職業外行，且不下功夫提升自己；
2. 職業內行，你說的都知道，就是習慣性偷懶；
3. 習慣把自己當領導，習慣用任務的方式提需求；
4. 只管生孩子（提需求），不管養孩子（把運營配置等活也指望產品或技術團隊都包了，提需求就像每月例行過度，走個郵件而已）。

第二講：正確的認識需求

1. 什么是需求

在軟件研發領域，需求可以用“3+1”分層講解：

1. 目標需求：提出一個目標，給一個指導原則（可有可無），適用對象：業務領導；
2. 業務需求：針對上述目標在業務上需要考慮的方方面面，適用對象：運營人員、某某業務崗（如財務、如風控）；
3. 運營策劃（運營場景）：設計運營業務流及活動方案；
4. 產品需求：將上述1、3轉化為產品需求，邏輯需求，輸出給研發，并基于“有限的研發資源”、“確定的時間邊界”在業務需求方、研發可實現能力、必要的迭代擴展能力三個維度給出專家決策意見。

各種需求的適用場景說明示例：

1. 能不能做一個***， 這是探討，探討后形成思路……
2. 你們做個***，這是boss的特權，不適用與職能崗……
3. 咱們要實現這個活動，大概需要多少工作量，這是預溝通，為了進一步詳細提需求做準備……
4. 我這個著急，很急？事故前提下優先處理，否則你的很急耍了別人的正常渠道的需求（火車站排隊）……
5. 我的需求方案已整理（流程圖、頁面圖、文案說明、關聯影像、特殊說明、優先級、上線時間等等），你看下還有哪些忘記考慮~ 這個需求不錯，兄弟，相見恨晚，產品同學最喜歡和你這種需求爸爸打交道了~

實戰復盤：

實際上，優秀的隊友無論出處，即便不是IT行業從業者，你嚴謹的做事風格也值得IT從業者敬重！譬如下面兩個case分別是來自“某從業多年的運營同學”與“某風控同學”，我們可以清晰的看出兩個需求的差距——其對下游的“內耗溝通”或者底層對應的“企業成本浪費”有時候很驚人，所以我前面提到，對“低質需求”是團隊的攪屎棍，是企業成本的第一個隱形殺手。

低質需求case：依貓畫虎、粗制濫造。

高質需求case：目標明確-思路清晰-考慮全面-方案合理-同理心。

這是一份非互聯網行業的需求說明，但當事人很用心，遠超過從業多年的運營同學或者不少產品同學。這份需求除了有郵件的詳盡說明外，還附帶著臺下大量的調研、溝通和攢局討論。

當事人除了很下功夫投入外，其工作方法也很專業，更值得我們致敬，我們將其解構，細細品味如下：

表達背景：根據合規報送承諾提取需求；

1. 前置溝通：找產品溝通實時細節；
2. 課下功夫：制定需求方案；
3. 文字功夫：詳盡分明、邏輯嚴謹；
4. 澄清需求：組織發起討論；
5. 窮追猛打：修改優化；
6. 鎖定預期：研發排期；
7. 閉環習慣：上線驗收（備注：如下截圖無法體現此工作）；

Demo期的產品或者說產品體系內的原生需求，溝通鏈條短或者說產品內部溝通即可，考驗的是產品經理自身的知識素養、執業能力、和業務的系統理解。

運營類的需求，溝通鏈條長或者說存在交叉部分，如果考慮缺失較多，產品過多代勞會導致極大的溝通內耗和效率風險（立場不同、經驗不同、思路就會差異）、工作邊界模糊（相互指望的考慮真空）。

2. 要什么 VS 怎么做

活動類的更多是要什么? 所以運營的重心在活動類需求。

換句話說，運營類的需求需要有運營同學主控，其不光需在大的運營訴求、策略設計、流程設計方面下下功夫，還需在入口設計、文案設計、數據統計、業務閉環等方方面面都要系統考慮。如果只是以老板自居，簡單粗暴的參考同行的幾個界面就當以為自己可干運營了，會褻瀆運營崗位的神圣性和嚴肅性，會對團隊生態造成嚴重的內耗，也會讓運營策劃活動流于形式而非最核心的一擊必中的“效果”訴求。

功能類的更多設計怎么做？ 所以產品的重心在功能類需求。

功能類的需求當有產品經理扛起大旗，哪怕是運營類的需求也應當有產品經理負全責，譬如運營紅包發布工具、運營活動管理發布工具、運營數據統計分析工具、運營廣告位投放工具等，這些都需要產品經理與使用人員（運營、財務等）充分溝通，挖掘需求背后的訴求，解構重構需求，形成自己的產品思路、并充分調研同行的最新解決方案及實現方式，結合自己團隊的資源情況和產品建設現況，給出相對最優的需求實現方案。

3. 不確定帶來的痛苦

人世間最大的痛苦之一是“不確定”+“猜測推斷”+“出事連坐”帶來的害怕參與。所以，一場優雅的需求，首要是“澄清需求”，需求不澄清，后面會出大事。需求澄清了，能否實現就是團隊能力和時間設定的問題了。

第三講：如何組織一場優雅的需求

1. 醞釀需求：需求前奏-做什么？

第一步：思考為什么要做？

第二步：業務場景（涉及節點、涉及角色）是什么？

第三步：預期攻擊目標是啥？

第四步：現有基礎都有啥？

第五步：怎么做，初步思路：找本部門、領導、產品 溝通可行性；

第六步：有沒有更好的攻擊方案？同行都怎么用？他們這樣做是否有特殊的背景？歷史上我們是怎么做的？

第七步：成本代價預估；

第八步：內部是否達成共識了？

第九步：內部過會論證可行性、形成共識：優先級、時間點；

方式：走路帶風的口頭溝通+敏捷速決的共識小會；

2. 發起需求：需求設計-怎么做？

第一步：撰寫需求文檔；

第二步：自查需求文檔；

第三步：內部過會；

第四步：提交給外部執行；

方式：嚴謹文檔+郵件召會+共識小會

3. 受理需求：產品組-做研發第2道干擾攔截

第一步：需求了解；

第二步：參與需求評審；

第三步：細節確認；

第四步：實現策略層設計、排期統籌、資源組織； 不可能三角概念；

第五步：前置研發資源協調、前置工作準備；

第六步：排期準備：產品排期、視覺排期、測試排期；

方式：嚴謹文檔+郵件召會+共識小會

4. 啟動需求：產品-視覺-技術

第一步：產品設計（如需產品崗介入：如底層邏輯、整體合并考慮、項目綜合推進等）；

第二步：需求方溝通及細節確認；

第三步：需求評審、需求立項；

方式：嚴謹文檔+郵件召會+共識大會

關于此模塊，我在“產品從業干貨-基礎技能篇：如何優雅的駕馭需求？”一文中有更系統的講解和實力說明，此處不再累述，產品從業者有必要閱讀一下。

5. 運營輸出：注意事項

1. 競品調研及結論輸出（如需要）；
2. 現有的數據分析及本需求的價值（如需要）；
3. 業務流設計；
4. 頁面標題；
5. 頁面內容、含交互；
6. 視覺傳達重點訴求；
7. 短信及APP推送配套（如需要）；
8. Banner配套（如需要）；
9. 分享節點（如需要）；
10. 老活動銜接連貫配套（如需要）；
11. 公眾號文章配套（如需要）；
12. 關聯影響及注意事項；
13. 數據初始化說明等（如榜單干預等）；
14. 客服前置培訓配套及值班匹配配套（如需要）；
15. 資產供標配套（如需要）；
16. 上線時間節點；
17. 流量監控（如需要）；

6. 視覺輸出：注意事項

1. 需求解構、交互稿解構；
2. 整體考慮：活動周期、研發工期、研發資源
3. 技術實現成本；
4. 字體運用；
5. 圖片大??；
6. 移動端效果；
7. 稿件移交方式；
8. 需求自查；
9. 需求方驗收確認。

7. 產品輸出：注意事項

方案具備擴展性；

文檔不給研發、測試挖坑。

8. 研發輸出：注意事項

略

9. 測試輸出：注意事項

一個原則：用戶發現的非極端場景遇到的問題測試組未發現都是測試組失職的問題。

10.?不同的需求 不同的處置流程

數據類需求：

1. 先看后臺能否交差組合出；
2. 簡易需求 直接對接DBA；
3. 必要的升級為【功能】——數據中心 通過“京滬高鐵”模式在6月份之前分批建成。

數據需求樣例：

為配合運營活動，需要調取2019年1月份房寶貸出借人回款明細。

表頭如下：

數據需求應答樣例：

受理人收到郵件后直接給需求人進行郵件反饋：

1. 收到，立即處理，預計***點完成；
2. 收到，忙完**處理，預計**點完成。

Ps：如未反饋，直接當面找上述兩位看郵件并口頭溝通交付情況。

活動類需求：

1. 運營直接與視覺對接、驗收視覺產物；
2. 產品參與實現方案支持、項目組織交付。

功能類需求：

1. 各需求方提需求；
2. 產品組采集需求后，全包設計；
3. 需求設計完后與需求方確認需求是否 滿足預期指標；
4. 確認無誤后啟動研發。

故障類需求：

1. P1類：研發立即解決，不解決不下火線（吃飯睡覺都讓路）；
2. P2類：產品納入需求池，統籌排期。

口頭應急類需求：

1. 需求方有限度的、處于用戶體驗和業務安全考慮的；
2. BoSS交辦緊急的；
3. 商務需要緊急的。

第四講：工具裝備

武器1：自己走一圈（案例略）

武器2：思考一圈

武器3：競品捋一捋

武器3：百度搜一搜

武器5：紙和筆畫一畫

武器6：Excel+Visio+RP

武器7：郵件+口頭+釘釘+評審會

武器8：自己嘗試走一走

結語

1. 當成自己的事，如無必要，勿增實體；如有必要，要做到極致；如未極致，也不能失格；
2. 如果搞砸了，這個事除了浪費成本外，更浪費時間窗口和 參與者內心受傷；
3. 流程走一走，順一順：自左向右，自上向下復查。

作者：九天牧人，個人微信unifarm

本文由 @九天牧人 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議