需求是產品研發的起點。
需求的把控就像開車握著方向盤。可能只是偏離一個很小的角度，車行駛的軌跡便完全不同。
重要性
不知為什麼，大部分時候我們總是傾向忽略需求管理的重要性
因此我會老實地多寫一些字來強調這點。
我儘量用輕鬆的語氣聊這個話題，雖然這個話題沉重無比。
需求是產品不斷完善與進化的核心抓手。
我們的產品團隊，研發團隊，測試團隊,交付團隊，他們一個個都在圍繞需求，日以繼夜地工作，揮灑汗水，試圖把產品變得更完美。
大家如此努力，我們的產品真的有變得越來好了麼？
有沒有發現產品裡充斥一大堆沒幾個人用的玩具特性？
產品的各種功能彷彿一大坨狗皮膏藥層層疊疊地貼在一起，讓人望而生畏 。
沒有一個人說的清楚產品的完整的許可權體系，總有各種漏洞和分支情況。
經常碰到奇怪的小機關在不起眼的角落，過了一段時間沒有人知道這上千個開關都是做什麼用的。
研發變得越來越慢，技術小哥每做一個新功能都徒勞地想把牽扯到的幾十種場景梳理明白。最後決定推翻了重做。大量重構讓人身心俱疲。
一個按鈕是否顯示的判斷邏輯寫了十幾個條件，讓人眼花繚亂。即使是一個小修改，由於產品經理一時考慮不全相關聯的幾十個點，後期總有大量的【設計遺漏】型別的bug提上來。
哦！這簡直糟糕透頂！難道不是嗎！
我仔細思索了一番，我們時常選擇忽視需求管理，可能因為這實在是一件很難的事情。
我們需要有大智慧，大勇氣，大決斷，來做好需求管理。
需求管理在產品研發流程的最上游，因此每一個錯誤的決定，都會導致後續巨量，無效的研發成本投入，測試成本投入，修正成本投入，額外運維成本投入。殺傷力堪比原子彈。
很多人都瞭解【技術債】這個詞兒。由於初期用了不恰當的架構，導致後續所有研發都不那麼對勁，總是有著不可理喻的限制或者瓶頸。
類似的，如果忽略了需求管理，我們會慢慢背上【設計債】。
這種債更直觀，見效更快，效果更明顯，影響更廣泛。
當我們焦頭爛額，步履維艱的時候，看不下去的老闆可能終於有一天來問你
小馬，我如果給你2000萬，讓你再拉30個人，花一年時間把產品重做一遍，是不是能解決問題？
如果不清楚癥結所在，我相信你答不好老闆的這個問題。
你需要的角色
這個部分我們探討你需要哪些小夥伴來做好需求管理。
產品總監
產品總監的作用可能比我們想到的更廣泛，更具體，更具影響力。這絕對不是一個虛無縹緲的Title。
在產品型公司，產品總監就是公司的靈魂，是產品進化的舵手。除了清晰的思路，他需要像孩子一樣疼愛自己的產品，不停地思考如何才能把自己的孩子培養得更優秀。
這個職位的人需要有相當的決策權力，以保證其智慧，決斷，領袖氣質，能夠引領產品向著正確的方向行進。
最優秀的產品總監會爭取他所需要的決策權，為了讓產品符合自己的設想不擇手段。然而這樣的人真的可遇不可求。所以不是找到一個能力出眾的產品總監就結束了，一般情況下他需要充分的授權。
他的重要性
必不可少
他的工作內容
規劃產品邊界
產品是什麼？能做什麼？不能做什麼？ 成本是有限的，產品總監通過釐清產品邊界，幫助我們阻止成本浪費在無謂的特性上。再強調一遍，這裡的成本包括研發成本，測試成本，交付成本，運維成本等一系列巨量的下游成本，所以千萬別在產品設計環節省錢！
我講個故事大家都懂了。
有一個做考勤打卡產品的公司，他們有很多大客戶。
有一個客戶提出能不能幫忙管一下員工休假。
於是公司花了一個月完成了休假模組，員工可以在產品中提出休假申請，並進行主管審批。
過了一個月客戶提出不能做休假申請撤回，有時候員工不能按計劃休假，需要有個撤回休假申請按鈕。
又過了一個月，客戶再次提出員工休假需要有公司級別控制，需要在產品中完成員工休假計算模組，計算員工休假剩餘天數。
一切還沒結束。
沒過幾天客戶打電話來，員工休假資料沒有和薪酬系統打通，休假需要影響薪酬計算。
這個故事我還可以寫很長。
但是意思大家明白了吧？
假如我們的產品是一個完美的圓，當客戶要求邊界外的東西的時候，就相當於在這個圓上凸起一個【包】，我們的產品不圓了！不要存在僥倖心理，後面一系列壓力會讓我們把這個【包】周圍都補全了，變成一個更大的圓。
做這件事情有著我們很難預估的成本。當這個包不是我們產品應覆蓋的東西的時候，畫這個圓的成本就是不折不扣的浪費！
規劃產品進化方向
產品邊界並不是一成不變的，產品總監要有高屋建瓴的思路，要有對競品降維打擊的氣概和長遠規劃。沒有這個規劃，產品的生長就是無序且混亂的，必然導致多走很多彎路。
很經典的案例就是美團產品的進化擴張路程。
由最初的團購，到涉足外賣業務，到合併大眾點評，到現在的美團叫車。
一個產品體系中的產品互為倚重，相互引流。點評搜到飯店可以直接美團叫車過去，美團外賣會送叫車優惠券。這種產品體系的擴張方式體現了產品總監高超智慧。
參與需求總監評審
需求總監評審是產品總監控制產品發展的重要抓手。
總會有紛紛擾擾的需求不停地被提出，做還是不做？自己做還是用外部產品？自己做的話用什麼方式做？
產品總監需要清晰的思路和優秀的溝通能力，表述自己的觀點，說服需求提出者按照自己的意志來進行。
其他日常事務
包括招募團隊成員，協調分工等，在此就不細述了。
產品經理
產品經理要做的事情複雜而繁瑣。
你絕對不想讓什麼人來兼職這個角色。那未免太不人道了。
我們不妨先來看下產品經理的職責清單。
| 產品經理的職責 | 描述 |
|---|---|
| 競品調研 | 時刻保持對競爭對手的瞭解 |
| 客戶交流 | 瞭解使用者的感受 |
| 形成初步需求（產品故事） | 梳理產品需要哪些新特性 |
| 與產品總監一起完成總監評審 | 說服產品總監花成本做這件事情是有意義的 |
| 與其他模組產品經理完成需求概要傳遞，檢查模組間影響 | 可能需要其他模組的配合才能做好這件事情 |
| 與技術負責人一起完成技術評審 | 技術負責人會根據技術實現，提出一些自己的實現建議，這些建議十分重要 |
| 形成完整的需求文件 | 根據以上所有輸入，完成最終的詳細設計 |
| 與UX&UI團隊溝通，完成UX&UI設計 | 向UX和UI團隊講解所需實現的需求 |
| UX&UI驗收 | 保證UX和UI與自己的需求設計一致（這一點非常重要） |
| 與開發小組，包括測試團隊完成需求詳細傳遞 | 根據需求詳細設計，UX，UI，與開發團隊全員傳遞所有的需求細節 |
| 開發提測後，完成產品初期驗收，防止需求變形 | 為防止開發過程需求變形，產品經理需要在開發提測後，第一時間判斷實現是否大體滿足要求。不要在上線後採取看開發做的東西是否是自己想要的，那時候一切都來不及了。 |
| 需求上線後完成上線驗收 | 上線後檢查需求是否完整無誤。 |
| 上線後監控需求效果，進行後續調整 | 產品經理需要關心自己花了大量人力物力做出的特性用起來反饋如何 |
產品經理的工作貫穿了需求的整個生命週期，牽扯公司內公司外，部門內部門外形形色色的人群。
這絕對是一個高難度的職位！
鑑於產品經理的工作如此繁雜，有些公司會將這個角色拆分，多到可以拆分成4個：
| 角色 | 分工 |
|---|---|
| 運營經理 | 主要接觸終端使用者與市場部門 |
| 產品經理 | 主要完成產品故事相關的工作 |
| 需求分析師（BA） | 詳細的需求設計與實現方案 |
| 專案經理 | 監督研發上線進度，對需求保質保量按時落地負責 |
由於上述原因，招聘一個合格的產品經理也變得十分困難！
優秀的產品經理需要具有以下特質：
| 優秀產品經理的特質 | 描述 |
|---|---|
| 良好的溝通能力 | 他需要和形形色色的人溝通。表述和說服佔用了他很多時間。 |
| 良好的團隊合作能力 | 他需要和外圍團隊以及產品團隊內部的每個人維持友愛的關係，不然他的工作就會步步維艱，或者漏洞百出 |
| 良好的抽象能力 | 產品不是單純的特性堆積。每次一個新的需求出現，都是對現有產品體系的挑戰。產品經理需要思考為什麼產品架構無法輕易地實現這個新出現的需求，形成架構層次的實現方案。否則產品就變成了一堆膏藥貼在一起的醜東西。 |
| 高要求 | 對自己要求低的產品經理，對產品的要求也不會高。他的輸出的東西也會讓人痛苦。不要讓這樣的人留在產品團隊。鑑於產品經理的重要性，他將成為我們的木桶的最短板。 |
| 熟悉產品 | 這是一切的基礎，我碰到過經常想不起來產品有什麼功能而去問研發和測試的產品經理。那真是一個噩夢。 |
需求生命週期
好吧，我們千辛萬苦找到了牛逼的產品總監，湊齊了優秀的產品經理，來了解下需求的生命週期。
我們不想漏掉以下任何一個關鍵步驟，那會讓我們產品團隊的能力大打折扣。
產品總監評審
前面多次提到這個過程。這個環節保證研發的工作基礎是有意義的，是有益於產品的。
這個過程的缺失，會導致產品走大量彎路，產品總監的思路和構想將難以落地，其價值也難以體現。
產品經理內部需求概要傳遞
當產品總監認可一個需求項後，需要在各個模組的產品經理傳遞需求概要。這個步驟保障需求在落地過程中可以獲取到各個模組的支援和幫助。
這個過程的缺失將可能引起模組間配合遺漏，導致有缺陷特性產生。
技術經理評審
產品經理與模組技術負責人完成技術經理評審。
技術經理從技術架構的角度分析需求，給出實現建議。在這個過程中，產品經理將得到技術負責人的幫助，完善需求的實現方案，並根據技術負責人的成本評估對一些特性做出取捨。否則有些錦上添花的次要特性會佔據研發的一半以上時間。
需求文件編寫
當接收了產品總監，各個模組的產品經理，以及技術負責人的建議與祝福後，產品經理現在可以綜合考慮前面的輸入，完成最終的需求設計。這是產品經理的最重要的輸出之一，體現了產品經理的綜合水準。
值得注意的是，需求詳細設計並不是只為了指導研發完成需求落地，它還是產品邏輯的文件體現，為後期知識傳遞以及未來邏輯追查留下的重要文獻資料。
UX和UI的評審
產品經理需要驗收需求的UX以及UI。很多需求變形都是從這一步驟開始的。UX組對需求的理解不透徹，導致UX圖就有問題。UX作為研發團隊的重要輸入，將為研發團隊提供錯誤的指導。最終做出的特性也會和產品經理的想法大相徑庭。
需求宣講
當一切準備就緒，產品經理需要向研發團隊（包括測試組）宣講完整的需求，包括每一個細節。工具就是需求詳細設計，UX&UI。
技術經理將拆解需求到任務，編制研發計劃，準備開展研發工作。 測試組也將根據這次宣講的內容，以及需求詳細設計，完成測試用例的編寫。
這一個步驟還是在避免理解差異，導致需求變形。
研發實現
這是個很容易理解的過程，也是個複雜的過程。我需要一個專門的部分來說明這個步驟，這裡就不細述了。
預驗收
當研發提測後，產品經理需要在測試環境再次確認需求是按照設定的方式實現。我們不能等到需求上線後再做這件事情，畢竟那時候一切都晚了。
上線後需求的迴歸評審
需求終於上線了。
等等，需求生命週期還有一個步驟。就是這裡提到的迴歸評審。
需求是否達到了我們預期的效果，如果沒有達到，我們還需要做哪些調整，我們要接受哪些教訓，學到了哪些東西。這些都是需求生命週期中，給我們（產品團隊）的最寶貴的財富。
沒有反思，就不會進步。這個過程會讓產品經理的思路得到昇華，也就使得未來產品走的彎路更少。
問題與應對
產品中最重要的部分
產品中最重要的部分，是產品的基礎架構。
包括登入模組，人員組織結構，許可權結構，系統字典，配置模組等等。這些基礎的東西不好用，會導致產品的根基不穩，而所有的需求都是在這個根基上生長而出的。
當未來發現這些根基上的裂縫，再想要彌補的時候，仰頭一看，我們會發現根基的裂縫已經遍佈所有上層架構。彌補的成本可想而知。
我們需要思路最縝密，條理最清晰的產品經理負責產品的基礎架構。
這些模組雖然簡單並且有例可循，但千萬不要輕視。輕視他們就是心存僥倖，就是玩火。
千萬。
不要玩火。
這是一個有價值的需求嗎？
對於產品而言，什麼最重要？這是一個首先要回答的問題。
每個產品的答案可能不一樣。舉個例子。
如果流量對於產品最重要，那麼這個待評估的需求可以貢獻多少流量，使用人數佔基數的百分之多少，或者對留存率提升多少？
這些問題搞清楚了，需求的價值就不難估算了。
價值不高的需求首先儘量不要去做。甄別這些低價值需求是產品總監的分內之事。至於如何將這些來自老闆，來自重要客戶，來自心愛的產品經理的低價值需求擋掉的技巧，也是產品總監的必修課。
如果各種壓力導致我們不得不完成一個沒什麼人用的特性怎麼辦呢？
用盡可能少的成本做這件事。不要過度考慮互動！不要過度考慮穩定性！不要過度考慮例外情況！
時刻牢記，這個需求對你的產品不重要。每多一個研發人天的成本都是不值得的！
然後，把這個不得不實現的低價值需求記在一個小本子裡，它是產品的瑕疵。未來一旦有機會，就立刻把它拿掉！
是的，只要需求上線後，發現確實沒什麼用，就把邏輯刪掉。
產品要做加法，也要做減法。保證我們的產品時刻保持在健康狀態，我們需要修剪一些額外的枝葉，這是我們不能忘記做的事情。
協作的問題
當產品越來越複雜，一個產品經理已經忙不過來的時候，我們開始拆分模組，將不同模組分配給不同的產品經理負責。
這麼做無可厚非。但是一定要小心初期的混亂。
除非模組可以劃分的十分清楚，否則要想好對策，規避模糊地帶。
要知道，模糊地帶可能會變成沒人管的區域。這些無人管理的地帶會讓研發團隊不知所措。會導致大量設計缺陷類的問題出現。
各個模組的產品經理需要互相協作，共同加強模糊地帶的管理。
這是一個巨型需求
哇塞，我設計了一個巨型需求，它是如此的壯觀，如此的巨集大！它是一個史詩級的使用者故事！它大到需要所有模組的研發團隊整個迭代任何其他的事情都不能做。
小心這樣的巨型需求。它是不受歡迎的，因為大部分時候，各個團隊在迭代中都有些其他必須要做的事情。
結果就是，這個巨型需求無法放進任何一個迭代中。拖了半年之後，你發現系統已經和半年前完全不同，這個巨型需求的詳細設計也不再適用。
很可惜，不是麼？
正確的做法是，你需要嘗試把巨型需求拆分，拆分成一個個可以獨立上線的階段。每個迭代塞進去一點。慢慢編織你的巨集偉的史詩故事。
這不是我要的東西
前面需求管理生命週期中，很多過程都是為了避免需求走形而設定的。沒有什麼比漫長的等待後，發現研發給出的東西面目全非，更讓人沮喪的了。
在完成需求宣講後，產品經理需要在各個節點，勤快地跟進研發成果。否則就難免沮喪了。
小結
- 重視需求管理環節，否則後期將產生大量成本浪費
- 找到符合產品的【需求價值衡量標準】。儘量摒棄價值不高的需求。
- 做好產品的邊界管理。
- 產品的基礎架構一定要做好，這是根基所在。
- 注重各個模組間產品經理的協作。
- 小心巨型需求
- 參與各個環節，防止需求變形