项目进行过程中，如何把控B端产品的风险管理？

B端产品从需求调研到产品上线，需要经历一系列流程。那么，为了推进产品进度，我们需要做一些风险管理。作者结合自己的项目，总结产品线流程中，如何进行风险管理以及相关应对措施，希望对你有所帮助。

B端产品从需求调研、产品设计、开发、上线、推广培训等环节中，除了推进产品进度，风险管理也至关重要，稍有不慎，就会影响项目进度。那么如何识别风险？风险出现的概率如何评估？如有风险则如何应对？解决方案可以提前构思吗？等等有关风险问题，都需要产品经理在跟进产品全流程环节中，反复想清楚，才能确保产品保质保量上线。

笔者刚从事产品工作时，作为产品助理，主要是跟着产品经理进行原型设计，当时比较关注的是产品流程执行方面工作，如页面功能设计、PRD的编写、上线前的测试、上线后的推广培训工作，并未关注到风险方面。

后面独立负责单独的产品和产品线以后，发现，底层的执行方面工作其实是最固定的，风险也是最低的，因为确定性比较高，方向定了干就完了。而挖掘需求、产品方向、资源协调等大方面事宜，不确定性很高，风险也比较大，所以就需要有意识投入更多精力关注到风险这条线，与产品流程线并行，才能保证产品稳步进行。

笔者负责的几个项目中，有过好成绩，也有过生产事故，血的教训，让我对风险管理逐步建立起完整方法论。风险本质上是实际结果和预期未完全匹配，遭到客户或用户等相关方的投诉，例如用户投诉你设计的产品特别难用，找不到想要的按钮。或是产品运行中出现数据纰漏，导致业务无法在规定时间完成工作等，都属于风险事故。

风险管理，其实就是有限的时间和资源下，管理未来目标的实现和相关用户的期望值不出现巨大偏差，就需要在必要节点与相关方充分沟通，方案设计也不能太满，要留有一定容错空间，与用户沟通也是如此，话不说满，留有余地，比如上线时间需充分评估不能太紧。

所以说产品经理要了解心理学，就是需要洞察一些人性规律。比如期望如果很高，实际达不到，则大概率是失望的，但是期望如果低一些，实际容易达到，那么大概率就是惊喜。

还有，和各类相关方沟通时，尤其是B端涉及业务流程改造改革方面，用户投诉产品不好用，不代表着真不好用，可能本质原因是他们不想更换工作流程，因为学习成本较高，或是销售为了隐藏业绩没有实际录入系统等等，所以业务里面的可说部分也许是水平面的冰山一角，很多业务也需在水面下面，需要产品经理潜心挖掘。

下面就从几方面，总结下产品线流程中，并行的风险这条线，如何进行风险管理，以及相关应对措施。

一、需求调研阶段

此阶段的风险最主要是需求判断失误，不满足用户或相关方的业务痛点。

这里需要解释下，B端产品的成功不仅只是满足使用者（即用户）的需求，还需满足相关方（如直属业务sponsor、上下游业务关联方等）的需求。一般用户属于执行者，注重业务流程上的一个操作点，并不能全流程串联起来。而项目相关方，一般是项目的发起人，B端产品基本就是业务领导，站在公司降本增效角度，全流程的进行业务改造。而信息化产品就是最有利的抓手，可以更快实现降本增效目标。

所以此阶段，不仅要和用户聊、也要与业务领导层充分沟通，目标、方向的确认也是基于业务领导层对工作的规划，具体方案如何实现就需要和用户充分沟通。当然，前面也讲过，有些话用户直接聊了，但有些话没聊不等于没有，需要产品经理运用缜密的逻辑进行推敲，串联起业务流程，一次没聊透彻没关系，换用户多次聊，最终保证需求不偏离用户、业务领导的实际现状。

以上是介绍如何降低风险的方式，就是利用透彻的需求调研方式保证需求获取是准确的，是贴合业务的，具体可看笔者另外一篇文章《需求调研做好了，事半功倍！》https://www.woshipm.com/operate/5733996.html。

那么如果真的出现需求偏离现状，需求调研失误，又如何处理呢？

此时，也莫慌。一般需求调研阶段，时间相对来说宽裕一些，并没有方案确定后立马投入开发、上线阶段时间紧，所以还是有时间再修正需求结论的。而且这个时候，也不要为了赶进度，或是侥幸心理，觉得没必要较真真实需求，先做个方案试验一下不行再改，就急匆匆进入下一个阶段，设计方案。因为越早发现问题，试错成本就越低，越到后面产品设计、方案实施阶段再发现问题再改，时间成本和开发成本就太大了。

笔者经历的一个项目中就遇到了类似问题，前期因为调研需求是只针对某几家公司调研，忽略了全国其他城市公司的业务特点，导致开发出来的产品只适用于这几家公司，其他几十家无法适用。好在业务领导也知道属于前期探索阶段，没有对实际上线推广时间有过多要求，才给予团队快速调整的时间。

