起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識理清需求，做好項目管理，產品開發不再是冤家
編輯導讀：產品經理的日常主要工作就是與需求打交道，如何能夠快速準確地厘清產品需求，讓功能直擊用戶痛點是很多產品經理的愿望。對于ToB行業產品來說，由于和C端產品的差異性較大，需求需要根據其特殊性進行管理。本文作者對ToB行業需求的特點進行了梳理分析，對具體的需求落實展開了討論，供大家一同參考學習。
事情源于一個優化方案的實現。
（當時那把劍離我的喉嚨只有0.01公分，但是四分之一炷香之后，那把劍的開發將會徹底地信任我，因為我決定說一個謊話。雖然本人生平說過無數的謊話，但是這一個我認為是最完美的…）
“最后一次改需求?！?/p>
卒，全劇終。
一、ToB行業需求的特殊性
人們常說貓狗大戰，魚鳥大戰，星球大戰，但不知什么時候開始，產品經理和開發成了一對冤家，路窄到約架脫口秀互聯網專場撕逼。外行看熱鬧，內行也看熱鬧，只有當事人拽緊拳頭咬著牙，在如今太平盛世，竭盡全力壓抑自己繪寫暴力美學的沖動。
究竟是什么讓原本善良純真的雙方彼此成為了令人哭笑不得的歡喜冤家？
答案是需求?；ヂ摼W行業，需求真可謂無處不在。排除某些無理取鬧的要求，我們把所有對產品未來的美好期望統稱為需求。有所求，有所解，一個需求的生命周期里，必然同時存在有需求方和解決者。
從事ToB行業，產品經理很容易被當作一個傳話筒，僅僅作為需求對接的管道，連溝通的橋梁都懶得搭建。沒有經過產品思考分析，直接把需求原材料扔給開發，注定是項目團隊的災難。
理清需求的前提，即雙方均得理解需求。ToB行業需求的特殊性主要體現在以下幾點：
1. 需求關系鏈比較復雜，需求被每個角色層層篩選或包裝
這個關系鏈有點類似供應鏈的上下游關系，按照需求的流向：客戶——>項目——>產品——>研發傳遞。
對于項目而言，客戶就是需求方，項目團隊就是解決者；對于產品而言，項目團隊就是需求方，產品團隊是解決者；對于研發而言，產品團隊是需求方，開發是解決者。需求就像水流一樣，每經過一個站點，其有可能被中途截斷，也可能分支細流，更可能被額外匯流。
開發總是吐槽產品需求多，但殊不知這條鏈路波濤洶涌而來的10個需求，產品已經砍掉5個，暫緩2個，剩下3個擇優選擇1個交給開發……如果此時沒有產品做一座舍身取義的大壩，其后果，開發可以通過小數據演算一下……
2. 需求可信度同樣有些復雜，每個角色對需求的優先級和重視程度不同
當需求的河流流向最終的研發，途經的需求方沒有一個是無辜的?？蛻粲锌赡軣o心之說，項目有可能在添油加醋，產品經理需要根據目前客戶、項目、產品進展和研發資源的情況作出合理的需求分析，最后才能落實到開發實現。
判斷需求的真實訴求，才能找到需求方的核心想法。
客戶的有些需求可能聊著聊著就消失了，這種就屬于典型的“莫須有”需求；還有別看項目熱血沸騰地描述產品的偉大藍圖，但其需求的目的可能僅僅只是為了維護項目和客戶之間的友好關系；而作為產品的“親爹”，子不教，父之過，孩子有啥毛病家長最清楚，但一切問題的完善都需要時間，而開發資源的博弈抉擇問題一時半會是急不來的。
開發總是責怪產品需求多變，但需求的優先級和重要性是跟隨著項目的進度走的。一般情況下，產品前期就已經把一切都規劃好，但如果客戶正常使用產品的過程都能碰見個bug，就不要怪這個bug缺陷為何成為重要又緊急的需求了吧。
3. 需求實現難度預估較為復雜，每個角色對需求的可行性評估不同
拋開“手寫一個百度”、“手寫一個淘寶”這種傻大粗門外漢的偽需求，ToB行業因為很多需求在確定做之前需要先給個預估結果，涉及到的知識可能深入系統底層，這時候產品需要開發以專家的角度進行需求的刨析并提供寶貴的建議。
需求實現難度預估分析，這點開發一定最有話語權，但不一定最有決策權。一旦開發掌握了需求的生死大權，那么產品的需求就只有“做”和“做不了”這兩條道路，所以產品經理的可貴/可恨之處就在于從大局觀思考整個需求的存在主義，并指明了第三條路：“必須做”。
而每個“做不了”的需求，不是因為需求可行性就一定差，可能因為其他原因，比如排期來不及，人員突然請假缺失，需求的拆解不到位等。如果產品經理沒有一點自己的判斷力，那開發說做不了，這個需求就不做了，豈不如同尸位素餐。因此我更喜歡問清楚有關需求的問題，這時候只要不是濫竽充數的開發，都會盡心盡力為你解答。
這種現象也就是開發常說的“幫產品解決了問題，結果手里剩一堆活”。但如果開發不答惑解疑，產品稀里糊涂確定了需求，恐怕到時手里就不僅僅是剩一堆活那么簡單了。
我聽過開發對我說過最霸氣的話：“沒有什么需求是做不了的，只要給足足夠的時間（和money）?！痹缫褜憫T了業務的CRUD，也想挑戰一下自己能力的開發，需求可行性就是個偽命題。
但對于整個產品迭代周期，項目周期而已，需求可行性不僅僅是包括實現可行性，還包括時間可行性和成本可控性。因此產品需要更多維度的考慮問題，如果開發都能夠get到這些點，團隊的執行力勢如破竹。
二、如何把實現需求落實到整個研發團隊的項目管理中？
在理清楚了ToB需求的特殊性，以及掌握了和開發溝通需求的技巧之后，接下來就要思考如何把需求的實現落實到整個研發團隊的項目管理中。
目前我經手的項目研發模式比較特殊，介于敏捷開發和傳統瀑布之間，各有其長，同時也有其短。
存在即合理，任何公司的研發模式必然符合其公司的業務發展；也正如其公司的人員必然符合其公司的業務要求。所以我曾見過很多很美好很完善的產品培訓知識結構，但至于適不適合其從業的公司情況，恐怕就不得而知了。
我也曾有段時間也在努力探索追求產品行業的標準，但實踐才是檢驗真理的唯一標準，有時候研發的進度就是容不下你寫完一份標準的產品文檔。
所以我現在很能夠理解很多同行人心中的那份焦慮：既感受不到行業頂尖大廠的標準化流程，有看不慣部分創業公司的所謂扁平化管理，而在自己的公司里整天渾渾噩噩，迷茫痛苦。
我堅信一個最基本的經濟學道理：任何公司，都不會養一個沒有價值的員工。所以能夠找到一份工作并且做下去，就證明其實員工和公司雙方在現階段是合適的。而如果我們要追求更高的方向，就必須不斷提高自己，讓自己兼容更強更好的公司的崗位要求，也就是在合適的時間，努力做一個合適的人，而非最優秀的人，這樣也許內心的痛苦掙扎就會少些。
話說回來，如何做好需求的項目管理，同樣因公司而異。我目前的產品工作模式，其實還是比較接近敏捷開發的Scrum模型。
通過JIRA這個項目與事物跟蹤工具，追蹤自己所提的每個需求。
一個需求單的結構體大致如下：
需求名稱：【產品】XX需求
需求類型：故事/任務/缺陷
需求描述：
（1）問題/需求：簡單描述產品的問題/升級點。
（2）實現目標：詳細描述該需求最后完成的結果。
（3）（問題分析）：產品如果知道問題所在，可以寫下自己的分析，僅供開發參考。
（4）圖+文字說明
需求執行者：某開發/測試
需求Sprint：XX
備注：……
基本翻譯過來就是在什么時間內，需要什么人實現什么樣的需求，并且記錄下來整個需求的生命周期。
而產品的項目管理能力不僅僅依賴工具的使用，而是對每個有明確deadline的需求進行有效的跟蹤，避免實現需求的開發誤入歧途。開發可能只負責需求的實現，但產品經理需要負責需求的驗收和交付，因為開發最后可以義正言辭的聲明：“需求我就是按照產品說的做的?！彼耘c其在最后關頭互相撕逼，不如在早期就把不穩定因素扼殺在搖籃里。
（曾經有一份真實的需求放在我面前，我沒有珍惜，等我失去的時候我才后悔莫及，人世間最痛苦的事莫過于此。 如果上天能夠給我一個再來一次的機會，我會對那個開發說三個字：我懂你。 如果非要在這份責任上加上一個期限，我希望是……Deadline）
欲戴其冠，必承其重。戴上金箍兒，產品研發九九八十一難，其實，我們都是悟空……
作者：濤痕，公眾號：一兩語
本文由 @濤痕 原創于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
泛泛而談
拋磚引玉