责任归属制度

    在现代社会协作模式中，责任既然难以避免，就需要规范化问题发生时的责任归属制度，达到有法可依。作者认为，责任归属的非常好的实践应该是如下（但不限于下面几条，篇幅关系介绍下面几条）：

    · 制度1：责任发生时，首先应该确认责任的根源 - 即外部问题导致，还是内部问题导致？并进一步分析。尽管是外部问题导致，是否可以通过内部的变革来改进自己？而不是被一些外部环境假象蒙蔽，导致放弃组织自我的剖析与改进。可以想象如果所有人都推托外部原因（外部原因一般无法改进），则组织就缺乏剖析与改进的动力。

    下面是网络上很流行的另一个故事，用于作为第一条制度的反面例子再好不过了：在一个公司的年度会议上，营销部门的经理A说：“最近销售做得不好，我们部门有一定责任，但是最主要的责任不在我们，竞争对手纷纷推出新产品，比我们的产品好，所以我们很不好做，研发部门要认真总结。”，研发部门经理B说：“确实，我们最近推出的新产品是少，但是我们也有困难呀，我们的预算很少，可就是如此少得可怜的预算，也被财务削减了！”；财务经理C说：“是，我是削减了你的预算，但是你要知道，公司的采购成本在上升，我们当然没有多少钱。”；采购经理D忍不住跳起来：“不错，我们的采购成本是上升了10%，可是为什么你们知道吗？俄罗斯的一个生产铬的矿山爆炸了，导致了不锈钢价格的上升。”。

    最后A、B、C说：“哦，原来如此呀，这样说，我们大家就都没有多少责任了，哈哈哈哈……”。

    最后这个年度会议最后的结论是：俄罗斯的问题。

    · 制度2：确认责任根源后，应确认确认谁是主要责任，谁是次要责任。现在的组织管理是团队协作模式，多人共同承担一个工作。当发生责任时，肯定会同时涉及到多个责任参与方。但责任是有主次之分，谁是该责任范围内的主要负责人，谁就应该承担这个主要责任，其余的责任参与方成员则承担次要责任。

    比如：一个公司举行营销展览，在一个大型展览馆展示公司的最新产品，该活动分两个部分，由两位领导分别负责，两部分分别为：宣传以及客户接待部分，这部分负责将尽可能多的目标客户带领进展览馆，特别是客户的高层；另外一部分是展馆管理，保安，讲解，以及可能的销售机会记录。

    但是在营销展览的第二天，发生了一个事故，最新展览的产品以及资料在展馆内失窃，该产品和资料是公司的高级机密，是本次展览的重点。

    失窃事故发生后，谁应该是主要责任呢？负责展馆管理的领导试图把责任转移到负责宣传以及市场活动的领导身上，抱怨其接引了小偷进展览馆，造成了产品及资料失窃。诸位觉得这样的责任转移合理吗？作者觉得，这样的责任转移是不合理的，这样的事故并不是发生在模糊地带，负责展览管理的领导应该负主要责任，所以应由其担负起责任。

    当然，如果本次展览来访的客户都是级别较低，没有太多客户的高层参加，最后造成最后展览效果不佳，这样的责任则是负责营销和客户访问的领导人的责任了。

    实际上，类似的情况在组织中也是时常发生。如，组织中有负责支持客户的员工和管理产品的员工，负责支持客户的员工，把客户的问题以及需求整理并发回到产品团队，但是最后产品在这个客户的支持中由于问题以及需求过多，导致了把一些不合适的功能加入了产品中。诸位觉得这样的问题，又是谁的责任呢？根据作者上面的模型，作者觉得这个事故的产生是产品管理人员的责任，而非客户支持员工的责任。因为客户支持人员把客户的问题、需求梳理并发回；而产品管理人员则需要进一步去执行其职责，对产品进行相应的分析并最终确定如何修改产品，最后产品出了问题，应该是产品管理人员的主要责任。就犹如上面说的，展馆的机密失窃，如何能是外面负责营销和接送客户的领导呢？

    · 制度3：确认责任根源后，应确定该责任是否发生在责任模糊地带，如果责任发生在模糊地带，无法确认谁是主要责任，谁是次要责任，则应是模糊地带的领导的责任，因为领导的一个重要责任是要制度化组织中的管理，使得组织尽量存在少的模糊地带，而达到规范化管理的目的；如果无法制度化的地带，应该激励员工主动的去解决问题，或协调员工解决问题。所以，当找不到谁的责任的时候，就肯定是这个项目的领导的责任。

    比如，一个软件开发团队有开发人员，测试人员，以及Build人员。Build人员把开发人员开发出来的代码进行自动化编译，并生成安装包（生成的安装包里面有一些是产品发布申明和安装文档)，以便测试人员进行测试。但测试人员的测试中，并不包括去查看Build出来的javadoc文档是否正常显示。

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

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

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

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

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