掌握“影响分析思维”,解决产品节点缺陷

1 评论 7358 浏览 17 收藏 19 分钟

产品经理作为互联网中的“撕逼工作者”“需求沟通者”,每天都被大量事务、大量细枝末节包围着,而这些事务也容易产生大量棘手、难解决的问题,那么学会“影响分析思维”后,将有效帮助我们从根源解决问题。

01 一些常见的问题

作为互联网产品经理,是否遇到过以下的场景:

  1. 需求文档写完了,但是交互设计师的给出的方案和自己想的并不一样、设计师的画风跟自己的脑海里的完全不一样。
  2. PRD和交互原型都输出了,但在技术评审过程中,程序猿说“这个实现不了”,又或者评了一个超长的时间,然后项目经理说要不还是砍砍需求吧。
  3. 新功能完成了开发,但是到测试的时候,测试的同事或者产品经理自己无意间发现,咦,新功能没问题,怎么一些老旧的功能突然报错了?找技术沟通之后发现,原来是那些老旧功能也用了同一个板块,没考虑到。结果只能加班加点修复,甚至延迟发版。
  4. 新功能上线后,运营反馈说用户投诉骤然增多,一调研发现,原来是新功能打断了用户原来熟悉的必须流程,或者新的字段加重了用户的工作量,又或者新的功能增加了误操作的概率等。
  5. 新功能上线后,从用户访问量看,尽管运营已经很尽力的推广了,但是新功能的使用量还是很低。

今天我们尝试用一个新的角度去审视、解决上述问题。

02 影响分析

有一种设计方法叫做FMEA,Failure Mode and Effects Analysis 失败模式和影响分析,FMEA于20世纪50年代于美国被提出,多用于工业系统设计制造的过程。

FMEA用于在产品设计阶段和过程设计阶段,对构成产品的子系统、零件,对构成过程的各个工序逐一进行分析,找出所有潜在的失效模式,并分析其可能的后果,从而预先采取必要的措施,以提高产品的质量和可靠性的一种系统化的活动。

FMEA有专业的软件为那些大型工业制造商去实施,我们这里就简单讲一下其流程:

  1. 整理流程图
  2. 明确流程每个节点的要求
  3. 针对每个节点找出可能发生的不良模式及发生原因
  4. 对每个节点存在的缺陷进行风险评估
  5. 对严重的问题进行解决
  6. 实施改善后的流程

FMEA用的评估方法叫做PRN,Risk Priority Number,风险优先数/级。主要从以下三个方面对影响进行评估。

PRN=S x O x D

  • Severity 严重程度
  • Occurrence 发生概率
  • Detection 可发现性/发现难度/不可侦测性

以下我们将会用FMEA的思维去评估一个新功能上线的流程,但是我们侧重点是找出容易产生的影响,并在工作过程中尽可能的避免,而不是遇到了问题后如何去解决。

03 工作流程

上图是一个经典的互联网产品产生的流程图,从一个idea的产生到落地的循环生态。

对于产品经理而言,他们是整个流程的出发点,一个需求经过了交互设计师、视觉设计师、技术开发、测试、运营,最后面向用户。

用一个不太合适的形容词,就是“你比划我来猜接龙”的过程,最初的想法和用户最终看到的效果,可能会有一定的的差异,而这过程中,一些潜在的问题就显现、放大,甚至产生不好的影响。

我们将针对每个节点,我们都提前找出可能的影响,比尝试找出规避或解决影响的方案。

3.1 交互与视觉设计

在功能需求的设计过程中,产品经理应当去思考,功能的操作流程、呈现效果,是否与当前产品的定位、体验一致,而不是把这个问题完全抛给设计师的去解决。

例如我们的产品定位是简单,用户无脑刷就得了,但是某个新功能为了检测用户忠诚度,需要用户在手机上完成一个很复杂的流程或动作,然后能获得对应的奖励。

这个复杂的流程可能在你的表达传达给交互设计师时,就会有一定的偏差,等到交互设计师为了统一整个产品的交互逻辑,完成方案时,效果又会产生一层偏差,先不谈这个结果是不是用户想要的,至少很可能这个结果并不是你想要的。

再例如,需求文档中欠缺对视觉效果的要求,最后设计师出的图,可能完全不是产品经理想要的,相信这种事情大家应该见多了。

面对这种情况,在写PRD的时候不妨多附上一些理想的同类产品的界面图片、并多视图描述一下视觉风格倾向,就能把这种偏差减少。

3.2 研发测试

