理清需求，做好專案管理，產品開發不再是冤家

事情源於一個最佳化方案的實現。

（當時那把劍離我的喉嚨只有0.01公分，但是四分之一炷香之後，那把劍的開發將會徹底地信任我，因為我決定說一個謊話。雖然本人生平說過無數的謊話，但是這一個我認為是最完美的…）

“最後一次改需求。”

卒，全劇終。

一、ToB行業需求的特殊性

人們常說貓狗大戰，魚鳥大戰，星球大戰，但不知什麼時候開始，產品經理和開發成了一對冤家，路窄到約架脫口秀網際網路專場撕逼。外行看熱鬧，內行也看熱鬧，只有當事人拽緊拳頭咬著牙，在如今太平盛世，竭盡全力壓抑自己繪寫暴力美學的衝動。

究竟是什麼讓原本善良純真的雙方彼此成為了令人哭笑不得的歡喜冤家？

答案是需求。網際網路行業，需求真可謂無處不在。排除某些無理取鬧的要求，我們把所有對產品未來的美好期望統稱為需求。有所求，有所解，一個需求的生命週期裡，必然同時存在有需求方和解決者。

從事ToB行業，產品經理很容易被當作一個傳話筒，僅僅作為需求對接的管道，連溝通的橋樑都懶得搭建。沒有經過產品思考分析，直接把需求原材料扔給開發，註定是專案團隊的災難。

理清需求的前提，即雙方均得理解需求。ToB行業需求的特殊性主要體現在以下幾點：

1. 需求關係鏈比較複雜，需求被每個角色層層篩選或包裝

這個關係鏈有點類似供應鏈的上下游關係，按照需求的流向：客戶——>專案——>產品——>研發傳遞。

對於專案而言，客戶就是需求方，專案團隊就是解決者；對於產品而言，專案團隊就是需求方，產品團隊是解決者；對於研發而言，產品團隊是需求方，開發是解決者。需求就像水流一樣，每經過一個站點，其有可能被中途截斷，也可能分支細流，更可能被額外匯流。

開發總是吐槽產品需求多，但殊不知這條鏈路波濤洶湧而來的10個需求，產品已經砍掉5個，暫緩2個，剩下3個擇優選擇1個交給開發……如果此時沒有產品做一座捨身取義的大壩，其後果，開發可以透過小資料演算一下……

2. 需求可信度同樣有些複雜，每個角色對需求的優先順序和重視程度不同

當需求的河流流向最終的研發，途經的需求方沒有一個是無辜的。客戶有可能無心之說，專案有可能在添油加醋，產品經理需要根據目前客戶、專案、產品進展和研發資源的情況作出合理的需求分析，最後才能落實到開發實現。

判斷需求的真實訴求，才能找到需求方的核心想法。

客戶的有些需求可能聊著聊著就消失了，這種就屬於典型的“莫須有”需求；還有別看專案熱血沸騰地描述產品的偉大藍圖，但其需求的目的可能僅僅只是為了維護專案和客戶之間的友好關係；而作為產品的“親爹”，子不教，父之過，孩子有啥毛病家長最清楚，但一切問題的完善都需要時間，而開發資源的博弈抉擇問題一時半會是急不來的。

開發總是責怪產品需求多變，但需求的優先順序和重要性是跟隨著專案的進度走的。一般情況下，產品前期就已經把一切都規劃好，但如果客戶正常使用產品的過程都能碰見個bug，就不要怪這個bug缺陷為何成為重要又緊急的需求了吧。

3. 需求實現難度預估較為複雜，每個角色對需求的可行性評估不同

拋開“手寫一個百度”、“手寫一個淘寶”這種傻大粗門外漢的偽需求，ToB行業因為很多需求在確定做之前需要先給個預估結果，涉及到的知識可能深入系統底層，這時候產品需要開發以專家的角度進行需求的刨析並提供寶貴的建議。

需求實現難度預估分析，這點開發一定最有話語權，但不一定最有決策權。一旦開發掌握了需求的生死大權，那麼產品的需求就只有“做”和“做不了”這兩條道路，所以產品經理的可貴/可恨之處就在於從大局觀思考整個需求的存在主義，並指明瞭第三條路：“必須做”。

