真实的码农职场——从生产问题到背低绩效
一个毕业整一年的同学因为在生产发布时出现问题找我吐槽，昨天先是文字聊了几句，后来我觉得这个事挺典型的，就语音聊了20多分钟，把这事记录下来，跟大家分享一下。
先说说背景：
1、前面的产品、开发把方案做好之后离职了，他才被调进这个项目，说白了是接手别人的烂摊子。
2、其它项目都有质量同事全程跟进的，唯独他这个没有，自己根据别人的方案做开发、写用例、自测，再把测试用例给质量同事做生产回归。
3、出问题的那个逻辑其实在他的测试用例中被覆盖到的，他在测试环境下自测时也没有问题，但质量同事在生产环境下回归时遗漏了这个逻辑。
4、监控配得不全，导致这个问题被发现的不是那么及时。
问题被发现并处理完之后，主管让这个同学拉会复盘、写复盘材料、补监控（包括历史上缺失的），最后还让他背了个低绩效，这个同学觉得很冤，甚至有了跳槽的想法。
这里说说我看法：
1、半路被拉进项目，按着别人的方案做开发本来就缺失了很多背景，他在过程中做得其实不错，没有栽到那些历史问题上，但最后却因为质量同事的大意导致线上问题，确实很冤。
2、出来工作就得接受安排，不管是什么样的项目，只要复杂度没有明显超出自己的层级，就应该按时保质保量地开发、上线，甚至超出了能力范围，报完风险之后也得硬着头皮啃，这个是在公司干活的现实逻辑。
3、这个同学虽然冤枉，但过程中做的也确实是有问题的，比如，功能开发完上线之后针对性的监控不全而没有评估到位。公司角度来说，生产环境出现问题定责时，不会因为自己是按照别人的方案做开发就可以不负责任了。
4、项目出现生产环境问题时，一定是相关人员共背责任，同时又有主次之分的。在这个案例中，合理的责任划分应该是：质量同事作为直接责任人负主要责任、这个同学作为开发负次要责任。
5、如果赶上打绩效，在某些强制低绩效比例的公司，碰上这种问题之后背一个低绩效在所难免，因为强制绩效往往都是在部门中逐层往下分配的，如果团队中没有明显拉跨的，那出过线上问题的人大概率就得背了。
以上是冷冰冰的分析，接下来再讲一个比上面逻辑更重要的东西。
在公司做事，KPI大棒指挥之下，所有人在做事时都是面向老板、追求结果，出现问题之后不管是惩罚还是低绩效，大家都无话可说。
但是，主管在处理这些问题过程中的原则很重要，态度更重要。把出现问题的团队成员当成活生生的人而不是没有感情工具人，这个态度是能力的一种。
对于软件技术人员来讲，什么是企业文化？不是贴在墙上的宣导语、不是老板和HR喊出的那些空洞的口号，而是在实际工作中感受到的这个组织处理问题的方法和导向，尤其是日常工作中出现问题时的团队协同是否顺利，主管对团队成员的评价是否秉持公正的视角。
#在职场上，你最讨厌什么样的同事#
投递美团等公司10个岗位