产品:“我想要一个根据手机壳变手机主题颜色的APP

技术:“实现不了”

产品:“怎么实现我不管,明天就要上线”

于是技术就把产品打了……

这并不是一个“空穴来风”的事情,但是与技术撕逼,可能是产品经理工作中除了写PRD第二重要的事情了。

了解一个功能是如何实现的,在产品经理眼里和在技术大大们眼里,可能并不是一回事。

就如上图所示,一个产品,在产品经理眼里,整个系统被安排得稳稳妥妥、明明白白。但是在技术眼里,你甚至可能找不到那些技术上的接口,和产品经理眼里的功能的关联。

对于产品经理看来的好几个功能点及好多个端的区别,有可能在技术层面上是同一个接口处理、同一个数据表保存、只是用不同字段及状态进行区分展示而已。

于是乎由于产品架构与技术架构的不一致,就容易引发最经典的三个案例:

  1. 产品:“明明有类似的功能,为什么不能复用?”,技术:“功能看似相似,但是写在不同的项目中,且底层读的表也不同,差异巨大,还不如重新写一个。”
  2. 产品:“这个看着很容易啊,为什么实现不了”,技术:“是看着容易,但是现在用的底层技术框架并不带有这样的功能/不是为这类需求设计的,所以没法实现。”
  3. 产品:“为什么一个新功能优化,老是导致原有其他的功能出bug?”,技术:“你PRD也没写这个功能在别处也用到了啊!”

以上种种问题很容易影响开发进度,也容易导致在开发过程中需求被迫修改、甚至砍掉。想要避免这些问题,方法也很简单:

1-2:多提前沟通交流,了解一些关于自家产品的技术结构和实现方式。这里其实并不需要产品经理懂得怎么看代表,技术架构的东西一样可以用流程图、系统蓝图等,大家都看得明白的方式来表达。

3:在写PRD时,回顾一下产品中其他功能,是否还有其他功能依赖着本功能,或者其他位置会跳到此版块,又或者是否有其他产品、供应商也对接了此功能,旧版本是否兼容此功能等。把这些依赖关系都梳理出来,能让技术大大们更好的进行影响分析和兼容性设计,从而潜在的问题。

例如我们要给商品加个“品牌”字段,那么商品都会在哪些界面显示出来、商家又都能在哪些终端、通过哪些方式创建商品,平台后台又有多少个查看商品信息的地方,是否有对接的供应商需要有在获取商品信息。

果我们漏了其中任何一点,很可能这个新增的“无关”字段,就会导致一部分商家创建商品的时候报错、又或者运营在后台某个位置选择商品时,发现商品名称都变成了品牌名称等等。

我其实写了挺多篇关于产品经理要懂点技术的文章,类似的技术科普文不少,大家有兴趣可以自行百度。

3.3 产品上线

假如一个APP上原生的功能需要更新,那么iOS需要提交给苹果的应用商店审核、安卓需要提交给腾讯应用宝/360/小米/华为/百度等应用商店审核。微信小程序功能要更新,也需要提交给微信进行审核。只有审核通过后,用户通过公开的途径才能下载使用最新的版本。

不知道是否有产品经理遇到过这样的问题,测试或技术的同事将应用提交审核后,过了几个小时或者一两天,反馈回来却说,审核失败了,对方需要提交XXXX资格证、XXXX执照,于是就从产品经理问运营,运营问财务法务,财务法务问老板……最后发现公司确实没有这个资质,最后一整个月的功劳都白费了。

还有一种情况,就是应用申请上架后,被驳回的理由是里面使用了一些对应平台不允许使用的技术,或者不符合对应平台的规范。于是技术或测试又来找产品,然后产品就跟领导沟通,找技术、项目重新评估时间,重新开发……

这种影响其实在产品设计的最初阶段就应该避免,这里建议产品经理们阅读并熟悉以下内容:

1. 微信小程序运营指南,可能是全世界要求与限制最多的平台之一:https://developers.weixin.qq.com/miniprogram/product

2. 苹果应用原则与规范,根据苹果官方数据,苹果应用商店拒绝的比例达40%:https://developer.apple.com/cn/app-store/review/guidelines/

3. 百度应用商家审核规范,虽然百度应用商店用户量不多,但是从我的经验来看,要求算是安卓市场里面最严的:http://app.baidu.com/docs?id=18&frompos=401009

4. 阅读并熟悉你所在行业的法律法规,例如我国对金融、网约车、医疗器械等行业是有明确的政策要求的。

5. 认同一个常识问题,别人的地盘别人做主:

