吃力不讨好

话说2018.07.31的x安公司的谢XX和李XX，在摄像头下两人进行了比较随心所欲的肢体接触，网传是因为产品经理要求程序员实现APP主题根据手机壳变颜色的需求，程序员忍无可忍从而释放自我的过程。当然这是网传版本，据说完全不是那么回事。

但是为什么这个事件就那么红呢。我觉得有两方面的原因：

1. 程序员一向是被整个社会调侃最多的职业之一（之一比较谦虚），热点够大。
2. 网传的需求太他么奇葩，迎合了大多的吃瓜群众。

作为程序员其实我们为什么也觉得有趣，是因为产品和程序员多多少少都会有不对付（矛盾）的情况发生。这件事刚好映射了此情况。我个人觉得该矛盾的核心点还是在于同理心这一点上，双方好像都很难理解对方。其实主要就是很少站在对方的角度和位置上，客观的理解对象所说的事情。

讲的有点多了，为什么想说”吃力不讨好”，是因为本周周会复盘时，刚好遇到了一个同事出现了此情况，当事人肯定很难受也比较委屈,这位同事暂时起名小波，方便叙述。

当然这篇文章主要是站在技术人员的角度写的，其它职位的待我深入了解后再有资格叨叨。

为什么需要复盘一下呢，明面上的原因是小波任务delay了进而导致周目标delay了，在PO验收时结果有些不太理想。所以SM就拉着大家做了一下复盘，
流程是：

• 首先小波先说明一下整个delay的原因
• 分析根因
• 大家发表一下看法和建议
• 形成改进项或者规约之类的东西
• 团队是否认同
• 改进项的责任人进行跟进

大体的原因是在于，小波在研发时，鉴于程序员的伟大使命感，总想着抽象进而方便后人，但是在研发前期准备时不管是关键路径还是详设，都没能体现这块内容，关键是这块内容占用的时间还比较长，所以最终导致整个计划delay。这本身不是个问题，因为想法时好的，问题在于这是个”吃力不讨好”的事，因为这是过程产物，PO等人是看不到的，更大的问题是小波没有和任何人进行同步，一个人吭哧吭哧干了半天，那就大家都不知情，所以导致他很被动。

所以我给的建议是：

1. 吃力不讨好的事一定得让干系人知道，好事不留名大多数情况下是扯淡的说法。
2. 自己得有一定得心理准备或者做一定的心里建设，因为既然是吃力不讨好的事，那就不能指望所有人能念你的好。

当然最终团队形成了一些改进项

1. 尽量提前在”关键路径“阶段列出所有研发内容，功能性的和非功能性的，使后面的工程计划能更加准确。
2. 定义承载过程产物的文档格式以及标准，目的是为了体现研发过程。
3. 周目标的check标准更加细化，能提升更早暴露风险的时间。
4. 当在研发中遇到此类问题时，一定要马上同步到相关的人，评估计划方案之后再动手。

本文引用的内容，如有侵权请联系我删除，给您带来的不便我很抱歉。