请时刻保持“怀疑”态度

18 评论 9749 浏览 34 收藏 13 分钟

#本文为人人都是产品经理《原创激励计划》出品。

保持合理“怀疑”,是产品经理在工作中所应具备的态度,这一态度可以让产品经理更迅速地发现业务疏漏,及时解决未知问题,为工作赋能。同时,这一态度需要贯彻于产品经理工作的各个层面。具体应如何保持“怀疑”?不妨读一读作者的看法。

很多小伙伴都看过下面这张图,“不要相信任何人”是产品经理的生存法则。我想使用项目中真实发生的案例谈谈我个人的看法,请时刻保持“怀疑”态度。

一、对业务提的需求保持“怀疑”态度

对业务提的需求保持“怀疑”态度,时刻提醒我们再问得多一点,再沟通得深一点。

以下是为我与业务的沟通过程:

业务:产品管理中的“单价”可不可以独立修改,并且放在单独的列表展示,不和基础信息修改放在一起?

我:我们现在已经做了信息修改的功能,其中包含了“单价”的修改,需要你描述一下这个需求详细的场景和单独修改的作用。

业务:我觉得在一起修改比较麻烦,我想单独修改。

我:如果再做一个单独修改的,会导致功能重复,页面功能过多使用起来并不一定很方便哦,而且我们现在技术资源不足,有很多需求在排期,暂时不考虑这种优化功能。

业务:我们小组主要负责价格的优化,如果你不帮我们做这个东西,我怎么去计算价格变化?

我:如果你需要价格的变化,我们可以考虑做一个统计报表,更好地监控和分析价格的变化。

业务:那好吧,可以按照你们的要求去做。

我们本次沟通,最终的方案是做统计报表,监控价格的变化。

不过我心里依旧保持一个“怀疑”的观点:业务方并不一定只是为了看价格的变化,也有可能价格的变化对他们的绩效产生影响,他们拿到价格变化的数据是为了统计绩效。如果我们可以进一步通过系统直接计算出组内各个同事的绩效,业务方的使用会更加便捷。

需求是隐形的,用户往往不知道自己想要什么,受于自身的认知的局限性,用户提出的方案往往是他所看过的某种方法。一切真正的需求来源于沟通,我们必须要不断深究,找到核心问题,并提供解决方案。

二、对技术的方案保持“怀疑”态度

对技术的方案保持“怀疑”态度,不代表对技术的水平不信任,只是提醒我们要时刻准备处理未知的风险。

下面是我负责的某个系统发生的问题。

需求:计算过去30天销量的趋势值,过去30天可能销量波动较大,故需要判断使用不同计算公式。

设计方案的计算逻辑:判断过去30天内销量>0的值的个数:

  1. 若个数>15,则计算公式使用中位数;
  2. 若个数<=15,则计算公式使用平均数。

技术实现的计算逻辑:判断过去30天内销量=0的值的个数:

  1. 若个数<=15,则计算公式使用中位数;
  2. 若个数>15,则计算公式使用平均数。

技术为了判断方便,把判断的方式转换了一下,大部分情况下,这两种方式计算的结果绝对是一致的,测试同学模拟数据进行验证,结果是一致的,需求验收上线了。

上线后,我们用大量真实的数据跑了两天,我在排查数据时,发现大部分数据都是正常的,有个别数据是异常的,经过我大量的验算,发现了实现的方式与原来设计的有点不一致。

在我们实际的业务中,有些产品刚刚上架,只卖了几天,所以并不是所有产品都有过去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 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 多想想为什么,原因是啥

    来自广东 回复
  2. 我心里依旧保持一个“怀疑”的观点:业务方并不一定只是为了看价格的变化,也有可能价格的变化对他们的绩效产生影响–没打算去确认下么

    来自福建 回复
    1. 按理说应该是要去确认的,不过考虑到当时的情况,资源时间都不够,不敢进行再深一步的扩展了

      来自广东 回复
    2. 那我还猜对了,感觉要是跟下去,可能又谈出一个需求,难过

      来自福建 回复
  3. 主要是觉得这种类似接近精英级的“怀疑”脑子能不能真能快速转过来

    回复
    1. 在遇到事情时,不着急下结论,经过认真分析思考后,再给出回复,多加练习,就会越来越熟练了

      来自广东 回复
  4. 结构清晰,案例丰富极有代入感,赞赞!

    来自浙江 回复
    1. 😜

      来自广东 回复
  5. 给第一个图点赞哈哈哈哈!

    来自广东 回复
    1. 😜

      来自广东 回复
  6. 保持“怀疑”态度,保持敬畏之心。

    来自上海 回复
    1. 共勉

      来自广东 回复
  7. 很赞哟~

    回复
    1. 感谢😜

      来自广东 回复
  8. 注意人身安全 哈哈哈

    回复
    1. 哈哈

      来自广东 回复
  9. 来自广东 回复
    1. 感谢😜

      来自广东 回复