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

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协议。