多杰游戏学

用户工具

站点工具

您在这里: 学习指南 » 个人成长 » src工作法
个人成长:src工作法

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

两侧同时换到之前的修订记录前一修订版
后一修订版		前一修订版
个人成长:src工作法 [2023/06/13 14:45] – [思路一、信息误差的责任人在发送信息的人。] 邪让多杰个人成长:src工作法 [2023/06/13 15:28] (当前版本) – [答疑] 邪让多杰
行 3: 行 3:
 {{ :个人成长:src工作法.jpg?400 |}} {{ :个人成长:src工作法.jpg?400 |}}
 ==== 简单解释 ==== ==== 简单解释 ====
-通过落实责任，确保工作中消息传递/任务传递的有效性。+通过落实责任，以责任方的角度出发，确保工作中消息传递/任务传递成功的工作方法。 
 + 
 +==== 适用范围 ==== 
 +一个人，有需求发送给其他人，并期望一个结果的情况。 
 +  * 【平级的串行任务】执行者 --> 执行者 
 +  * 【上至下的分派任务】上级 --> 执行者 
 +  * 【里至外的申请任务】执行者 --> 其他接口人（如财务，乙方） 
 + 
 + 
 +==== 作用 ==== 
 +在工作中，与人交接经常会出现一些情况： 
 +  * <color #ed1c24>我以为你知道。</color> 
 +  * <color #ed1c24>你一直没回复。</color> 
 +  * <color #ed1c24>你完全做错了方向，我要的不是这个。</color> 
 +  * 等等 
 + 
 +发生这样问题的原因，可以从几个角度拆解： 
 +  - 能力问题 
 +  - <color #00a2e8>信息误差</color> 
 +  - 客观环境问题 
 + 
 +实践中，我们发现大部分情况下问题都源自于2，属于信息误差。所以为了尽量避免2的产生，就产生了当前课题与模型。 
 + 
 +学会本模型，好处有： 
 +  *【从个人角度】学会SRC工作法，<color #22b14c>避免出现信息传递问题</color>。 
 +  *【从领导角度】学会SRC工作法，<color #22b14c>明确责任点，降低任务沟通损耗</color>。 
 +  *【从工作流角度】<color #ff7f27>将SRC融入到工作流程设计中</color>，能够尽量确保任务信息传递正确到位，降低信息传递的误差损耗。
  
 ==== 思路一、责任人是发送者 ==== ==== 思路一、责任人是发送者 ====
行 22: 行 48:
 同时又因为，<color #00a2e8>大多数情况下，发送信息的人拥有更多的信息、经验或能力。</color> 同时又因为，<color #00a2e8>大多数情况下，发送信息的人拥有更多的信息、经验或能力。</color>
  
-==== 思路二、阐述目的与预期。====+==== 思路二、阐述目的与预期====
  
 当我们确定了信息误差的责任人是信息发送者后，我们就可以<color #00a2e8>以发送者的角度出发讨论该问题</color>，接下来用：“我”。 当我们确定了信息误差的责任人是信息发送者后，我们就可以<color #00a2e8>以发送者的角度出发讨论该问题</color>，接下来用：“我”。
行 31: 行 57:
 ===为什么不仅仅从任务难度进行区分？=== ===为什么不仅仅从任务难度进行区分？===
 因为<color #ed1c24>难度是“主观”的</color>，比如：“帮我买个西瓜”，有的人有挑选西瓜的独家秘诀，此时<color #ed1c24>安排的人如果“不知道”</color>，则完成的任务就变得“很难”。 因为<color #ed1c24>难度是“主观”的</color>，比如：“帮我买个西瓜”，有的人有挑选西瓜的独家秘诀，此时<color #ed1c24>安排的人如果“不知道”</color>，则完成的任务就变得“很难”。
 +
 已知命题： 已知命题：
   人的思想不可观测   人的思想不可观测
  
 所以，执行者是不可能在我没有阐述清楚任务期望的情况下，知道我在想什么的。 所以，执行者是不可能在我没有阐述清楚任务期望的情况下，知道我在想什么的。
 +
 这也是责任人一定要是发送者的原因。 这也是责任人一定要是发送者的原因。
 +
 自然的，当我分析一个任务时，我就会思考我脑海中的评判标准<color #00a2e8>是否“普世”</color>的，哪怕是“普世”的，经常也会出问题，因为<color #ff7f27>这是“我的常识”，而不是“执行者的常识”</color>。 自然的，当我分析一个任务时，我就会思考我脑海中的评判标准<color #00a2e8>是否“普世”</color>的，哪怕是“普世”的，经常也会出问题，因为<color #ff7f27>这是“我的常识”，而不是“执行者的常识”</color>。
  
