这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版 | ||
个人成长:src工作法 [2023/06/13 14:55] – [思路二、阐述目的与预期] 邪让多杰 | 个人成长:src工作法 [2023/06/13 15:28] (当前版本) – [答疑] 邪让多杰 | ||
---|---|---|---|
行 112: | 行 112: | ||
<color # | <color # | ||
+ | ==== 思路四、检查回复 ==== | ||
+ | |||
+ | 这里分两种情况: | ||
+ | * 任务预期时间是否合理 | ||
+ | * 任务理解是否到位 | ||
+ | |||
+ | 如果是普通的执行任务,我< | ||
+ | |||
+ | 如果是< | ||
+ | |||
+ | < | ||
+ | <note tip> | ||
+ | |||
+ | 通过< | ||
+ | 通过< | ||
+ | 至于课题疑问,则是看是否需要开个会再给执行者讲一遍该任务的情况。 | ||
+ | |||
+ | 通常大部分情况下,任务都是简单的,只用确认一个完成时间即可,< | ||
+ | |||
+ | 少部分情况下,任务具备一定难度,就需要反复确认信息发送的准确性,从最终结果看,一定是“省了时间”的,并不会浪费时间。这部分内容可以具体参考后续出的“探索模型”,有对应的现成模板,专门针对复杂任务。 | ||
==== 名词解释 ==== | ==== 名词解释 ==== | ||
* Send,确保你的问题按时按量发送给了对方。如涉及【非共识】、【跨部门】、【跨岗位】,一定要长篇解释清楚为什么要发送这个问题。 | * Send,确保你的问题按时按量发送给了对方。如涉及【非共识】、【跨部门】、【跨岗位】,一定要长篇解释清楚为什么要发送这个问题。 | ||
行 117: | 行 137: | ||
* Check, 确保收信息后,你的问题已经被回答清楚,或者你的要求已经被对方列入待做事项,且有交付日期,如果没有,则重复S与R步骤。 | * Check, 确保收信息后,你的问题已经被回答清楚,或者你的要求已经被对方列入待做事项,且有交付日期,如果没有,则重复S与R步骤。 | ||
==== 答疑 ==== | ==== 答疑 ==== | ||
- | 无 | + | |
+ | === 问题1:遇到了别人刻意甩锅/ | ||
+ | |||
+ | 这套机制的建立,就是为了避免这种情况产生。 | ||
+ | |||
+ | - 首先,< | ||
+ | - 然后,如果按照流程执行了,< | ||
+ | |||
+ | 还有另一种情况,如果你是接收方: | ||
+ | - 学会了SRC,你能理解信息误差是很容易产生了,你就在执行任务之前,主动的向发送方提交你的“方向”与”预期“。 | ||
+ | - 如果发送方确认了,就降低了误差风险,如果发送方不理会不确认,也属于工作态度有问题。 | ||
+ | |||
+ | 这套工作法的< | ||
+ | |||
+ | === 问题2:遵循了这套机制后,依旧遇到甩锅怎么办? === | ||
+ | |||
+ | - 是不是没用对,流程哪里还可以改进? | ||
+ | - 是不是这个员工问题,领导为什么不开除他? | ||
+ | - 领导执意不开除问题员工,是不是领导有问题? | ||
+ | - 我是否应该离职,毕竟领导都有问题。 | ||
+ | |||
+ | <note tip> | ||
===== 观点与分析 ===== | ===== 观点与分析 ===== | ||
- | ==== 观点1 ==== | + | 无 |
- | ==== 观点2 ==== | + |