而每個“做不了”的需求，不是因為需求可行性就一定差，可能因為其他原因，比如排期來不及，人員突然請假缺失，需求的拆解不到位等。如果產品經理沒有一點自己的判斷力，那開發說做不了，這個需求就不做了，豈不如同尸位素餐。因此我更喜歡問清楚有關需求的問題，這時候只要不是濫竽充數的開發，都會盡心盡力為你解答。

這種現象也就是開發常說的“幫產品解決了問題，結果手裡剩一堆活”。但如果開發不答惑解疑，產品稀裡糊塗確定了需求，恐怕到時手裡就不僅僅是剩一堆活那麼簡單了。

我聽過開發對我說過最霸氣的話：“沒有什麼需求是做不了的，只要給足足夠的時間（和money）。”早已寫慣了業務的CRUD，也想挑戰一下自己能力的開發，需求可行性就是個偽命題。

但對於整個產品迭代週期，專案週期而已，需求可行性不僅僅是包括實現可行性，還包括時間可行性和成本可控性。因此產品需要更多維度的考慮問題，如果開發都能夠get到這些點，團隊的執行力勢如破竹。

二、如何把實現需求落實到整個研發團隊的專案管理中？

在理清楚了ToB需求的特殊性，以及掌握了和開發溝通需求的技巧之後，接下來就要思考如何把需求的實現落實到整個研發團隊的專案管理中。

目前我經手的專案研發模式比較特殊，介於敏捷開發和傳統瀑布之間，各有其長，同時也有其短。

存在即合理，任何公司的研發模式必然符合其公司的業務發展；也正如其公司的人員必然符合其公司的業務要求。所以我曾見過很多很美好很完善的產品培訓知識結構，但至於適不適合其從業的公司情況，恐怕就不得而知了。

我也曾有段時間也在努力探索追求產品行業的標準，但實踐才是檢驗真理的唯一標準，有時候研發的進度就是容不下你寫完一份標準的產品文件。

所以我現在很能夠理解很多同行人心中的那份焦慮：既感受不到行業頂尖大廠的標準化流程，有看不慣部分創業公司的所謂扁平化管理，而在自己的公司裡整天渾渾噩噩，迷茫痛苦。

我堅信一個最基本的經濟學道理：任何公司，都不會養一個沒有價值的員工。所以能夠找到一份工作並且做下去，就證明其實員工和公司雙方在現階段是合適的。而如果我們要追求更高的方向，就必須不斷提高自己，讓自己相容更強更好的公司的崗位要求，也就是在合適的時間，努力做一個合適的人，而非最優秀的人，這樣也許內心的痛苦掙扎就會少些。

話說回來，如何做好需求的專案管理，同樣因公司而異。我目前的產品工作模式，其實還是比較接近敏捷開發的Scrum模型。

透過JIRA這個專案與事物跟蹤工具，追蹤自己所提的每個需求。

一個需求單的結構體大致如下：

基本翻譯過來就是在什麼時間內，需要什麼人實現什麼樣的需求，並且記錄下來整個需求的生命週期。

而產品的專案管理能力不僅僅依賴工具的使用，而是對每個有明確deadline的需求進行有效的跟蹤，避免實現需求的開發誤入歧途。開發可能只負責需求的實現，但產品經理需要負責需求的驗收和交付，因為開發最後可以義正言辭的宣告：“需求我就是按照產品說的做的。”所以與其在最後關頭互相撕逼，不如在早期就把不穩定因素扼殺在搖籃裡。

（曾經有一份真實的需求放在我面前，我沒有珍惜，等我失去的時候我才後悔莫及，人世間最痛苦的事莫過於此。 如果上天能夠給我一個再來一次的機會，我會對那個開發說三個字：我懂你。 如果非要在這份責任上加上一個期限，我希望是……Deadline）

欲戴其冠，必承其重。戴上金箍兒，產品研發九九八十一難，其實，我們都是悟空……

作者：濤痕，公眾號：一兩語

本文由 @一兩語 原創於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議