我是如何避免制造“产品事故”的思维导图

项目经理是腾讯下来的，高度提倡敏捷开发，一周一个小迭代，两周一个大迭代，通常是上一个迭代内容刚测试完成，下一个迭代内容就开始宣讲了，团队的研发人员一直处于工作量饱和，节奏快得工作状态。

正式在这种开发背景下，促成了一次严重的事故，当时那个需求的重要性很高，所以是产品总监牵头负责的。

我们的需求评审通常是各部门Leader一起参加，该需求最初是Boss直接提出的，在评审的时候发现产品功能与期望的需求有偏差，因此产生了严重分歧。

进一步导致技术实现上也产生争论，10个人参加的需求评审，出现了10种不同的声音。

那段时间开了无数次的碰头会，搞得大家都很精疲力尽，所以到最后也没有出现一个“大家一致认可”的方案出现，感觉总有漏洞，但是时间紧迫，没办法只能“跟着感觉走”让开发做了一个心里没谱的版本上线。

刚上线一天，大量数据涌入，严重的缺陷瞬间暴露，造成公司那一天的退款订单比平时一个月都还多。

Boss大发雷霆，产品总监事后主动辞职。

这次事故让我明白了什么？

首先要说服自己

我对PRD文档的理解，其实里面的内容是给自己看的，写的过程其实是，帮助自己梳理思路的过程。

一个PRD文档，上午写完趁热看，感觉很完美，下午再来看一遍，就会发现问题。

一个点，也许会被自己推翻很多次，只有当自己也推翻不了自己的时候，才说明那个点已经可以曝光给其他人了。

自己还没想清楚，就别拉着大家开会

开会的目的无非就是向一群人详细的表达自己的想法，或联合一群人来头脑风暴，需求评审会议明显属于前者，别把评审会开成了”大家来帮你思考的讨论会”。

频繁交流

产品经理是“无冕之王”，我们是没有实权但是又可以是站在公司最耀眼的地方的人，我们能驱动公司的资源来帮助落地我们脑子里的想法，靠的不光是思考，还有沟通。

“思考再多，不说出来等于不思考。”

持续跟踪

需求交付给设计和开发以后，应该持续跟踪，以保证实现的方式跟需求是吻合的。

人与人之间交流，内容传递是一个衰减的过程，你想的和你说的，以及对方听到的，可能内容都不一样。

那么，该如何避免制造事故的？

需求采集阶段

需求一定是采集来的，而不是自己凭着主观意识和想当然的同理心去设想出来的，采集需求一定要客观，只有客观才能最贴近真实需求，只有贴近真实需求，才能保证接下来的工作路线是正确的。

运营部反馈了一个问题：

今年年初，我牵头负责了我们产品“钱包”功能的重构设计，以下是这期间我的大致工作流程：

如果前期我“听风就是雨”，做的验证不够就拿到台面上来宣讲，那么带来的结果：