被冤枉了的产品汪
共 2078字，需浏览 5分钟
·
2021-09-05 11:36
周末在后台看到一条很长的留言，一个做产品的读者说自己在工作中吃了哑巴亏，觉得很不爽，想让我支支招。
事情是这样的。
他毕业后进了现在这家创业公司做产品，到现在一年多点的时间。因为公司不大，产品研发的流程也不是很规范，所以很多事情都是口头交接。
随着项目复杂度的提升和人员的变化，一些历史遗留问题越来越多，经常是补了东墙拆西墙。
有一次在开发一个新功能时，他在 PRD 评审会上把相关的逻辑和规则都说清楚了，而且大家也都一致认可并通过，于是产品进入开发阶段。
可做到一半时，后端程序员发现一个逻辑走不通，于是找到他想修改一下方案。
商量了半天总归是想出了一个新方案，但需要前端配合修改，他随即去找前端程序员进行了沟通。
本以为问题就这么解决了，没想到产品在上线前的测试过程中发现原本要改的那个逻辑出现严重 bug，查了原因后发现，是前端没有改。
因为临近上线时间，现在修改的时间又明显不够，一度陷入尴尬。
在项目组会议上，领导挺生气，说这么重要的逻辑问题为啥现在才发现？是哪个环节出了问题？
其实他心里明白，是前端没做。可在会议过程中，前端却开始了甩锅表演。
后端说自己改完跟产品确认了，让产品跟前端去沟通。前端说产品没有确定最终逻辑，所以没做修改。
可实际上，他作为产品经理确实跟前端程序员有过沟通，而且双方就修改逻辑达成了一致。
可是，面对一个无赖，他又拿不出什么证据。既没有需求变更记录，也没有沟通记录。
作为这个需求的负责人，他只能抗下领导的责骂。但他心里十分清楚，自己是被冤枉的。
其实，这样的事儿在产品工作中经常出现，大多是因为产品经理没有做好需求管理和沟通管理导致的。
不管在多大的团队、多复杂的项目中，但凡涉及到需求变更，一定要登记变更记录。
可以是基于原 PRD 的修改，也可以单独维护一份变更文件。
这么做的目的很简单，一方面确保方案始终处于最新状态，另一方面则是作为一个辅助沟通的工具。
切记，需求变更和共识不能以口头协议的方式存在。
关于这一点，吃过亏的人都懂。
除了需求变更本身要有记录，沟通过程也要有记录，尤其是对于一些关键决策或者重要变化的沟通，一定要走正式沟通渠道。
比如邮件、会议、群聊等。
以前我在大厂工作时，任何一个需求的变更都会最终以邮件的方式备案和确认，并且会抄送双方领导以及项目相关人员。
不为别的，就是怕出问题时对方甩锅，同时也是作为沟通备忘。
你们一定体验过这么一种场景，沟通时说得好好的，但实际做的时候却走样了。
至于原因，就是从沟通到执行的过程中存在了信息丢失。简单说，就是当时的理解和现在的理解存在了偏差。
以前我觉得自己记忆力挺好的，可同时处理的问题多了以后，就发现经常会出现短路或遗漏。
所以，后来我就不那么相信自己的记忆了，反而相信笔记。
一种笔记是做给自己看的，比如一些沟通关键点、重要任务、待完成事项的备案。
另一种笔记是做给别人看的，比如一些多方共识、沟通结论、关键决策等。
对于这种给别人看的公开笔记，同时也会利用一些沟通渠道发布出来，比如邮件、群通知、会议纪要等。
在绝对信任的团队里，其实这些事情大多可以省略，可在人心复杂和事情复杂的项目中，这些却是必备工作。
背过锅的人，都懂。
其实我是一直建议产品经理有空能去学习一些项目管理知识的，尤其是关于沟通管理、需求管理、会议管理这三部分，实用性还是挺强的。
之前给你们推荐过一些不错的项目管理学习资料，应一部分读者的要求，这里再推荐一次。
特别是对于计划准备下一次 PMP 考试的同学，可以提前仔细了解下。
主讲人很多人可能都知道，张立台博士，资深项目管理专家。
张博士拥有 12 年项目管理培训经验，曾为工商总局、国税总局、航天集团、华为、中兴、朗讯、西门子、奔驰、浦发银行等提供项目管理咨询培训服务。
90 分钟的时间内，张博士会教你如何用一页纸搞定项目管理的各个环节，打开项目管理知识体系的大门。
给你们要了一些优惠价，只要 0.99 元，名额不多。
如果你当前工作中面临处理人际沟通、需求管理、风险控制以及多部门协作的问题，可以试着去了解和学习下项目管理相关的知识，还是挺有用的。
报名到课的同学还可以得到如下课程礼包。
················· 唐韧出品 ·················
需求沟通的目的不是自己表达完整，而是让对方理解完整。
很多 PM 会有这么一种感觉：我都说得这么清楚了，为什么他还是不懂？
其实不是对方不懂，而是你没能从对方的角度来解决他的疑问。当然，你也叫不醒一个装睡的人。