findscripter 何时使用
当你需要把"公司如何运转"显性化、可改进时使用，典型场景：
- 初创/成长期公司要搭建运营机制，从无到有建立协作节奏
- 在 EOS（Traction）、Scaling Up（洛克菲勒习惯）、OKR-native、Holacracy、自定义混合之间做框架选型
- 同一类问题每周复现、会议低效、权责不清、季度目标总是滑坡
- 要落地 OKR、设计周例会与议题解决流程、建立 90 天 Rocks
核心判断：多数运营失调不是人的问题，是系统的问题。修好系统，人在系统里自然运转更好。
不该用的边界：
- 不替代具体业务执行方案（如某次销售打法、某个功能设计）
- 不替代单一职能的深度专业内容（财务建模、招聘流程细节等）
- 已有成熟运营系统且运转良好时，不要为改而改
- 不是组织架构图（org chart）工具——本框架关注"谁对结果负责"而非汇报线
步骤
分阶段落地，切忌一次性全上。
第一步：建责权图（1 个 2 小时工作坊）
- 列出公司执行的所有职能
- 每个职能指派唯一负责人，无例外
- 找出空白（无人负责）与重叠（两人都以为自己负责）
- 公布，变化时更新
第二步：定记分卡（领导团队对齐，约 1 小时）
- 先定 5～10 个每周指标，每个有负责人和单一周目标值
第三步：启动每周 L10 例会（无需准备，直接开始）
这三件事带来的协同提升，超过多数公司一年的努力。
后续按 references 的 90 天计划逐步补齐会议节奏、Rocks、沟通节拍。
指令
六大核心组件（任何框架都需要这六项）：
责权图（Accountability Chart）——回答"谁对这个结果负责"
- 每个职能仅一人负责（owns），可多人参与（works in）
- 禁止共享负责：「Alice 和 Bob 都负责」等于无人负责
- 早期一人可兼多席，但要写明；按季度复盘随规模调整
结构示例：
CEO ├── 销售 (CRO/VP Sales) │ ├── 入站管道 │ └── 出站管道 ├── 产品与工程 (CTO/CPO) │ ├── 产品路线图 │ └── 工程交付 ├── 运营 (COO) │ ├── 客户成功 │ └── 财务与法务 └── 人力 (CHRO/VP People) ├── 招聘 └── 人力运营记分卡（Scorecard）——每周指标，非月度非季度
- 5～15 个指标上限；每个有负责人 + 单一周目标值（一个数，不是区间）
- 红/黄/绿状态，不写段落；周会只讨论红色项
- 反模式：测一切。跟踪 40 个 KPI 是在"看"不是在"管"
指标 负责人 目标 本周 状态 新增 MRR CRO €50K €43K 🔴 流失率 CS Lead < 1% 0.8% 🟢 关键 bug CTO 0 2 🔴 现金跑道 CFO > 18mo 16mo 🟡 会议节奏（Meeting Pulse）——维持公司"心跳"
会议 频率 时长 参与 目的 每日站会 每日 15 分 各团队 只讲阻塞 L10/领导同步 每周 90 分 领导团队 记分卡+议题 部门评审 每月 60 分 部门+领导 OKR 进展 季度规划 每季 1～2 天 领导团队 定 Rocks、复盘战略 年度规划 每年 2～3 天 领导团队 1 年+3 年愿景 L10 固定议程（目标是每次开成 10 分满分）：
- 好消息 (5 分)——个人+业务
- 记分卡评审 (5 分)——只标红色
- Rock 评审 (5 分)——逐项 on/off track
- 客户/员工头条 (5 分)
- 议题清单 (60 分)——走 IDS
- 待办评审 (5 分)——上周承诺
- 收尾 (5 分)——给会议打 1～10 分，下次如何到 10
议题解决 IDS（Identify, Discuss, Solve）——每议题最多 15 分钟
- Identify：用一句话说清真问题（根因，非症状）
- Discuss：相关事实+视角，限时；讨论开始重复就停
- Solve：一个负责人、一个动作、一个截止日，写进待办
- 反模式："先线下聊"（多半永不解决）；只讨论不决策；重开已决议题（除非有新信息）
- 议题清单：领导团队持有，每周评审并修剪。一个议题挂满 3 次会还没讨论，要么不是真议题，要么太可怕没人敢碰——两者都值得关注
Rocks（90 天优先级）——每人/团队 3～7 件
- 为什么 90 天：足够取得有意义进展，又短到逼真
- 每人最多 3～7 个，超 7 个一个都做不成
- 二元判定：完成或未完成，没有"60% 完成"
- 季度规划时设定，每周评审 on/off track
- 坏 Rock："改进销售流程"
- 好 Rock："3 月 31 日前上线 Salesforce CRM，含完整管道阶段与周报"
- Rock vs 待办：待办一个动作搞定；Rock 需 90 天持续投入
沟通节拍（Communication Cadence）——谁、何时、以何形式获得什么信息
- 全员：月度公司更新（书面+Q&A）；季度结果+下季优先级（全员大会）
- 领导团队：每周记分卡（仪表盘）
- 董事会：月度董事备忘
- 投资人：月/季关键指标+叙事
- 默认规则：内部信息犹豫要不要分享时——分享。沟通不足的代价永远高于过度沟通
框架选型速查（详见 references/os-comparison.md）：
| 如果你是… | 考虑… |
|---|---|
| 10～250 人、创始人主导、运营混乱 | EOS / Traction |
| 雄心成长型、需严谨战略级联 | Scaling Up |
| 技术公司、工程文化、假设驱动 | OKR-native |
| 去中心化、扁平、高自治 | Holacracy（仅当你有耐心） |
| 都不太合适 | 自定义混合 |
示例
输入：一家 60 人的 SaaS 公司，创始人反映"每周开会但同样的问题一直反复，季度目标总滑坡，没人清楚谁负责客户流失"。
适配输出（30 天快启）：
- 选型：60 人、创始人主导、运营混乱 -> 推荐 EOS/Traction
- 责权图工作坊产出："客户流失"明确归 CS Lead 唯一负责，消除"销售和 CS 都管"的重叠
- 记分卡定 6 个周指标（新增 MRR / 流失率 / 活跃用户 / 部署次数 / 关键 bug / 现金跑道），各有数字目标
- 启动每周 L10，固定议程，60 分钟走 IDS 处理议题清单
- 季度规划上为领导团队设 3～7 个公司级 Rocks，每人 3～7 个，二元判定，周会 on/off track 复盘
关键自检问题：
- "若问 5 位团队负责人本季度公司前三优先级，答案会一致吗？"
- "谁负责客户流失？能毫不犹豫说出名字吗？"
- "说一个能在周五就判断本周好坏的指标——我们在跟踪它吗？"
注意事项
保留以下硬约束（来自源框架）：
- 责权图禁止共享负责；记分卡 5～15 个指标、用单一数字目标；Rocks 每人硬上限 7 个、二元判定；IDS 每议题 15 分钟
- 常见失败模式：
- 部分落地："做 OKR 但跳过每周检查"——半套系统比没有更糟，制造无问责的表演
- 会议疲劳：在现有会议上叠加全套节奏——应替换会议而非新增
- 指标过载：开局上 30 个 KPI——从 5 个起步，节奏稳了再加
- Rock 膨胀：每人 12 个 Rock——当一切都是优先级，就没有优先级
- 领导不遵守：领导团队跳过 L10 或不走 IDS——系统得到的尊重等于领导给它的尊重
- 只年度规划不季度复盘：季度是任何有意义目标的最低复盘周期
- 与 C-suite 的连接：CEO 出愿景喂给 1 年计划和 Rocks；COO 拥有会议节奏与议题解决；CFO 拥有财务指标；CTO 拥有工程 Rocks 与技术指标；CHRO 拥有人力指标（流失、招聘速度）
互见
- references/os-comparison.md —— EOS vs Scaling Up vs OKR vs Holacracy vs 混合 全面对比
- references/implementation-guide.md —— 90 天落地计划
- 关联技能：lark-okr（飞书 OKR 落地）、lark-task（Rocks/待办跟踪）、lark-calendar（会议节奏排期）
采编自 alirezarezvani/claude-skills（MIT）。