行 41: 行 70:
  
 这样还有一个好处，当我作为发送者，在发送任务时被强制要求思考“目的”与“预期”时，就变相强制我<color #ff7f27>检查一遍“需求是否合理”</color>。 这样还有一个好处，当我作为发送者，在发送任务时被强制要求思考“目的”与“预期”时，就变相强制我<color #ff7f27>检查一遍“需求是否合理”</color>。
-当一个发送者能够<color #00a2e8>想清楚“自己要什么”</color>时，<color #22b14c>问题就会变得轻松</color>许多。+ 
 +<note>当一个发送者能够想清楚“自己要什么”时，问题就会变得轻松许多。</note>
  
 举例，音乐或者美术是偏感觉的，作为非专业和的需求发起者，我很难用专业的角度去干预制作。 举例，音乐或者美术是偏感觉的，作为非专业和的需求发起者，我很难用专业的角度去干预制作。
行 51: 行 81:
 但<color #22b14c>最终的好处，是消除信息误差</color>，确保执行者理解我的意图，减少不避免的返工与事故。 但<color #22b14c>最终的好处，是消除信息误差</color>，确保执行者理解我的意图，减少不避免的返工与事故。
  
-==== 作用 ==== 
-在工作中，与人交接经常会出现一些情况： 
-  * 我以为你知道。 
-  * 你一直没回复。 
-  * 你完全做错了方向，我要的不是这个。 
-  * 等等 
  
-发生这样问题的原因，可以从几个角度拆解： +==== 思路三、得到回复 ==== 
-  - 能力问题 +得到回复有两种情况： 
-  - 信息误差 +  - 得到预计完成的时间。 
-  - 客观环境问题 +  - 得到关于任务的理解。 
-==== 适用范围 ==== + 
-一个人，有需求发送给其他人，并期望一个结果的情况。 +哪怕再简单的一个任务，如果我期望一个结果，那么我就需要得到回复，比如“你什么时候完成，我到时候来找你。” 
-  * 【平级的串行任务】执行者 --> 执行者 + 
-  * 【上至下的分派任务】上级 --> 执行者 +其中<color #00a2e8>“什么时候”是关键</color>， 
-  * 【里至外的申请任务】执行者 --> 其他接口人（如财务+<note>强迫对方给一个时间，是对双方都负责的做法</note> 
 + 
 +<color #00a2e8>这不是绩效，不怕延迟</color>，但一个人<color #22b14c>一旦答应你了具体时间，责任就变得十分明确</color>，哪怕拖延，也可以清楚的知道次数，如果次数过多，就说明有问题。 
 + 
 +反之，<color #ed1c24>如果一个发送者，没有强迫询问一个预期时间，在该模型中，属于发送者的失败，这代表发送者没有将责任落实到位</color>。 
 + 
 +有许多萌新在工作中，<color #ed1c24>以为“我只要告诉对方”就是任务的完成。</color> 
 + 
 +这是十分糟糕的做法，一定会引发很多<color #ff7f27>推卸责任的情况</color>。 
 + 
 +<note>要以“对方回复你了时间”才能算作发送的结束。</note> 
 + 
 +有时候，会遇到比较难缠的对手，他说“我需要研究，但我不确定时间。” 
 + 
 +此时，也不要着急，我们把时间换成和他约定的“<color #22b14c>那我周三晚上再来问问你进度。</color>” 
 + 
 +虽然你多次询问的进度可能得到的答案都一样，但这无形给了对方进度压力，避免划水的情况。 
 + 
 +但要注意，一个健康的商业团队不应该存在“无确定时间”这种情况。 
 + 
 +<color #ff7f27>我们不是搞科研，也不是搞慈善，员工每一天都是有成本的。</color> 
 + 
 +==== 思路四、检查回复 ==== 
 + 
 +这里分两种情况： 
 +  * 任务预期时间是否合理 
 +  * 任务理解是否到位 
 + 
 +如果是普通的执行任务，我<color #00a2e8>仅仅需要对方回答一个预期时间</color>，如果我判断不合理，会询问不合理的原因，然后再决定是否干涉。 
 + 
 +如果是<color #ff7f27>需要研究的课题任务</color>，那通常我需要让执行者回答：<color #ffaec9>“课题步骤”与“需求理解”</color>，并同时填写可选项<color #ffaec9>“课题疑问”</color>。 
 + 
 +<note>对于任务，接收者一定要回复下一次检查时间，发送才算结束。</note> 
 +<note tip>若含有复杂信息，接收者一定要恢复自己的理解，通过发送者检查才算结束。</note> 
 + 
 +通过<color #ff7f27>观察执行者设计的“课题步骤”</color>，可以理解他的研究<color #ed1c24>方向是不是对的</color>。如果有必要，就以每个步骤作为一个节点验收一次，以免问题的研究路径出现偏差。\\ 
 +通过<color #ff7f27>观察“需求理解”</color>，让执行者重新阐述一遍他理解的任务，就可以<color #22b14c>确认信息传递是准确的</color>。\\ 
 +至于课题疑问，则是看是否需要开个会再给执行者讲一遍该任务的情况。 
 + 
 +通常大部分情况下，任务都是简单的，只用确认一个完成时间即可，<color #ed1c24>这是必须的，也是最容易被忽略的</color>。 
 + 
 +少部分情况下，任务具备一定难度，就需要反复确认信息发送的准确性，从最终结果看，一定是“省了时间”的，并不会浪费时间。这部分内容可以具体参考后续出的“探索模型”，有对应的现成模板，专门针对复杂任务。
 ==== 名词解释 ==== ==== 名词解释 ====
   * Send，确保你的问题按时按量发送给了对方。如涉及【非共识】、【跨部门】、【跨岗位】，一定要长篇解释清楚为什么要发送这个问题。   * Send，确保你的问题按时按量发送给了对方。如涉及【非共识】、【跨部门】、【跨岗位】，一定要长篇解释清楚为什么要发送这个问题。