B端产品的业务较复杂，现状流程都散落在多个角色用户的脑袋里，未来改造流程也在业务领导的未来规划中，一切都是变化着，就像之前有句话，唯一不变的就是变化。变化会带来机会也会带来风险，产品经理需要做的就是提前识别风险，需求环节获取的每个流程都需仔细推敲，判断是否有逻辑风险，并且根据现状和未来发展，判断风险概率大小。小概率事件则可暂时忽略，但不代表一直忽略，后续随着业务发展也可能会变为大概率事件，定期检视产品的各个环节也是很重要的。

二、方案设计与产品开发

需求确认无误后，方案的设计就会水到渠成，但此时重点需要关注未来变化，方案也需要面向未来设计，留有一定易修改空间。

如笔者之前设计的产品方案紧跟需求，未深入挖掘，导致方案比较刻板，包容性不好。而且很多时候，方案的大小、好坏，都会决定费用的投入多少、未来上线质量的高低。那如何设计一个好的方案呢？

这就需要确认需求本质和判断未来变化能力了。就像用户说要一匹更快的马一样，如果你只盯着找马，不如换个思路，汽车更能满足用户需求。

在实际项目如计算佣金规则方面，用户说我的规则是销售额乘以提成比例，提成比例又是根据销售额梯度递增，但另外公司的用户所在市场不同，提出提成比例是按照销售额梯度递减，两种相悖的规则，如果只考虑前者，后面就无法兼容，所以要提前考虑。

方案的设计也会直接影响开发工作量，就如上述案例，如果开发完成重新推翻再建立新规则，成本肯定很大。如果提前考虑未来解耦设计，单独出独立模块，即使A模块有变化，也不影响B模块，也可以额外新增C、D模块，都会大大提升工作效率，这就属于包容性很好的产品方案，另外也需督促开发也朝着此方向发展。

小tips，方案设计完成后，一定要与业务对接人（出钱的人）进行确认，邮件或合同确认方案整体流程和方案细节，防止后面扯皮。这也是前面说的，风险的存在是因为业务人员想象中的结果和实际真实结果不同，未达到两部分平衡，demo方案就是很好的落地形式，双方基于同样的东西进行确认，防止飘在空中，鸡同鸭讲。有了这个确认过的方案，后续用户突然临时新增需求，或是用户想象中的产品和实际开发不同等情况，都有据可依了。

产品开发的风险主要是人，开发人员能力直接影响开发进度、开发质量，所以就需要产品经理提前找到磨合过的优质开发资源。如果新合作的开发人员或是合作过但开发能力不行的，就只能提前延长工期。如果项目非常紧急无法延长工期，要提前识别出资源风险紧张，赶紧找领导协调，这也是需要产品经理格外关注的。

项目开发中主要就是日会、周会确认开发进度，测试资源也需尽量保证充足，避免上线bug不断。人员不够也需产品顶上，总之，开发过程中就是高频高效开会拉通团队成员进度。

还有一个容易踩坑的点是，需求评审（主要是产品经理叙述背景、产品方案细节）后，一定过几天就让每个开发讲解自己为了完成产品功能，需要做哪些事儿，然后就是测试用例评审会收尾，保证全组成员方向不偏。

笔者就出现过好几次因为开发想当然以为产品功能是这样设计，实际上没有深入理解，导致开发结果与产品功能出现偏差。需求评审时只是产品经理输出，并未融合开发独立思考后的结果，所以容易出现偏差。所以开发评审主要就是针对开发基于产品方案，搭建开发方案，反馈产品经理，保证双方达成共识。而且产品经理在设计产品方案时会侧重需求方，对开发实现难易程度、具体如何实现未做过多深入思考，也会有些偏差，沟通会就非常有必要，也是提前降低风险的有利措施。

产品经理兢兢业业紧盯项目进度，最终测试通过，可以上线了，就需要提前与用户沟通好准备工作，比如数据初始化、账号权限安排等，而且大产品上线进来不要全部用户一起上，而是找试点公司用户，试运行一段时间修复完已知未知的bug后再全面铺开，降低风险。

三、产品运营/运维

产品稳定运行后，你以为就可以万事大吉了么？切不可掉以轻心，笔者就的一个项目事故就是在这个环节爆发出来，以为没什么大bug、大需求，产品稳定期应该没什么大问题，就放松警惕，疏于定期管理与审视，导致突然出现数据错误，引起用户和业务支持者投诉。

究其原因，就是因为产品在上线初期重点关注大概率的场景，比如业务上经常出现的流程，而小概率场景没有过多考虑，可能半年也不会出现此场景，也就没有重新整理。慢慢的就把一些系统风险遗忘，导致突然某一天，小概率场景出现，引起大批量数据错误。

经历此次事故，我们团队也认真复盘，大家一致认为，针对稳定运行的产品功能，随着业务的变化，也会有一定影响，所以需建立定期风险排查动作，将实际业务场景逐一梳理分析，再走一遍系统流程，反推是否有功能异常或数据问题，尽早发现，尽早解决。

总结：风险无处不在，有大有小，细想也都有应对的方案，但前提是心中要有这根线，时刻多问问自己，完成这部分工作了，有哪些环节没考虑到吗？干好的标准是什么？干差的情况是什么？干差的风险概率多大？应对措施有哪些？提前考虑到了，到事儿上就可以临危不乱。