有出现了一个问题，客户反馈说新版本的软件中，少了一些javadoc文档。这样的一个问题，是谁的责任？

首先，这是一个典型的责任模糊地带事件，因为以前的流程中并没有去规范谁来负责文档的正确性。而Build人员由于要生成几十个开发人员的Javadoc，其中超过几万个的文件，也不可能一个个文件地去查看是否都正确生成并显示正确。所以才导致了这个问题。

好的解决方法是：Build人员Build出安装包后，测试人员不仅测试软件运行正确，还应加一些test case测试javadoc是否也显示正确。

所以，当发生这样的事件的时候，首先应该是流程的错，因为责任发生在协作的模糊地带，以前没有人注意到问题，也没有试图协调过分工，所以这也是一个组织改进流程、规范化管理的地方。如果真要追究责任，根据作者的制度应该是领导的错，而不是责任集中到部下。

· 制度4：模糊地带的责任，领导不能找部下“背黑锅”。我们知道领导职责比部下大，领导的职责的每一部分都能找到相应的部下对应，所以如果领导要进行责任集中找人背黑锅是很容易的。但发生在模糊地带的责任，不应当推托给部下，应该自己承担其这个责任，并利用这个机会改进组织制度，不然长久以往你的领导的实际领导力会随着你的推卸责任而慢慢流逝。

终受益人与终受害人

制度不是的，并不能规范责任归属的方方面面；另外制度也是冰冷的，过多的制度会使人失去热情和工作的激情。

作者熟悉的一些组织中，为了防止扯皮与内耗，后演变成法庭式的管理-凡事都要讲究证据。你和同事达成的口头讨论结果，几天后或几个月后，也许大家都会忘记或不承认，更不用说生效了，事后如果出了问题，你没有会议记录，也没有录音证明，这个黑锅你背定了。所以在组织中你要时刻保持着各种邮件记录，而且任何的决定都要通过书面的形式，会议的形式决议集体通过。

后结果可想而知，会议多起来了，邮件也多起来了，决定的人少了，谨慎的人多了；而组织的效率低下了，激情低下了，创造力低下了，主动性更是无需多说了。

所以除了制度规范组织行为外，有远见的还需要为组织赋予一种精神——职业化精神。让组织的成员学会负责人的主人翁精神，学会自我管理，负起主人翁的责任精神，乐于去承担责任，积极主动寻找组织中可以改进的地方，尤其是责任模糊地带。

我经常和我的同事们一起探讨“终受益人”和“终受害人”的思想，让他们明白负起责任，甚至负起本不属于自己的责任时，终的受益人是谁，为什么要去负责任！

“终受益人”的概念是前阵听厉以宁教授讲的，印象至今深刻。“终受益人”指的是一项政策或一件事情背后终收益的是什么人，明白“终受益人”后在执行一个任务的过程中要时刻记住谁才是政策的“终受益人”。有个故事很深刻的说明了这个“终受益人”的道理：

鲁国以前有条政策，是说如果鲁国人到其他去，发现有鲁国的奴隶的话，那帮他赎身，然后回鲁国找报销。，子路帮个鲁国奴隶赎身后，说不要报销。然后人们都称赞他品格高尚。但是孔子却把子路找来骂了一顿，说他应该找报销。子路不解，说那样不是高尚品格的表现了。孔子说：你这样做的确能显示你的品德高尚，但是你有没想到，如果以后再有人帮奴隶赎身，会有顾忌；若不找报销，能显示品格高尚，但是自己的钱没了还是很心痛。如果找报销，那显得自己品德不高尚了。那在进退两难时候会则么做呢？答案只有一个，那是看到奴隶不帮他赎身，当作没看见，不会有进退两难的困难了。但是奴隶不会被拯救，更多的奴隶会继续处于苦难当中，所以你应该去报销。

这个典故中，鲁国的这项政策的终受益人是奴隶，而不是救赎奴隶的人，如子路。所以在执行这项政策的时候应当记住谁才是政策的终受益人。

回到我们的责任归属问题，我们做为员工应该清晰的认识负责任的终受益人是谁？是那些偷工减料，不承担责任的那些员工吗？还是部门领导？还是公司？

我觉得都不是，负责任态度和行为的终受益人是你自己，一个负责任的人在组织中将得到多的锻炼和成长，终在不断的负责任的项目中，越来越多的需要负责任的精神的重担中，成为一个有理想有能力的职业人：

1.负责任能够得到更多的锻炼，作者认为组织中的领导力分职位带来的领导力和能力带来的领导力。一个员工有经理的职位，不代表是有领导力。

产生领导力的熔炉只有三种条件：逆境，组织停滞不前，组织找不到方向。其中不存在职位这一项。这三个熔炉中一个必须的前提是一种职业化的精神——负责任的主人翁精神。只有存在这样的精神的人才会勇往直前，在熔炉中不断成长、锻炼，后成为一个真正有领导力的人。