在微信的公众号、小程序文档里都不会写,微信里是不能用支付宝的(虽然反之支付宝里也不能用微信),微信里也打不开淘宝、拼多多、抖音、今日头条,甚至某天也会屏蔽你家的APP。
不过不要因此道德绑架微信,那是人家的地盘,你要有本事也可以不用微信联登、分享到微信、持微信支付、不开微信公众号、不开微信小程序的嘛:)

3.4 运营落地

运营落地的影响分为两部分:

1)运营影响

产品对于运营的影响非常大,毕竟运营只能根据有的功能进行宣传推广,巧妇难为无米之炊。一个产品在设计之初,建议跟运营的同事先聊一下,看看竞品是否有类似的推广经验,是否需要供应商进行配合提供对应商品或服务等,让运营同事有提前准备,包括宣传预热等。

若是等到产品上线后,才让运营开始着手准备推广,可能会产生预算经费不足、配套商品或礼品没准备没到位、由于没有前期宣传导致用户一脸茫然等后果。

2)用户体验

产品设计的初衷,其实想给用户带来更好的体验。但是由于用户并不只用你一家的产品,而是生活在一个信息爆炸的时代,被很多的主流势力、还有你家产品原有的功能等培养出了一套“用户预期”,在用户眼里,可能你的产品就应该是怎么样的,如果新功能并没有考虑这个问题,可能不仅不能提高用户体验,还会导致用户出现操作障碍,降低用户转换率。

所以在设计需求的过程中,必须考虑功能是否符合“用户预期”,如果一个功能确实很创新、独到,那就应该考虑增加一些用户操作指引等。如果新功能不得不打断原有的流程,那就应该注意让这个变化更平滑过渡,而不是突兀的改变。

总的来说就是:运营要准备、用户要引导。

3.5 项目管理

有些公司可能产品经理自身就要兼任项目经理的职责,对项目进度,尤其是开发进度,还有需要配合的资源进行沟通。

1)时间

需求设计的过程中需要预估设计、开发、上线的大致时间。版本迭代的周期过于频繁或滞后会对用户造成不同的影响。

多参加设计、技术评审会,积累经验了解一个功能设计、研发、测试的周期,将有助于产品经理更好的进行版本规划,让用户感知以一个平稳的步伐在进行产品更新,不频繁更新扰民,也不会堆积了一堆问题、风格陈旧很久才处理一次。

另外应用市场、微信小程序等上线审核是需要时间的,几个小时到几天不等。而且逢年过节的时候,国内外应用市场的审核人员也会放假的。这就对于有紧急发版、重大节日前后发版需求的产品来说,必须提前了解对应应用市场的时间安排,然后与项目同事一起反推定好好研发deadline。

2)依赖资源

对于有些功能而言,例如查询快递、唤起支付宝/微信/银联支付、微信/QQ联合登录、利用地图展示某些信息等,都是需要供应商配合对接才能完成的。如需设计对应功能,应事先与项目经理、商务等同事沟通,了解对方是否要签合同和付费、获得对方的开发者账号、开发文档等内容,为进一步技术对接做好准备。

如有能力的话尽可能阅读一下供应商的开发文档,了解功能是否与我方需求匹配,是否存在一些限制可能会影响未来功能的发展等。

3)对外部系统的影响

如果你的产品是面向商家端或工厂端的,那么有商家来对接是很常见的事情。他们自有的系统通过我方接口获取一些信息,我方新的功能调整是否需要他们同步更新,如果需要也要对方提前做好对接工作,预防我方上线后对方系统无法工作等。

四、总结

其实产品经理的工作与交互、视觉、研发与测试、运营、项目他们的工作都息息相关,大家的工作是围绕着“产品落地”在转,从一个idea冒出,到最终产品呈现在用户眼前,不仅仅是公司内部的事情,还与应用市场的规范、相关法规政策、依赖资源供应商、依赖着自己的外部系统等都有关系。

影响分析的最大用处,就是理性对待产品落地过程中各个节点,找出可能存在的问题,并在最开始设计需求的时候,就该规避的规避、该提前准备的进行准备,避免一个需求最后陷入无法实现、落地的僵局中。所谓“磨刀不误砍柴工”。

影响分析让产品需求的设计,由“我不要你以为,我要我以为”,变成“不打无准备之仗”,也只有这样,才能让一个团队更好的工作下去,不断推出对用户和市场有利的好功能、好产品。

 

本文由 @iCheer 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 写的不错,值得学习

    回复