第六章 进阶16 产品经理容忍度低一点

TA是一个报表系统，其中的一个报表，执行需要2个小时，有一点小的功能调整，就要跑2个小时，而且在白天用户较多的时间，还经常会执行失败，非常低效。

两周前，我的一个需求调整中，出现了这个场景。我让PM小杨组织一次代码review会，把研发的专家、DBA、部门负责人都约上，大家一起诊断下，是否能提升？

在这个会议的准备过程中，我了解到：

1）中台研发的专家给该产品的开发予以指导

2）开发同学自主优化，效率从2小时提高到20分钟

3）DBA主动提供支持，把效率提高到了3分钟

昨天TA的另一位PM找到我，说DBA做效率，把测试环境给重置了，导致很多产品配置工作都丢失了，预计会导致近一个月的工作延期，我也就此专门和2个客户去做了道歉。昨天晚上下班后DBA来找我聊，一方面表达了歉意，另外告知了效率提升到3分钟的结论，我觉得很惊喜，因为3分钟是我能接受的底线了。DBA说，代码review的会是不是不用开了？我说还是正常开下，因为：

1）如果问题没解决，那么大家一起看看问题，群策群力

2）如果问题解决了，那么大家共享下信息，也同步一下经验，作为复盘总结

今天的代码review，人员还是比较齐的，首先在同步现状阶段就发现了一个大乌龙，原来DBA解决的效率问题并不是本次的问题，而是另一个需求。所以本次的需求，效率仍然停留在20分钟。如果不开会，大家的信息偏差就很大了。

会议中主要的结论：

1）大家给开发同学提了一些方案，开发同学继续尝试优化

2）DBA帮忙对SQL整体执行效率做分析，给出更具体的问题分析

3）我代表产品团队对研发团队明确了要求，作为互联网产品，期望报表的效率也不要低于3分钟，而且是对大数据量的报表（日常的报表应该是秒级）。

对事，容忍度要低一点！

对人，可以包容一点。

PM反馈有时候对研发同学的推动力不足，鉴于此，我在周会中，给大家分享了这个案例，同时，对于如何通过科学方法推进事情解决，总结4点：

1）拥抱问题

不要怕出问题，每一次有问题都是个人能力的试炼场，成长的机会；同时，也是对产品优化的契机

2）巧用会议

通过会议来推动事情的解决，会议以及参会的负责人，都是PM的帮手，会议代表了自己对事情的重视

3）增进联系

工作中80%的问题，都是沟通问题，要加强沟通和联系；本例中，我给2个用户去道歉，我把这当作一次用户沟通的机会，有的用户反馈激烈，我也会告知我们的复盘和改善方案

4）达成共识

最终的结果要有共识，且信息要同步，避免大家单对单沟通得到不一样的结论；同时，也可以通过会议深化沟通，对未来的产品能力做出更深入探讨。