行 72: 行 137:
   * Check， 确保收信息后，你的问题已经被回答清楚，或者你的要求已经被对方列入待做事项，且有交付日期，如果没有，则重复S与R步骤。   * Check， 确保收信息后，你的问题已经被回答清楚，或者你的要求已经被对方列入待做事项，且有交付日期，如果没有，则重复S与R步骤。
 ==== 答疑 ==== ==== 答疑 ====
-无+ 
 +=== 问题1：遇到了别人刻意甩锅/隐瞒怎么办？ === 
 + 
 +这套机制的建立，就是为了避免这种情况产生。 
 + 
 +  - 首先，<color #22b14c>机制确保了责任方</color>，要求发送方（通常是上级）一定要主动判断接收者是否到位了。 
 +  - 然后，如果按照流程执行了，<color #ed1c24>接收者刻意不回答检查时间</color>，或其他信息，就是工作态度有问题，责任很清晰。 
 + 
 +还有另一种情况，如果你是接收方： 
 +  - 学会了SRC，你能理解信息误差是很容易产生了，你就在执行任务之前，主动的向发送方提交你的“方向”与”预期“。 
 +  - 如果发送方确认了，就降低了误差风险，如果发送方不理会不确认，也属于工作态度有问题。 
 + 
 +这套工作法的<color #22b14c>最佳实践是融入到工作流程</color>里，平时布置任务的工作流里会强制要求这个流程，在每一个可能有误解的任务中都避免信息误差。 
 + 
 +=== 问题2：遵循了这套机制后，依旧遇到甩锅怎么办？ === 
 + 
 +  - 是不是没用对，流程哪里还可以改进？ 
 +  - 是不是这个员工问题，领导为什么不开除他？ 
 +  - 领导执意不开除问题员工，是不是领导有问题？ 
 +  - 我是否应该离职，毕竟领导都有问题。 
 + 
 +<note tip>作为领导，责任在我，作为员工，向上管理，管理不动，走为上策。</note>
 ===== 观点与分析 ===== ===== 观点与分析 =====
-==== 观点1 ==== +无
-==== 观点2 ====+
个人成长/src工作法.1686638712.txt.gz · 最后更改: 2023/06/13 14:45 由 邪让多杰

页面工具

除额外注明的地方外，本维基上的内容按下列许可协议发布： GNU Free Documentation License 1.3
GNU Free Documentation License 1.3 Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki 粤ICP备2021175623号-1