首页 > 资讯 > 职场 >  职场攻略 > 项目进行过程中,如何把控B端产品的风险管理?

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

更新时间:2023-02-12 06:26:57 1021

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、大需求,产品稳定期应该没什么大问题,就放松警惕,疏于定期管理与审视,导致突然出现数据错误,引起用户和业务支持者投诉。

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

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

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

本文由@元方 原创发布,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

高额信用卡低门槛,1天下卡,免费申请>>

【免责声明】本站所载文章著作权归原作者所有,如有侵权请通过邮箱w3tool@geekdata.com联系我们。