接上文，那么我们应该怎么做？怎样才能把惩罚和故障率挂钩起来？本文的第二个阶段，要回答几个问题：
1）到底要不要建立对技术人员的惩罚制度？
2）在什么情形下，应该对技术人员进行惩罚？
3）考核的方式有哪些？
4）惩罚的方式和手段有哪些？
第一，管理学上提倡奖惩分明，做好了奖赏，做错了惩罚，这个毋庸置疑。技术人员做了错事，也要惩罚。这没什么问题，技术工作者和其他职业，并无区别。
第二，在什么情况下，应该对技术人员进行惩罚？我认为，对于普通的技术人员来说，有下面两种场景应该进行处罚：
1）有明显过错并导致不良后果（系统故障或公司财产损失）的时候。此处的明显过错，不是指代码BUG之类，而是指不按规定的流程规则操作，或者不遵从开发指南，或者不服从上级指令导致问题等。
2）长期的粗心大意，经常导致不良后果的。任何一个开发人员的代码都可能会有Bug，再认真细致也可能会产生Bug。但是如果一个员工经常性的产生bug，或者产生的bug格外多，就有点问题了。或者是该员工性格不适合做编程工作，或者是该员工对工作太随意。
第三，考核的方式有哪些？
1）最主要的考核是上级考核。如果所在团队比较独立，直属上级领导力较强，就由直属上级直接考核；如果所属团队独立性不那么强，工作同时受直属上级和间接上级领导，那么就由直属上级和间接上级共同考核。
2）次要考核是团队考核。这个团队的工作没有达标，那么整个团队的绩效都给低分，团队成员的绩效也都受影响。团队绩效未达标时，团队负责人应该负首要责任。
那么考核方式怎么和系统故障挂钩呢？
很简单，如果团队有责任保障系统稳定运行，同时外部环境也没有干扰，那么系统故障较多就应该扣减团队的整体KPI。反过来，如果外部环境很差，比如系统受第三方影响很多，团队任务难度高而总是时间紧，外部组织没有给予团队合理的支持，那么就应该适当的降低对系统保障的要求。这个原则对个人也是一样的。总结地说，故障责任对绩效考核仅有参考依据，但不作为主要和关键依据。
第四，惩罚的措施有哪些？直接扣钱行不行？惩罚一般有如下的形式：
1）直接的，公开的批评。在故障复盘会议上，明确指出责任，提出批评。
2）经济上，在奖金评定时，考虑该团队和员工的贡献和过失，贡献少而过失多，应减少奖金发放。这一点尤其应注意避免“做的多错的多最后惩罚多”的情况，应以贡献大小来决定。
3）直接发红包，请吃饭。有些问题已经强调过很多次，有明确的流程规范来避免，但是员工不注意不遵守，那么导致故障或损失了，就可以在组里发红包或者请大家吃饭。以这种方式来提起大家的注意。
对员工进行惩罚的几个原则：
1）首先惩罚制度要适合现实情况，要清晰，明确，公开，客观。这个很不容易做到。首先要根据现实情况提要求，建标准。比如如果团队整理实力比较弱小，就不宜提过高的要求。惩罚制度还要公正，各个团队一视同仁，不能出现“双重标准”，只要求某个团队“勇于承担责任”的情况，如果最后做得越多错得也越多责罚得越多，那以后再冲锋谁也不上了。制度建立后，要取得骨干员工的支持，并且向整个团队宣传。还要给一定的适应时间。
2）涉及到金钱的，一定要提前和团队成员说清楚、约定好，要大家都同意。不能搞突然袭击。
3）要求灰度。有些事情是难以精确量化的。模棱两可或者有争议的时候，千万不要把重点放在责任划分上，而应该把重点放在以后预防问题上。
4）对事不对人。重点强调是为了避免未来问题再次发生，而不是针对这个人的打击。
