时间: 2021-07-30 11:13:57 人气: 10 评论: 0
#本文为人人都是产品经理《原创激励计划》出品。
保持合理“怀疑”，是产品经理在工作中所应具备的态度，这一态度可以让产品经理更迅速地发现业务疏漏，及时解决未知问题，为工作赋能。同时，这一态度需要贯彻于产品经理工作的各个层面。具体应如何保持“怀疑”？不妨读一读作者的看法。
很多小伙伴都看过下面这张图，“不要相信任何人”是产品经理的生存法则。我想使用项目中真实发生的案例谈谈我个人的看法，请时刻保持“怀疑”态度。
对业务提的需求保持“怀疑”态度，时刻提醒我们再问得多一点，再沟通得深一点。
以下是为我与业务的沟通过程：
业务：产品管理中的“单价”可不可以独立修改，并且放在单独的列表展示，不和基础信息修改放在一起？
我：我们现在已经做了信息修改的功能，其中包含了“单价”的修改，需要你描述一下这个需求详细的场景和单独修改的作用。
业务：我觉得在一起修改比较麻烦，我想单独修改。
我：如果再做一个单独修改的，**导致功能重复，页面功能过多使用起来并不一定很方便哦，而且我们现在技术资源不足，有很多需求在排期，暂时不考虑这种优化功能。
业务：我们小组主要负责价格的优化，如果你不帮我们做这个东西，我怎么去计算价格变化？
我：如果你需要价格的变化，我们可以考虑做一个统计报表，更好地监控和分析价格的变化。
业务：那好吧，可以按照你们的要求去做。
我们本次沟通，最终的方案是做统计报表，监控价格的变化。
不过我心里依旧保持一个“怀疑”的观点：业务方并不一定只是为了看价格的变化，也有可能价格的变化对他们的绩效产生影响，他们拿到价格变化的数据是为了统计绩效。如果我们可以进一步通过系统直接计算出组内各个同事的绩效，业务方的使用**更加便捷。
需求是隐形的，用户往往不知道自己想要什么，受于自身的认知的局限性，用户提出的方案往往是他所看过的某种方法。一切真正的需求来源于沟通，我们必须要不断深究，找到核心问题，并提供解决方案。
对技术的方案保持“怀疑”态度，不代表对技术的水平不信任，只是提醒我们要时刻准备处理未知的风险。
下面是我负责的某个系统发生的问题。
需求：计算过去30天销量的趋势值，过去30天可能销量波动较大，故需要判断使用不同计算公式。
设计方案的计算逻辑：判断过去30天内销量>0的值的个数：
技术实现的计算逻辑：判断过去30天内销量=0的值的个数：
技术为了判断方便，把判断的方式转换了一下，大部分情况下，这两种方式计算的结果绝对是一致的，测试同学模拟数据进行验证，结果是一致的，需求验收上线了。
上线后，我们用大量真实的数据跑了两天，我在排查数据时，发现大部分数据都是正常的，有个别数据是异常的，经过我大量的验算，发现了实现的方式与原来设计的有点不一致。
在我们实际的业务中，有些产品刚刚上架，只卖了几天，所以并不是所有产品都有过去30天销量的，按照原有逻辑，销量较少的应该使用“平均数”计算，但是按照技术的逻辑，使用的是“中位数”。
我看过一个很有意思的比喻，说程序的代码就像“城中村的电线”，虽然看起来杂乱无章，但是能保证每家每户都有电，使用起来没有任何问题，但如果有一天有人动了一条电线，整个城中村电路就瘫痪了（没有嘲笑的意思，程序员小哥哥勿怪）。
所以说系统上线，正常运行，不代表我们产品工作已经完成，仍然需要一直跟进，负责产品的全生命周期管理，对于任何的小问题都要有所警醒，复查是否是系统设计方面有所漏洞。
对系统数据保持“怀疑”态度，是指我们不能单纯只看数据，要结合数据背景，进行合理的分析。系统的数据是最客观的，经过合理的分析，可以辅助我们做很多改善。
以下报表是我模拟的一份电商公司的数据（仅供参考）：
图一
看图一，如果仅仅来看这份数据和趋势图，我们得到的第一个结论可能是，公司退款率在不断下降，客服部门做了很多的努力。
图二
再看图二，我们拿到了销售额和退款额，发现1、2月份销售额不高，但是退款额很高，10月份开始销售额开始上升，这个时候我们已经对图一的退款率变化产生了“怀疑”态度。
图三
图三，我将退款率的计算公式换了一种算法，【退款率=当月的退款额/上一个月的销售额】，整体的退款率就趋于了稳定。
在电商行业的同学大概知道，上半年是淡季，下半年是旺季，跨境电商的配送周期较长，订单的退款经常**发生跨月的情况，例如12月的订单，退款集中在1、2月，但是1、2月的销量没有12月份高，所以就出现了图一中的1、2月退款率过高的情况。我描述的这种算法并不是最合理的算法，只是一个取巧的方式，具体的算法我们还要结合行业的背景进行优化。
脱离了实际业务的数据分析没有任何意义，我们在看任何数据的时候都要附带背景，在得出看似合理的结论之后，仍然要对数据保持“怀疑”态度。
对领导的安排保持“怀疑”态度，是让我们有“向上管理”的思维，对于领导的吩咐，要洞察背后的含义，若领导安排的工作难以开展，也要及时反馈，与领导达成一致意见。
有这么一个场景给大家举例：
领导：我刚刚开完公司的**议，上面沟通了一个事情，你去把A需求做了。
我：领导，这个A需求是主要解决什么问题呢？
领导：这个是为了解决XXX的问题。
我：领导，您还记得一个月前我们有个需求B吗？当时评审B需求时，B的优先级不高，我们排到了下个月的版本中，我刚才听您的描述，如果要做这个A需求，需要有B作为基础支撑，才能实现A的方案，您看我是不是要把B的优先级提上来，B需求配合A需求去做？
领导：哦，之前我没注意到这个细节，我先考虑一下时间和资源安排，稍后做出决定我通知你。
我：好的，收到。
在“领导”这一角色，由于观察问题的高度不一样，往往**忽略到一些细节点，我们作为方案的执行者，是需要将方案进行落地的，如果经过合理的分析，发现方案上面的漏洞，需求及时反馈问题，并提供可处理的方案，由领导拍板决定如何进行下面的工作。
每个人都**有犯错的时候，我们自身也不例外，做项目复**就是为了检查历史项目中的不足，并要求自己在接下来的项目中改进。
有一个名词叫“专家盲点”，大概的意思就是一个精通某领域的专家，正因为他太精通，以至于他忘记了当他不是专家时所遇到的困难。
当我们去做一个熟悉的工作时，很多时候肢体的动作绕过了大脑的思考，使用的是肌肉记忆。
如果带过很多项目，在业务提出需求时，我们很迅速地能判断业务提的需求是否可以实现，从而在短时间内给出答案，这个时候我们很可能**陷入“专家盲点”。
我们需要分析需求的背景，切换不同的视角，来重新审视这个需求的合理性和技术可行性，把每一次需求都当做一个全新的需求来对待。
对自我保持“怀疑”态度，谨防可能发生的风险，并做好随时调整方案的准备。
保持“怀疑”态度，保持敬畏之心。
望与君共勉，欢迎评论骚扰~
本文由 @elvin 原创发布于人人都是产品经理，未经许可，禁止转载。
本文为人人都是产品经理《原创激励计划》出品。
题图来自 Pexels，基于 CC0 协议
