不正确的惩罚方式，会让团队不敢承担更多的责任，会让团队不能正面问题，削弱改进的积极性，导致逃避责任、推诿扯皮的情况，这是工作改进的敌人，这是需要坚决反对的。
激励或者惩罚层面的问题，往往是管理层面或者领导层面的问题。
从技术层面，我们应该关注那些方面的问题呢？
1. 不能直面自己的问题
有些技术人员艺高人胆大，对自己的代码过度自信；有些技术人员过度爱惜自己的羽毛，害怕暴露自己的问题会给自己的发展或者面子带来不好的影响；有些技术人员可能认为自己的工作不是导致问题的直接原因，是别人工作引起的问题等等，这些方面的问题都会导致技术人员不能直面自己的问题。
2. 把问题简单化
把故障原因归到一点，例如是研发代码的问题，认为把代码修改过来就可以了，而不能从设计、测试、部署、运维整体过程去系统思考问题，这样会导致把问题简单化，不能从根本上系统性的解决问题。
3. 把问题复杂化
另外一种极端情况是，在复盘报告里面把出问题的原因归结为系统过度复杂，不是个人或者团队的能力能够解决的问题，认为个人和团队已经很努力了，想不出解决方案来，例如一个部署的问题，把原因归结为工作量大，运维的设备成千上万台，开发的应用几十万行代码之类的，配置过程极度复杂等原因，这些都不是发生问题的原因。
4. 把问题归到配合方
有时候故障复盘会把问题归结为配合方配合不力，或者是外包、厂商的问题，无论是是谁的问题，都是系统的问题，都应该以我为主来考虑问题，即便是外包方的问题，也是主管方管控不到位的问题。
5. 把问题归到外部环境
技术人员有时候会把问题原因归结为测试环境不具备，或者是测试数据与生产环境不一致，测试用例不能够覆盖全部等，这些原因可以理解为主观不努力，或者是事先没有完备的方案。
6.把问题归到历史
把问题归结为历史问题原来没有发现之类的原因，本质上都是系统上线前的质量问题，或者是带病上生产的问题，这些要从研发测试运维各个方面来进行分析。
7. 把问题归到个人
把问题归为个人原因有时片面的，只要不是个人主观故意或者恶意的明知故犯问题，要考虑对个人的能力，对个人的支持力度，从团队角度考虑问题，不能甩锅给某个人，或者让个人当替罪羊，如果是让一个人负责的话，那这个人一定是团队负责人，所谓的背黑锅我来，干活你去的唐僧大无畏精神。
