责任人到底需要背负怎样的责任？到底是只负责攒局，还是需要有追寻一切的执着？

在 Quora 中有这样一则提问“How well does Apple's Directly Responsible Individual (DRI) model work in practice?”，询问在苹果公司中，DRI 模式是如何运作的，刚好最近因为工作上的变动承担了越来越多的事情，觉得也有一些收获，与大家分享。

在苹果公司里，想知道“谁”负责“什么事”几乎永远不会被搞混。

在公司内部甚至对此有个专业的术语，叫做直接责任人（directly responsible individual），简称 DRI。DRI的名字经常出现在各种地方，不论是会议日程还是错误报告，只需要一眼就能搞清楚到底谁是负责人。一位前员工说：“苹果每次务实会议都会出一份行动清单，在每一次行动的旁边都注明DRI。”

在苹果内部，不论是最大的产品（如 iPhone），还是最小的动作项目或软件功能，都会分配给直接负责的人。对应的责任也一并落在那个人身上，完成它或者找到完成它所需要的资源也全部取决于那个人。

对于苹果来说，DRI 不是只是一个理念，只是一个简单的工具，它不是项目管理的过程或框架。DRI 只是一种授权工具，DRI 不需要向任何人解释他们的决定。如果你强迫 DRI 解释太多，你就会刺激他们在雷达监控下发布项目。对陷入解释的无休止循环的恐惧会使 DRI 偏离轨道，导致人们推迟行动而不是带着行动的偏见工作。

这一点其实与公司常见的“透明”有一定的区别，有时候任何人都能问你一件事，并且强迫你必须向他们解释原因并不见得能获得什么提升。

具体来说，DRI 解决的是下面这些问题：

一、在解决一个复杂的、跨团队的工程问题时，你需要一个 DRI，由他驱动团队，直到问题得到解决。

通常这是一个工程负责人，项目经理或产品经理所肩负的职责。假设我们遇到了一个机械工程问题，涉及到硬件部分。那么通常产品设计工程师将是 DRI，他们将与硬件工程师一起解决问题。如果在原型测试生产线上出现故障，那么你可以让 TPM （测试程序经理）作为 DRI，与苹果工程团队、测试设备供应商和合同制造商团队一起工作。

二、当不清楚谁负责此事，以及接下来要做什么的时候，你需要一个 DRI 。

当你相信你的 DRI，你不必担心当你没有看到任何关于这个问题的最近进展和事项。你应该假设他们已经找到了一个依赖项，并且正在等待它先发生，或者他们正在做一些幕后工作，这些工作将被证明是有用的。这不仅可以让其他从事同样问题工作的人放心，而且还有助于跨职能管理层清楚地了解到底是谁在推动什么。不仅仅是“ marcomm 团队”，而是一个特定的人。

三、当每个人都知道某件事很重要，但是没有人觉得自己有责任了解全部的时候，你需要一个 DRI 。

在一个快速发展的公司里，有大量重要的事情被搁置，不是因为人们不负责任，而是因为他们真的很忙。DRI 这样做的好处是更多的是权力而不是责任。当你觉得某样东西是你的心血时，那么你就真的真的关心它是怎么做的。当你取得一些伟大的成就时，你会沉迷于度量标准，追踪问题，团结人们，想为他们做些你竭尽全力能做的事情。

在苹果，到处可以听到这个常用词，如果有人想了解某个项目的直接联系人，就会问：“谁是那个项目的DRI？”

当然，使用 DRI 对团队来说也是卓有成效的，因为你不需要 15 个人都在担心同样的事情。相反，工程师可以很轻松地专注于手头的挑战。同样，在 Gitlab 中，DRI 也有相关的落地案例，比如：

一个 DRI 在 GitLab 不需要解释为什么他们正在做一个决定，他们也不需要说服其他人。对于 DRI 以外的其他人可以提供意见，但是并没有权利去感受被倾听或者在最终的决定中被考虑。

虽然乍一看可能会削弱团队有效合作的能力，但这其实代表你对于 DRI 的理解才刚入门。DRI 应该全身心投入到他们的工作中，能广泛协同。当他们被授权做出最终决定时，他们应该知道如何以及何时相信其团队和同事的经验和判断。

此外，Mike Brown 也在其 2015 年的文章中，认为一个优秀的 DRI 需要具备以下特质：

  1. 细节导向，兼具战略视角。
  2. 在执行和截止期的压力下保持冷静。
  3. 有很强的倾听能力，且善于提问。
  4. 能够以明智的方式改变项目（或策略或任务）的方向，以继续朝着目标前进。
  5. 擅长预测潜在问题，并及早解决。
  6. 能够在组织内成功地与高层和初级员工沟通。
  7. 从挫折中恢复的弹性。
  8. 在相似场景下的反应保持一致。

DRI 的理念是现代产品开发团队文化的基本组成部分。通过寻求建立一种团队责任文化，我们避免依赖管理人员告诉团队该做什么，并增加对团队自我组织和知道如何进行的依赖。