责任分散

“责任的扩散”一词指的是一种心理现象，其中重要的任务被遗弃，因为每个相关人员都认为处理它是其他人的工作。

不幸的是，这种萎靡不振是许多工程团队的祸根。这就是为什么仅涉及几天实际编码和测试的任务通常最终需要几个月的日历时间才能完成。

虽然我不是互联网模因的主要爱好者，但我创建了一个小图像，我觉得这个图像充分总结了我对软件开发团队中观察到的各种病态的看法：

抛开所有的幽默，有理由为什么这种事情经常发生。主要原因是整体任务复杂性，以及任务规划人员无法全面捕获完成任务所涉及的所有次要子任务。

例如，假设Alice，Bob和Chuck正在互联网创业公司工作。 Alice负责服务器代码，Bob编写HTML和JavaScript，Chuck负责devops和部署。他们正在忙于处理一项新功能，因此他们根据分配的角色划分了他们之间的工作：

不幸的是，正如你所看到的，整个任务中有很多灰色区域，而这些灰色区域并没有被分配给Alice，Bob和Chuck的工作所覆盖。

当产品经理问“为什么不完成任务X？”时，爱丽丝会如实地说：“好吧，我的部分已经完成了”，鲍勃和查克会说同样的话。

这里的部分问题是没有人 owns 整个任务。 “拥有”我不是指产品经理;我的意思是有能力采取具体行动推动任务向前发展的人。在我们的假设情景中，没有人对灰色区域负责，因此工作无法完成。

这里的另一个问题是Alice，Bob和Chuck都是 heavily siloed 。每个人都有一个指定的领域或舒适区域，很少偏离它。 Alice在服务器代码上工作，并且不习惯使用devops或客户端代码; Bob对服务器编程一无所知;而且Chuck对两者都有所了解，但对于闯入Alice和Bob的域名感到紧张。

此外，Alice，Bob和Chuck都在制定不同的时间表;除了这一功能外，还有许多其他工作要做。爱丽丝可能已经尽早完成了自己的工作，但鲍勃正在忙着处理一个高优先级的错误，并且可能不会再继续他的工作两周了。在鲍勃的工作完成之前，查克甚至无法开始。因此，即使工作可能只需要一两天的个人努力，完成项目所需的时间为三到四周。

另一个问题是所涉及的个人可能甚至不知道灰色区域存在。在上图中，显而易见的是，有三大工程师没有涉及大量工作。但是大多数任务描述都不是图表，它们通常是项目符号列表，电子表格中的行或者票证跟踪系统中的任务。他们往往看起来更像这样：

以这种方式呈现，完全没有明显的任务缺失部分。

这就是为什么“全栈工程师”近年来成为如此备受追捧的角色的原因之一。当一个人在整个任务上工作时，他们不仅创造已识别的单个部件，而且还迫使他们实施所有将这些部件绑在一起的“粘合剂”。

（当然，缺点是单个人不能扩展。本周只有这么多小时。）

没有能够做任何事情的“超级程序员”，另一种方法是更好地分割任务，以便不遗漏任何东西。如果涉及将客户端代码与服务器API集成的工作，则应将其包含在任务列表中。

避免这类问题的最佳方法是要意识到它们会发生，并在规划期间尝试对它们进行补偿。人类是错误的，这就是为什么我们发明了诸如复式簿记和科学方法之类的东西：帮助我们弥补我们的认知缺陷和观察偏见的技术。 负责人的扩散