对程序员的临时性惩罚措施，你可以接受吗？

同意 ...
也包括整个项目规则的制订，我怀疑到底有没有完整的项目规定或者有没有实施  ：o

你们有系统级的功能测试吗？

要注意责任不是一个人的，作为一个Team，不论下属发生任何的问题，lead总是要担最大的责任，以此类推，一个公司发生问题，最大的责任在公司的CEO或者董事长头上。

所以不要试图找一个替罪羊。
除了这个，还有，团队成员应该是互相辅助的，你这么搞，一旦出现问题，都会极力推卸、相互指责。实数下策。这种管理上的简单方法，很难行得通的。

实际上，我就经历过这种头要我们实施这种激励措施。我是反对的。而且，我可以用这种措施之外的很多措施达到良好的激励效果。

先把其他的做好,再想这种招数吧。我觉得那些更重要。比如良好的氛围、合理的计划，考虑员工的健康和发展，授权与反馈...

对于软件工人的质量
只能抱着信任让他们去作
抱着不信任去测试.....

从没有哪个人敢说
自己拼写不会出错的....

很多时候出错应该被提前撩到

PS:同意楼上

罚钱很容易上升到原则性问题，况且测试这种东西...不要对coding的人抱太大期望...单体倒还罢了，结合还是掏点钱请tester吧...

讲一个我们组发生的故事。

我们组是两个组合并来的。原来我呆的的组，BOSS做人很有艺术性，从来你犯错不会用生硬的批评和惩罚来使你意识到错误严重性，而是各种他的亲身经历，推荐书籍，灌输细心细节思想等 (他举了不少他遇过的做砸的严重后果的项目例子)
另一个组，连做Peer的code review出错都要影响年底的performance.

以前，出了错，大家想的是怎么尽最大努力弥补，尽量减小对客户的损失和对公司的不良影响，重大错误，BOSS也是从来都追求Lead的责任，从不拿小的开刀。BOSS这么做他说，这是让大家看到，Lead不是那么容易当的，大家要服从他，因为他要替你承担责任，Lead也要负责，因为手下的人你要负责，lead不是领导，而是Lead who serves原则。你是为大家服务的。

后来合并了，原来BOSS闪人了，新的组管理风格完全变了。因为有的项目是外包，欧美 日本都需要有oniste沟通人员，如果出现了问题，经常出现offshore和Onsite扯皮的现象，因为都在推卸责任，指责对方，反而错过了修复错误的最好时机。

建议好好检查一下自己，有些环节出了问题。我觉得LZ对项目不够冷静，没有做到对事不对人，另外就是现场管理的没有做到位，还有就是感觉你和下属分的特别清楚。

单就这件事情来看，上线前的综合测试和验收测试不知道怎么做的，上线前的演练环节也没有，任何系统都有BUG，出现BUG有可能是由于程序员马虎，但缺乏必要的机制进行控制，则是系统的问题，不能靠责任心、敬业心、认真等虚的东西去降低BUG数量。不管有没有制度，项目经理自己要判断每一阶段可能会有什么风险，也要告知大家这些风险怎么去预防、怎么救火。他每天要花时间，对项目的各个环节进行检查，因为真正对项目负责的只能是项目经理自己。BUG和质量事故不一样，BUG出现很正常，不能作为考核和惩罚的依据。

但是因为项目管理和公司管理问题，导致BUG转化成了质量事故，那么就必须要惩罚，这个惩罚是针对整个项目组和公司质量管理负责人，不管公司有无条例，出了质量事故，就是项目经理的事情，因为他的管理问题，导致客户损失，考核首先会落到他的头上，至于项目组内部再怎么转嫁，那就不是公司的事情了，项目组的项目奖金都会受到影响。如果对质量事故不进行处罚，下不为例或者因为没有制度而推诿，那以后公司就不要做事了。

同时公司质量负责人必须要惩罚，因为他失职，管理不到位。

不过这种处罚不能太过频繁，处罚完了以后，后续的制度和激励要跟上，光罚不行。

惩罚是达不到目的的，Kent Beck说学习也是极限编程最重要的一环。而惩罚而非自身的反省是达不到这个效果的。

大家分析的都很有道理，不过我觉的管理也是需要成本的，小公司可能顾不了那么多，工作只能抓最主要的，出现质量事故，应该是工作流程有问题，当然也有程序员个人的的问题，此次的情况我觉的还是他个人的问题，他自己对此没有异议。
楼上几楼有一句话是最适用的，测试工作真得是从不相信别人能做好的角度去做，我想这么样，但是总不能让老板亲自去测试吧，所以程序员虽然不是测试人员，但在公司没有配备测试人员的情况下，他就有测试自己部分程序的责任，自己的部分出了问题，算在自己头上无可厚非。
这件事的关键是罚与不罚的问题，流程目前我觉的虽然不好，但是性价比还是比较高的。

软件公司没有配备专门的测试人员（无论是自己雇佣还是外包），这是公司管理层没有尽到应尽的管理责任。