通过落实责任，以责任方的角度出发，确保工作中消息传递/任务传递成功的工作方法。

一个人，有需求发送给其他人，并期望一个结果的情况。

• 【平级的串行任务】执行者 –> 执行者
• 【上至下的分派任务】上级 –> 执行者
• 【里至外的申请任务】执行者 –> 其他接口人（如财务，乙方）

在工作中，与人交接经常会出现一些情况：

• 我以为你知道。
• 你一直没回复。
• 你完全做错了方向，我要的不是这个。
• 等等

发生这样问题的原因，可以从几个角度拆解：

1. 能力问题
2. 信息误差
3. 客观环境问题

实践中，我们发现大部分情况下问题都源自于2，属于信息误差。所以为了尽量避免2的产生，就产生了当前课题与模型。

学会本模型，好处有：

• 【从个人角度】学会SRC工作法，避免出现信息传递问题。
• 【从领导角度】学会SRC工作法，明确责任点，降低任务沟通损耗。
• 【从工作流角度】将SRC融入到工作流程设计中，能够尽量确保任务信息传递正确到位，降低信息传递的误差损耗。

我们的目的时降低信息误差，先单纯的看信息误差的参与者以及他们的关系。 有：

• 信息发送者
• 信息
• 信息接受者

信息本身是客观的，但发送者的表达是主观的，接受者的理解也是主观的。

所以为了该题可解，我们强制确定了责任，制定了第一条规则：

举例：如果领导布置了一个任务，员工没有理解就开始做，责任在领导。

因为只有把其中一方的信息作为参考系，才能对比出接受者理解的信息是否产生了误差。 同时又因为，大多数情况下，发送信息的人拥有更多的信息、经验或能力。

当我们确定了信息误差的责任人是信息发送者后，我们就可以以发送者的角度出发讨论该问题，接下来用：“我”。 当我想要发送任务，且不希望发送任务有信息误差时，我会进行如下步骤：

1. 判断任务难度与我的预期
2. 判断对方与我的信息公有集

因为难度是“主观”的，比如：“帮我买个西瓜”，有的人有挑选西瓜的独家秘诀，此时安排的人如果“不知道”，则完成的任务就变得“很难”。

已知命题：

人的思想不可观测

所以，执行者是不可能在我没有阐述清楚任务期望的情况下，知道我在想什么的。

这也是责任人一定要是发送者的原因。

自然的，当我分析一个任务时，我就会思考我脑海中的评判标准是否“普世”的，哪怕是“普世”的，经常也会出问题，因为这是“我的常识”，而不是“执行者的常识”。

所以当发送一个任务时，通常都需要发送者描述“目的与预期”。

这样还有一个好处，当我作为发送者，在发送任务时被强制要求思考“目的”与“预期”时，就变相强制我检查一遍“需求是否合理”。

举例，音乐或者美术是偏感觉的，作为非专业和的需求发起者，我很难用专业的角度去干预制作。

此时，我就会说清楚我会用在哪里，希望达到什么样的感觉，至于专业方面，我会完全相信专业老师，保持闭嘴，最终以“自己的感觉来验收”。

再举例，我要分派一个系统任务给系统策划设计，此时我会阐述清楚为什么要有这个系统，以及我希望这个系统达成的目的。这样就能够让执行者参与思考，避免纯粹的成为“执行”。

但最终的好处，是消除信息误差，确保执行者理解我的意图，减少不避免的返工与事故。

得到回复有两种情况：

1. 得到预计完成的时间。
2. 得到关于任务的理解。

哪怕再简单的一个任务，如果我期望一个结果，那么我就需要得到回复，比如“你什么时候完成，我到时候来找你。”

其中“什么时候”是关键，

这不是绩效，不怕延迟，但一个人一旦答应你了具体时间，责任就变得十分明确，哪怕拖延，也可以清楚的知道次数，如果次数过多，就说明有问题。

反之，如果一个发送者，没有强迫询问一个预期时间，在该模型中，属于发送者的失败，这代表发送者没有将责任落实到位。

有许多萌新在工作中，以为“我只要告诉对方”就是任务的完成。

这是十分糟糕的做法，一定会引发很多推卸责任的情况。

有时候，会遇到比较难缠的对手，他说“我需要研究，但我不确定时间。”

此时，也不要着急，我们把时间换成和他约定的“那我周三晚上再来问问你进度。”

虽然你多次询问的进度可能得到的答案都一样，但这无形给了对方进度压力，避免划水的情况。

但要注意，一个健康的商业团队不应该存在“无确定时间”这种情况。

我们不是搞科研，也不是搞慈善，员工每一天都是有成本的。

这里分两种情况：

• 任务预期时间是否合理
• 任务理解是否到位

如果是普通的执行任务，我仅仅需要对方回答一个预期时间，如果我判断不合理，会询问不合理的原因，然后再决定是否干涉。

如果是需要研究的课题任务，那通常我需要让执行者回答：“课题步骤”与“需求理解”，并同时填写可选项“课题疑问”。

通过观察执行者设计的“课题步骤”，可以理解他的研究方向是不是对的。如果有必要，就以每个步骤作为一个节点验收一次，以免问题的研究路径出现偏差。
通过观察“需求理解”，让执行者重新阐述一遍他理解的任务，就可以确认信息传递是准确的。
至于课题疑问，则是看是否需要开个会再给执行者讲一遍该任务的情况。

通常大部分情况下，任务都是简单的，只用确认一个完成时间即可，这是必须的，也是最容易被忽略的。

少部分情况下，任务具备一定难度，就需要反复确认信息发送的准确性，从最终结果看，一定是“省了时间”的，并不会浪费时间。这部分内容可以具体参考后续出的“探索模型”，有对应的现成模板，专门针对复杂任务。

• Send，确保你的问题按时按量发送给了对方。如涉及【非共识】、【跨部门】、【跨岗位】，一定要长篇解释清楚为什么要发送这个问题。
• Receive，确保收到了对方的确认信息，如果没有，就催促对方回复确认信息。
• Check， 确保收信息后，你的问题已经被回答清楚，或者你的要求已经被对方列入待做事项，且有交付日期，如果没有，则重复S与R步骤。

这套机制的建立，就是为了避免这种情况产生。

1. 首先，机制确保了责任方，要求发送方（通常是上级）一定要主动判断接收者是否到位了。
2. 然后，如果按照流程执行了，接收者刻意不回答检查时间，或其他信息，就是工作态度有问题，责任很清晰。

还有另一种情况，如果你是接收方：

1. 学会了SRC，你能理解信息误差是很容易产生了，你就在执行任务之前，主动的向发送方提交你的“方向”与”预期“。
2. 如果发送方确认了，就降低了误差风险，如果发送方不理会不确认，也属于工作态度有问题。

这套工作法的最佳实践是融入到工作流程里，平时布置任务的工作流里会强制要求这个流程，在每一个可能有误解的任务中都避免信息误差。

1. 是不是没用对，流程哪里还可以改进？
2. 是不是这个员工问题，领导为什么不开除他？
3. 领导执意不开除问题员工，是不是领导有问题？
4. 我是否应该离职，毕竟领导都有问题。

无