B端產品從需求調研到產品上線，需要經歷一系列流程。那么，為了推進產品進度，我們需要做一些風險管理。作者結合自己的項目，總結產品線流程中，如何進行風險管理以及相關應對措施，希望對你有所幫助。

B端產品從需求調研、產品設計、開發、上線、推廣培訓等環節中，除了推進產品進度，風險管理也至關重要，稍有不慎，就會影響項目進度。那么如何識別風險？風險出現的概率如何評估？如有風險則如何應對？解決方案可以提前構思嗎？等等有關風險問題，都需要產品經理在跟進產品全流程環節中，反復想清楚，才能確保產品保質保量上線。

筆者剛從事產品工作時，作為產品助理，主要是跟著產品經理進行原型設計，當時比較關注的是產品流程執行方面工作，如頁面功能設計、PRD的編寫、上線前的測試、上線后的推廣培訓工作，并未關注到風險方面。

后面獨立負責單獨的產品和產品線以后，發現，底層的執行方面工作其實是最固定的，風險也是最低的，因為確定性比較高，方向定了干就完了。而挖掘需求、產品方向、資源協調等大方面事宜，不確定性很高，風險也比較大，所以就需要有意識投入更多精力關注到風險這條線，與產品流程線并行，才能保證產品穩步進行。

筆者負責的幾個項目中，有過好成績，也有過生產事故，血的教訓，讓我對風險管理逐步建立起完整方法論。風險本質上是實際結果和預期未完全匹配，遭到客戶或用戶等相關方的投訴，例如用戶投訴你設計的產品特別難用，找不到想要的按鈕?；蚴钱a品運行中出現數據紕漏，導致業務無法在規定時間完成工作等，都屬于風險事故。

風險管理，其實就是有限的時間和資源下，管理未來目標的實現和相關用戶的期望值不出現巨大偏差，就需要在必要節點與相關方充分溝通，方案設計也不能太滿，要留有一定容錯空間，與用戶溝通也是如此，話不說滿，留有余地，比如上線時間需充分評估不能太緊。

所以說產品經理要了解心理學，就是需要洞察一些人性規律。比如期望如果很高，實際達不到，則大概率是失望的，但是期望如果低一些，實際容易達到，那么大概率就是驚喜。

還有，和各類相關方溝通時，尤其是B端涉及業務流程改造改革方面，用戶投訴產品不好用，不代表著真不好用，可能本質原因是他們不想更換工作流程，因為學習成本較高，或是銷售為了隱藏業績沒有實際錄入系統等等，所以業務里面的可說部分也許是水平面的冰山一角，很多業務也需在水面下面，需要產品經理潛心挖掘。

下面就從幾方面，總結下產品線流程中，并行的風險這條線，如何進行風險管理，以及相關應對措施。

一、需求調研階段

此階段的風險最主要是需求判斷失誤，不滿足用戶或相關方的業務痛點。

這里需要解釋下，B端產品的成功不僅只是滿足使用者（即用戶）的需求，還需滿足相關方（如直屬業務sponsor、上下游業務關聯方等）的需求。一般用戶屬于執行者，注重業務流程上的一個操作點，并不能全流程串聯起來。而項目相關方，一般是項目的發起人，B端產品基本就是業務領導，站在公司降本增效角度，全流程的進行業務改造。而信息化產品就是最有利的抓手，可以更快實現降本增效目標。

所以此階段，不僅要和用戶聊、也要與業務領導層充分溝通，目標、方向的確認也是基于業務領導層對工作的規劃，具體方案如何實現就需要和用戶充分溝通。當然，前面也講過，有些話用戶直接聊了，但有些話沒聊不等于沒有，需要產品經理運用縝密的邏輯進行推敲，串聯起業務流程，一次沒聊透徹沒關系，換用戶多次聊，最終保證需求不偏離用戶、業務領導的實際現狀。

以上是介紹如何降低風險的方式，就是利用透徹的需求調研方式保證需求獲取是準確的，是貼合業務的，具體可看筆者另外一篇文章《需求調研做好了，事半功倍！》http://www.aharts.cn/operate/5733996.html。

那么如果真的出現需求偏離現狀，需求調研失誤，又如何處理呢？

此時，也莫慌。一般需求調研階段，時間相對來說寬裕一些，并沒有方案確定后立馬投入開發、上線階段時間緊，所以還是有時間再修正需求結論的。而且這個時候，也不要為了趕進度，或是僥幸心理，覺得沒必要較真真實需求，先做個方案試驗一下不行再改，就急匆匆進入下一個階段，設計方案。因為越早發現問題，試錯成本就越低，越到后面產品設計、方案實施階段再發現問題再改，時間成本和開發成本就太大了。

筆者經歷的一個項目中就遇到了類似問題，前期因為調研需求是只針對某幾家公司調研，忽略了全國其他城市公司的業務特點，導致開發出來的產品只適用于這幾家公司，其他幾十家無法適用。好在業務領導也知道屬于前期探索階段，沒有對實際上線推廣時間有過多要求，才給予團隊快速調整的時間。

