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

01 一些常见的问题

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

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

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

02 影响分析

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

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

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

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

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

PRN=S x O x D

Sev云帆学社erity 严重程度Occurrence 发生概率Detection 可发现性/发现难度/不可侦测性

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

03 工作流程

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

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

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

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

3.1 交互与视觉设计

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

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

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

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

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

3.2 研发测试

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

技术：“实现不了”

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

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

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

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

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

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

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

产品：“明明有类似的功能，为什么不能复用？”，技术：“功能看似相似，但是写在不同的项目中，且底层读的表也不同，差异巨大，还不如重新写一个。”产品：“这个看着很容易啊，为什么实现不了”，技术：“是看着容易，但是现在用的底层技术框架并不带有这样的功能/不是为这类需求云帆学社设计的，所以没法实现。”产品：“为什么一个新功能优化，老是导致原有其他的功能出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协议。