📦 deps(thirdparty): update snapshots
This commit is contained in:
+34
@@ -0,0 +1,34 @@
|
||||
# 反管理鸡汤护栏
|
||||
|
||||
CrossFrame Org 的输出要能改变组织变量,不提供空泛激励。
|
||||
|
||||
## 失败表达
|
||||
|
||||
以下表达通常不合格,除非后面补了具体结构变量:
|
||||
|
||||
- 加强沟通。
|
||||
- 提升执行力。
|
||||
- 增强主人翁意识。
|
||||
- 统一思想。
|
||||
- 建立闭环。
|
||||
- 压实责任。
|
||||
- 提高协同效率。
|
||||
- 强化复盘机制。
|
||||
- 管理者要更有担当。
|
||||
- 团队要更主动。
|
||||
|
||||
## 合格改写
|
||||
|
||||
- “加强沟通”改为:固定决策入口、明确谁在什么时限内回复、未回复时谁有暂停权。
|
||||
- “提升执行力”改为:冻结范围、减少并行任务、明确验收口径、授权 owner 拒绝插单。
|
||||
- “建立闭环”改为:每条反馈写回到规则、资源、角色、接口或时间表,并在下一轮检查证据。
|
||||
- “压实责任”改为:结果 owner 与授权 owner 同表列出,避免只让执行层承担。
|
||||
- “强化复盘”改为:复盘只保留一个重复问题,产出一个结构改动和一个撤回条件。
|
||||
|
||||
## 输出前检查
|
||||
|
||||
- 建议里是否有 owner、授权、资源、时间盒、证据和停止条件。
|
||||
- 是否把复杂问题压成执行层态度问题。
|
||||
- 是否把报告、会议、口号当成修复本身。
|
||||
- 是否给了组织可以验证的下一轮信号。
|
||||
- 是否允许证据推翻当前判断。
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
# 中层承接耗竭
|
||||
|
||||
中层承接耗竭不是“抗压能力差”,而是组织把翻译、缓冲、补锅、冲突吸收和反馈转译长期压给一个层级,却不给相应授权、资源和停止权。
|
||||
|
||||
## 常见表现
|
||||
|
||||
- 中层同时向上解释风险、向下解释压力、横向协调接口。
|
||||
- 需求变化后,中层负责安抚团队,但不能改目标、时间或资源。
|
||||
- 复盘时中层被要求“拿方案”,但真正的授权主体不改变条件。
|
||||
- 团队越来越依赖个别中层的个人信誉维持运转。
|
||||
- 基层把中层视为压力来源,高层把中层视为执行问题来源。
|
||||
- 中层开始压缩信息:上报时去掉坏消息,下传时去掉不确定性。
|
||||
|
||||
## 需要保护的变量
|
||||
|
||||
- 信息真实性:中层不能因为怕追责而过滤坏消息。
|
||||
- 恢复时间:中层需要从连续补锅中恢复,而不是用更密集会议替代休息。
|
||||
- 授权边界:中层必须知道哪些事可以决定,哪些事需要升级。
|
||||
- 退出权:遇到超出授权的任务,中层可以暂停承接并要求条件补齐。
|
||||
- 后备承接者:不能让组织记忆只绑在少数人身上。
|
||||
|
||||
## 修复方向
|
||||
|
||||
- 把“请中层想办法”改成“补齐中层要改变条件所需的授权”。
|
||||
- 把“中层多沟通”改成“上层对范围、优先级、资源做明确取舍”。
|
||||
- 把“中层背结果”改成“授权主体对条件失败共同负责”。
|
||||
- 把“中层继续协调”改成“减少接口数量、固定决策入口、设停止条件”。
|
||||
|
||||
## 失败提示
|
||||
|
||||
如果输出把中层耗竭写成“要提升领导力、抗压能力、情绪管理”,但没有检查授权链和成本链,应判为失败。
|
||||
@@ -0,0 +1,40 @@
|
||||
# 组织失败信号
|
||||
|
||||
这些信号用于帮助定位组织修复对象,不是人格标签。
|
||||
|
||||
## 高成本信号
|
||||
|
||||
- 同一类延期、返工、跨部门等待连续出现,但复盘结论每次不同。
|
||||
- 会议纪要越来越完整,下一轮工作方式却没有可见变化。
|
||||
- 基层反馈只停留在抱怨、表态、情绪安抚或被要求“更主动沟通”。
|
||||
- 中层不断加班协调、翻译、补锅,但没有权限改优先级、资源和接口。
|
||||
- 领导层要求更快、更紧、更透明,却没有减少任务、增加资源或授权停止。
|
||||
- 项目失败后只追加流程、审批、汇报频率,而不处理决策入口和授权边界。
|
||||
- 复盘后产生“改进项清单”,但没有 owner 的权限、完成定义、证据和复查时间。
|
||||
|
||||
## 复盘失真信号
|
||||
|
||||
- 复盘主要产出是可以上交的文本,而不是下一轮结构改变。
|
||||
- 关键责任主体缺席,留下执行层解释“为什么没有做好”。
|
||||
- 说得最多的人没有改变条件的权限,能改变条件的人只听汇报。
|
||||
- 复盘把结构问题改写成态度、沟通、意识、配合、主动性。
|
||||
- 负面信号被称为“个别情况”,但没有抽样、追踪或撤回条件。
|
||||
|
||||
## 项目失败的机制候选库
|
||||
|
||||
候选机制应互相竞争,不要一次性全塞进输出。
|
||||
|
||||
- 目标漂移:项目目标在执行中改变,但计划、资源和评价口径没有同步。
|
||||
- 授权断裂:承担结果的人没有改变范围、资源、优先级或接口的权限。
|
||||
- 反馈写回失败:问题被看见,却没有改到规则、角色、接口、时间表或资源。
|
||||
- 复盘副产品化:报告、清单、道歉、OKR 更新替代了真实修复。
|
||||
- 中层过载:组织把冲突、解释、翻译、补救成本集中压给中层。
|
||||
- 错误加速:问题还没定位就加会、冲刺、追责、升级管理,导致噪音更多。
|
||||
- 证据低成本化:自评、汇报、漂亮材料替代了可审计行为和结果证据。
|
||||
|
||||
## 使用边界
|
||||
|
||||
- 不凭单次失败给人格或文化定性。
|
||||
- 不把沉默直接解释为认同;沉默可能来自无授权、无保护或反馈无用。
|
||||
- 不把努力和加班当成修复证据;它们可能是组织未写回的成本外包。
|
||||
- 不把“大家都知道问题”当成闭环;知道问题不等于改动结构。
|
||||
@@ -0,0 +1,32 @@
|
||||
# CrossFrame Org 读取路由图
|
||||
|
||||
本文件只决定组织专项材料怎么读。CrossFrame 本体仍由 `../crossframe/SKILL.md` 与 `../crossframe/references/read-routing-map.md` 决定。
|
||||
|
||||
## 基础路由
|
||||
|
||||
| 用户请求 | 先读 canonical | 本 skill 必读 | 输出模板 |
|
||||
| --- | --- | --- | --- |
|
||||
| 项目失败、延期、反复返工 | `../crossframe/protocols/diagnosis-protocol.md`、`../crossframe/references/concept-cards/mechanism-candidates.md` | `protocols/org-diagnostic-protocol.md`、`references/org-failure-signals.md`、`references/responsibility-authorization-chain.md` | `templates/org-diagnostic-memo.md` |
|
||||
| 复盘失真、复盘越做越假 | `../crossframe/references/concept-cards/repair-byproduct.md`、`../crossframe/references/concept-cards/evidence-cost.md` | `protocols/retrospective-redesign-protocol.md`、`references/org-failure-signals.md`、`references/anti-chicken-soup-guardrails.md` | `templates/retrospective-redesign-recommendation.md` |
|
||||
| 基层反馈没人听、问题无法写回 | `../crossframe/references/concept-cards/chengjie-huiliu.md`、`../crossframe/references/concept-cards/responsibility-chain.md` | `protocols/feedback-writeback-protocol.md`、`references/responsibility-authorization-chain.md` | `templates/feedback-writeback-plan.md` |
|
||||
| 中层疲惫、被夹在中间、长期补锅 | `../crossframe/references/concept-cards/structure-process-group.md`、`../crossframe/references/concept-cards/repair-byproduct.md` | `references/middle-manager-depletion.md`、`protocols/org-diagnostic-protocol.md` | `templates/org-diagnostic-memo.md` |
|
||||
| 想要组织改造、试点、行动计划 | `../crossframe/protocols/low-condition-action-protocol.md`、`../crossframe/references/concept-cards/low-condition-action.md` | `protocols/low-risk-pilot-protocol.md`、`references/responsibility-authorization-chain.md` | `templates/low-risk-pilot-plan.md`、`templates/stop-condition-card.md` |
|
||||
| 冲刺、加速、升级管理后更乱 | `../crossframe/references/concept-cards/judgment-grades.md`、`../crossframe/references/concept-cards/evidence-cost.md` | `protocols/low-risk-pilot-protocol.md`、`references/anti-chicken-soup-guardrails.md` | `templates/stop-condition-card.md` |
|
||||
|
||||
## 高风险概念补读
|
||||
|
||||
- 复盘、修复、道歉、改进项、合规材料:读 `../crossframe/references/concept-cards/repair-byproduct.md`。
|
||||
- 责任、背锅、负责人、Owner、RACI:读 `../crossframe/references/concept-cards/responsibility-chain.md`。
|
||||
- 反馈、回流、写回、闭环:读 `../crossframe/references/concept-cards/chengjie-huiliu.md`。
|
||||
- 中层耗竭、结构负荷、行动承接:读 `../crossframe/references/concept-cards/structure-process-group.md`。
|
||||
- 弱信号、汇报、报告、自评、复盘记录:读 `../crossframe/references/concept-cards/evidence-cost.md`。
|
||||
- 试点、低风险行动、可撤回动作:读 `../crossframe/references/concept-cards/low-condition-action.md`。
|
||||
- 停止条件、能否强推、能否升级:读 `../crossframe/references/concept-cards/judgment-grades.md`。
|
||||
|
||||
## 输出选择
|
||||
|
||||
- 用户要“怎么看、诊断、为什么”:默认 `组织诊断备忘录`。
|
||||
- 用户要“怎么改、怎么闭环”:默认 `反馈写回方案`。
|
||||
- 用户要“复盘怎么做”:默认 `复盘改造建议`。
|
||||
- 用户要“先试一下、低风险推进”:默认 `低风险试点计划`。
|
||||
- 用户情绪很急、组织正在加速:先输出 `停止条件卡`,再给低风险试点。
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
# 责任链与授权链
|
||||
|
||||
组织修复的核心问题通常不是“谁态度不好”,而是谁对结果负责、谁有权限改变条件、谁在承担没有权限的成本。
|
||||
|
||||
## 三条链
|
||||
|
||||
### 责任链
|
||||
|
||||
- 结果责任:谁必须对结果、质量、延期、风险或损失负责。
|
||||
- 条件责任:谁负责提供资源、范围边界、优先级、接口和决策。
|
||||
- 解释责任:谁被要求解释失败、安抚冲突、翻译需求和证明努力。
|
||||
- 修复责任:谁负责把反馈写回下一轮结构。
|
||||
|
||||
### 授权链
|
||||
|
||||
- 范围授权:谁可以删减目标、冻结需求、拒绝插单。
|
||||
- 资源授权:谁可以增加人手、预算、时间、工具或外部支持。
|
||||
- 优先级授权:谁可以让低优先事项暂停。
|
||||
- 接口授权:谁可以改变跨团队交接方式、SLA 或决策入口。
|
||||
- 停止授权:谁可以宣布暂停、降档、撤回、保护现场。
|
||||
|
||||
### 成本链
|
||||
|
||||
- 谁承担加班、返工、解释、情绪劳动和信任损耗。
|
||||
- 谁因为失败失去名誉、机会、评价或资源。
|
||||
- 谁从模糊授权中受益,或避免暴露真实取舍。
|
||||
|
||||
## 诊断问题
|
||||
|
||||
1. 承担结果的人是否拥有足够授权。
|
||||
2. 拥有授权的人是否承担可见责任。
|
||||
3. 被要求解释的人是否能改变结构条件。
|
||||
4. 反馈是否能进入下一轮规则、资源、角色、接口或时间表。
|
||||
5. 组织是否把高层取舍失败包装成执行层配合不足。
|
||||
6. 中层是否成为事实上的“无授权修复器”。
|
||||
|
||||
## 输出要求
|
||||
|
||||
- 每个建议都要写明 owner,但 owner 不是背锅人;必须同时写明 owner 拥有什么授权。
|
||||
- 如果某建议需要上级授权,直接写出授权请求,而不是把动作写成执行层自我改进。
|
||||
- 如果授权无法获得,建议要降档为低风险试点、观察项或停止条件。
|
||||
Reference in New Issue
Block a user