我是如何避免制造“产品事故”的
事故并不可怕，可怕的是，事后并不懂得反省。
对于一家互联网企业来讲，服务器并发未处理好导致宕机，那属于“ 技术事故 ”，商城首页的商品和价格对应不上，那属于“ 运营事故 ”，错误的执行了错误的产品设计，造成用户流失，那属于“ 产品事故 ”。
在我不长的产品生涯中，也曾遇到过大大小小的“产品事故”，下面我将分享一段经历，以及在这件事情上自己的一些思考给大家。
我经历过的“产品事故”
2015年，我在腾讯旗下某2B软件的代理公司做CRM，当时是个小研发团队，加上项目经理18个人。
项目经理是腾讯下来的，高度提倡敏捷开发，一周一个小迭代，两周一个大迭代，通常是上一个迭代内容刚测试完成，下一个迭代内容就开始宣讲了，团队的研发人员一直处于工作量饱和，节奏快得工作状态。
正式在这种开发背景下，促成了一次严重的事故，当时那个需求的重要性很高，所以是产品总监牵头负责的。
我们的需求评审通常是各部门Leader一起参加，该需求最初是Boss直接提出的，在评审的时候发现产品功能与期望的需求有偏差，因此产生了严重分歧。
进一步导致技术实现上也产生争论，10个人参加的需求评审，出现了10种不同的声音。
那段时间开了无数次的碰头会，搞得大家都很精疲力尽，所以到最后也没有出现一个“ 大家一致认可 ”的方案出现，感觉总有漏洞，但是时间紧迫，没办法只能“跟着感觉走”让开发做了一个心里没谱的版本上线。
刚上线一天，大量数据涌入，严重的缺陷瞬间暴露，造成公司那一天的退款订单比平时一个月都还多。
Boss大发雷霆，产品总监事后主动辞职。
这次事故让我明白了什么？
首先要说服自己
我对PRD文档的理解，其实里面的内容是给自己看的，写的过程其实是，帮助自己梳理思路的过程。
一个PRD文档，上午写完趁热看，感觉很完美，下午再来看一遍，就会发现问题。
一个点，也许会被自己推翻很多次，只有当自己也推翻不了自己的时候，才说明那个点已经可以曝光给其他人了。
自己还没想清楚，就别拉着大家开会
开会的目的无非就是向一群人详细的表达自己的想法，或联合一群人来头脑风暴 ， 需求评审会议明显属于前者 ， 别把评审会开成了”大家来帮你思考的讨论会”。
频繁交流
产品经理是“无冕之王”，我们是没有实权但是又可以是站在公司最耀眼的地方的人，我们能驱动公司的资源来帮助落地我们脑子里的想法，靠的不光是思考，还有沟通。
“思考再多，不说出来等于不思考。”
持续跟踪
需求交付给设计和开发以后，应该持续跟踪，以保证实现的方式跟需求是吻合的。
人与人之间交流，内容传递是一个衰减的过程，你想的和你说的，以及对方听到的，可能内容都不一样。
那么，该如何避免制造事故的？
需求采集阶段
需求一定是采集来的，而不是自己 凭着主观意识和想当然的同理心 去设想出来的，采集需求一定要客观，只有客观才能最贴近真实需求，只有贴近真实需求，才能保证接下来的工作路线是正确的。
运营部反馈了一个问题：“用户觉得这个地方字太小，内容又多，操作起来很麻烦，看久了眼睛又花又累。”
如果单纯听取运营部的想法，以及主观思考来分析，很容易“误入歧途”的认为，只要“通过优化UI清爽界面，或把一个页面的功能拆分为两个页面来完成” 就能解决用户这个需求。
其实只有去拜访用户，面对面交流，观察以后，才会发现用户的真实需求为：在Web端上开发出这个功能，因为能用电脑操作，屏幕大。
如果把产品经理的工作看作是修路，终点是“满足用户需求”，那么需求采集阶段就是修路的第一段，我们的理解和看法，产生的思考结果，将决定这条路的方向。
思考实现的方法，实现的路径，实现的难度，资源的分配，就如盘上公路一半，S型的蜿蜒盘旋，绕过一个又一个的“雷区”。
只有思考的越透彻，那后面的杂音才会越小，落地的速度才会最快。
分析与设计阶段
需求分析与设计，是产品工作中很重要的一部分，这里产出的内容， 将决定公司接下来的营销、运营、研发等资源的调配与消耗， 所以需求分析一定要谨慎，产品设计一定要匹配。
- 学会频繁的梳理自己的PRD文档，也许每过一遍，就会修复一些逻辑缺陷，或者产生更好的想法来调优方案。
- 拿捏不准的和概念模糊的，学会请教相关的人，描述想法给他人，以验证对方案的设想是否正确，只有得到验证才好大胆的去实现。
- 对自己批判性思考，学会问自己“ 首先 是这是不是真实需求， 其次 是这样解决的可行性如何？ 最后 是这种解决方案在逻辑上是否合理”。
- 开需求评审会以前，尽量先跟参会的关键人员们通通气，分歧和不统一的意见，尽量放到台下来解决，减少会议上的杂音。
今年年初，我牵头负责了我们产品“钱包”功能的重构设计，以下是这期间我的大致工作流程：
如果前期我“听风就是雨”，做的验证不够就拿到台面上来宣讲，那么带来的结果：
- 可能与财务系统有冲突。
- 可能技术实现有困难。
- 可能不符合公司运营方案的策略。
- 产品思路有问题，缺陷明显。
- 上线后问题暴露，伤害用户，造成损失。
作为产品的第一负责人，只有严谨的做事方式去避免出现“产品事故”，才能有机会站在台上，被众人所注目，被聚光灯所照亮。
如果只能做螺丝钉，也要做一颗有思想的螺丝钉。
文/拥抱变化
关键字：产品经理, 需求
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