B端產品的業務較復雜，現狀流程都散落在多個角色用戶的腦袋里，未來改造流程也在業務領導的未來規劃中，一切都是變化著，就像之前有句話，唯一不變的就是變化。變化會帶來機會也會帶來風險，產品經理需要做的就是提前識別風險，需求環節獲取的每個流程都需仔細推敲，判斷是否有邏輯風險，并且根據現狀和未來發展，判斷風險概率大小。小概率事件則可暫時忽略，但不代表一直忽略，后續隨著業務發展也可能會變為大概率事件，定期檢視產品的各個環節也是很重要的。

二、方案設計與產品開發

需求確認無誤后，方案的設計就會水到渠成，但此時重點需要關注未來變化，方案也需要面向未來設計，留有一定易修改空間。

如筆者之前設計的產品方案緊跟需求，未深入挖掘，導致方案比較刻板，包容性不好。而且很多時候，方案的大小、好壞，都會決定費用的投入多少、未來上線質量的高低。那如何設計一個好的方案呢？

這就需要確認需求本質和判斷未來變化能力了。就像用戶說要一匹更快的馬一樣，如果你只盯著找馬，不如換個思路，汽車更能滿足用戶需求。

在實際項目如計算傭金規則方面，用戶說我的規則是銷售額乘以提成比例，提成比例又是根據銷售額梯度遞增，但另外公司的用戶所在市場不同，提出提成比例是按照銷售額梯度遞減，兩種相悖的規則，如果只考慮前者，后面就無法兼容，所以要提前考慮。

方案的設計也會直接影響開發工作量，就如上述案例，如果開發完成重新推翻再建立新規則，成本肯定很大。如果提前考慮未來解耦設計，單獨出獨立模塊，即使A模塊有變化，也不影響B模塊，也可以額外新增C、D模塊，都會大大提升工作效率，這就屬于包容性很好的產品方案，另外也需督促開發也朝著此方向發展。

小tips，方案設計完成后，一定要與業務對接人（出錢的人）進行確認，郵件或合同確認方案整體流程和方案細節，防止后面扯皮。這也是前面說的，風險的存在是因為業務人員想象中的結果和實際真實結果不同，未達到兩部分平衡，demo方案就是很好的落地形式，雙方基于同樣的東西進行確認，防止飄在空中，雞同鴨講。有了這個確認過的方案，后續用戶突然臨時新增需求，或是用戶想象中的產品和實際開發不同等情況，都有據可依了。

產品開發的風險主要是人，開發人員能力直接影響開發進度、開發質量，所以就需要產品經理提前找到磨合過的優質開發資源。如果新合作的開發人員或是合作過但開發能力不行的，就只能提前延長工期。如果項目非常緊急無法延長工期，要提前識別出資源風險緊張，趕緊找領導協調，這也是需要產品經理格外關注的。

項目開發中主要就是日會、周會確認開發進度，測試資源也需盡量保證充足，避免上線bug不斷。人員不夠也需產品頂上，總之，開發過程中就是高頻高效開會拉通團隊成員進度。

還有一個容易踩坑的點是，需求評審（主要是產品經理敘述背景、產品方案細節）后，一定過幾天就讓每個開發講解自己為了完成產品功能，需要做哪些事兒，然后就是測試用例評審會收尾，保證全組成員方向不偏。

筆者就出現過好幾次因為開發想當然以為產品功能是這樣設計，實際上沒有深入理解，導致開發結果與產品功能出現偏差。需求評審時只是產品經理輸出，并未融合開發獨立思考后的結果，所以容易出現偏差。所以開發評審主要就是針對開發基于產品方案，搭建開發方案，反饋產品經理，保證雙方達成共識。而且產品經理在設計產品方案時會側重需求方，對開發實現難易程度、具體如何實現未做過多深入思考，也會有些偏差，溝通會就非常有必要，也是提前降低風險的有利措施。

產品經理兢兢業業緊盯項目進度，最終測試通過，可以上線了，就需要提前與用戶溝通好準備工作，比如數據初始化、賬號權限安排等，而且大產品上線進來不要全部用戶一起上，而是找試點公司用戶，試運行一段時間修復完已知未知的bug后再全面鋪開，降低風險。

三、產品運營/運維

產品穩定運行后，你以為就可以萬事大吉了么？切不可掉以輕心，筆者就的一個項目事故就是在這個環節爆發出來，以為沒什么大bug、大需求，產品穩定期應該沒什么大問題，就放松警惕，疏于定期管理與審視，導致突然出現數據錯誤，引起用戶和業務支持者投訴。

究其原因，就是因為產品在上線初期重點關注大概率的場景，比如業務上經常出現的流程，而小概率場景沒有過多考慮，可能半年也不會出現此場景，也就沒有重新整理。慢慢的就把一些系統風險遺忘，導致突然某一天，小概率場景出現，引起大批量數據錯誤。

經歷此次事故，我們團隊也認真復盤，大家一致認為，針對穩定運行的產品功能，隨著業務的變化，也會有一定影響，所以需建立定期風險排查動作，將實際業務場景逐一梳理分析，再走一遍系統流程，反推是否有功能異?；驍祿栴}，盡早發現，盡早解決。

總結：風險無處不在，有大有小，細想也都有應對的方案，但前提是心中要有這根線，時刻多問問自己，完成這部分工作了，有哪些環節沒考慮到嗎？干好的標準是什么？干差的情況是什么？干差的風險概率多大？應對措施有哪些？提前考慮到了，到事兒上就可以臨危不亂。