最近读极客时间朱赟的一篇文章有感，在这也聊一下，在互联网的公司大多数以迭代的方式上线需求，节奏一般都比较快，经常会一个需求当天来了第二天就上线，开发和测试时间总共就两天，中间还穿插着别的需求测试，不像传统企业瀑布式发布需求，基本开发一个月测试三个月，中间基本不会加需求或者变更需求，所以在互联网公司的上线后经常会引起生产故障。这里不是说时间不足肯定就会泄漏故障，时间充足就不会泄漏故障。
泄漏了问题是否要追责，是否要惩罚呢
首先要明确为什么要追责，或者为什么要惩罚，追责是为了惩罚吗还是惩罚是为了更好的追责呢
设想一下极端，如果每个错误都要受到惩罚会怎么样？
- 在部门管理中，难免会出现问题大家都怕犯错误，大需求以及负责的需求没人敢做，只能指派，或者一直是“老司机”做这类需求，新人得不到锻炼，老司机也担惊受怕；
- 出了问题后会无尽的吵架甩锅丢责任，吵架会成为工作的一大部分；
- 别人出了问题也不敢指出，指出就会让对方被追究责任；
设想另一个极端，如果出了错误没人被追责又回怎样？
这里要明确一点是出了问题一定要追责，但是不惩罚，追责不是为了惩罚；追责是为了知道为什么会出现问题，相关开发人员、测试人员了解到确切的问题原因，在未来的工作，采取更多的手段和方法，避免再次出现同类的问题；
追责过程中要对事不对人，重点在了解问题原因，在流程和机制上改进，避免同类的问题再次发生，而不是指责谁代码怎么写的，测试怎么测的，为什么泄漏了问题
团队之间保持信任，追责中不能破坏人之间的信任，要不断建立相互的信任，让大家明确追责是为了找到问题的本质，避免问题再次发生，不断建立起团队不断学习、反馈、进度的一个正向循环