38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# 反馈写回协议
|
|
|
|
用于基层反馈无效、复盘没有改变下一轮、问题被看见但组织不变的场景。
|
|
|
|
## 定义
|
|
|
|
反馈写回不是收集意见，也不是会议纪要。反馈只有写回到规则、资源、角色、接口、时间表或停止条件，才进入组织修复回路。
|
|
|
|
## 写回路径
|
|
|
|
1. 信号来源：谁发出反馈，反馈来自结果、过程、客户、基层、跨部门接口还是风险事件。
|
|
2. 信号保护：反馈者是否会因说出问题承担额外成本。
|
|
3. 转译节点：谁把反馈转成组织语言，转译是否压扁了坏消息。
|
|
4. 授权节点：谁能改变条件，是否在场。
|
|
5. 结构落点：反馈写回到什么具体变量。
|
|
6. 证据形式：下一轮用什么行为或结果证明写回发生。
|
|
7. 复查时间：何时检查，谁检查，失败如何撤回或升级。
|
|
|
|
## 五种有效写回
|
|
|
|
- 规则写回：改验收口径、需求入口、升级路径、风险阈值。
|
|
- 资源写回：增加时间、人手、预算、工具、培训或外部支持。
|
|
- 角色写回：改变 owner、审批人、接口人、替补人或授权边界。
|
|
- 接口写回：改变跨部门交接、响应时限、信息格式和默认决策规则。
|
|
- 时间表写回：冻结范围、减少并行、设置恢复窗口和复查节点。
|
|
|
|
## 失败模式
|
|
|
|
- 反馈只变成“大家要重视”。
|
|
- 反馈只变成执行层改进项。
|
|
- 反馈只变成更密集汇报。
|
|
- 反馈者需要继续解释，授权主体不用改变。
|
|
- 没有下一轮信号，无法判断写回是否发生。
|
|
|
|
## 输出要求
|
|
|
|
每条写回建议必须包含：反馈来源、结构落点、授权 owner、执行 owner、证据、复查时间、失败处理。
|