版本：v1.0 创建日期：2026-04-10 维护者：龙龟神将
| 场景类型 | 推荐框架 | 关键思维 | 页内位置 |
|---|---|---|---|
| 横向展开 | 逻辑树、金字塔、矩阵 | 系统+结构化+逻辑 | §2.1 |
| 纵向深挖 | 五Why、因果链、四层次 | 结构化+逻辑+系统 | §2.2 |
| 全面分析 | 十大步骤 | 五大思维全调用 | §2.3 |
| 创新突破 | 反事实思维 | 创造性+批判性 | §2.4 |
| 中层管理 | 三层能力模型 | 框架思维+结构化 | §2.5 |
第一步：系统思维「看全」
□ 划定系统边界
- 问题处于哪个系统？（客户价值流）
- 系统边界在哪里？（市场→销售→产品→售后→复购）
□ 识别要素关联
- 市场获客（流量、转化）
- 销售转化（需求匹配、价格谈判）
- 产品体验（功能、质量、易用性）
- 售后服务（响应速度、解决方案）
- 复购推荐（NPS、口碑传播）
□ 标注关系
- 促进关系：售后好 → 复购高
- 抑制关系：价格高 → 转化低第二步：结构化「搭骨架」
□ 选择分类维度
- 推荐：按用户旅程（时间轴）
- 备选：按要素（人机料法环）
□ 绘制逻辑树
客户满意度下降
┌────┬────┬────┬────┐
▼ ▼ ▼ ▼ ▼
市场 销售 产品 售后 复购第三步：逻辑思维「拆不乱」
□ 检查MECE
- 五个环节相互独立？✓
- 五个环节完全穷尽？✓
□ 保持同一层次
- 同用「用户旅程」维度 ✓
- 不混入「部门职能」维度 ✓第四步：锁定关键节点
□ 数据分析
- 市场获客：正常
- 销售转化：略低
- 产品体验：下降30% ← 关键节点
- 售后服务：下降50% ← 关键节点
- 复购推荐：下降20%
□ 决定：重点深挖「产品体验」和「售后服务」第一步：选择深挖框架
□ 判断原因类型
- 现象：产品体验下降
- 可能类型：技术原因？人为原因？流程原因？
□ 选择框架
- 首选：四层次原因分析法
- 备选：根据原因类型切换框架第二步：结构化深挖
□ 第一层：问题拆解
「产品体验下降」的具体表现：
- App崩溃率上升
- 加载时间延长
- 界面卡顿
□ 第二层：直接原因
「App崩溃率上升」的直接原因：
- 某次版本更新后崩溃率从0.1%上升到2.5%
□ 第三层：流程/系统原因
「为什么那次更新后崩溃率上升？」
- 测试流程：灰度发布3天，未覆盖所有机型
- 审核流程：紧急版本跳过部分检测
- 监控流程：新崩溃未及时发现
□ 第四层：人的原因
「为什么测试不充分？」
- 知识：测试人员不熟悉新架构
- 习惯：紧急版本走简化流程已成惯例
- 环境：上周五发布，周五下午大家想早下班第三步：逻辑思维「推不错」
□ 验证因果
- 时间顺序：版本更新（先）→ 崩溃率上升（后）✓
- 共变关系：版本回滚后崩溃率下降 ✓
- 排除混淆：非系统维护、非竞品攻击 ✓
□ 防止跳跃
- 错误：「因为测试不充分」→ 停止
- 正确：「因为测试不充分」→ 追问「为什么不充分？」第四步：系统思维「看深」
□ 识别反馈回路
版本发布 → 崩溃率上升
↑ │
│ ▼
回滚 ← 用户流失 → 口碑下降
□ 识别延迟效应
- 三天前发布的版本，今天才发现崩溃？
- 为什么延迟三天？
□ 检查心智层
- 「紧急版本走简化流程」的信念是什么？
- 「周五下午可以早点下班」的潜规则是什么？第五步：设定停挖标准
□ 判断是否可行动
- 是：修改测试流程、增加监控告警
- 否：追究历史责任
□ 判断是否超出范围
- 否：测试流程属于本部门管理范围
□ 判断成本收益
- 成本：增加测试人员和时间
- 收益：避免用户流失和口碑损失
- 结论：收益远大于成本 → 继续行动┌─────────────────────────────────────────────────────────────────┐
│ 十大步骤实操手册 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第一步：定义问题 │
│ ───────────────── │
│ □ 现状（事实）： │
│ - 项目延期率从10%上升到35% │
│ - 任务完成率从85%下降到52% │
│ - 团队成员满意度从4.2下降到3.1 │
│ │
│ □ 期望（应该）： │
│ - 项目延期率控制在15%以内 │
│ - 任务完成率维持在80%以上 │
│ - 团队成员满意度维持在4.0以上 │
│ │
│ □ 差距： │
│ - 延期率差距25% │
│ - 完成率差距28% │
│ - 满意度差距0.9 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第二步：界定范围 │
│ ───────────────── │
│ □ 是个人问题还是系统问题？ │
│ - 判断：系统问题（多个成员、多个项目同时出现） │
│ │
│ □ 是今天必须解决还是可以缓缓？ │
│ - 判断：影响业务连续性，需要本周内解决 │
│ │
│ □ 影响边界： │
│ - 涉及团队：产品团队（12人）、研发团队（25人） │
│ - 涉及项目：5个重点产品项目 │
│ - 涉及客户：3个战略客户 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第三步：收集信息 │
│ ───────────────── │
│ □ 发生了什么？（客观事实） │
│ - 访谈记录：沟通不清、优先级不明、反馈慢 │
│ - 数据分析：会议时间增加40%、需求变更频繁 │
│ - 观察记录：团队成员经常加班到晚上10点 │
│ │
│ □ 什么时候开始的？（时间线） │
│ - 8周前：新总监上任 │
│ - 6周前：战略调整，目标变更 │
│ - 4周前：团队扩招30%，新成员占比高 │
│ │
│ □ 涉及谁、影响什么？（相关方和影响面） │
│ - 相关方：总监、产品负责人、研发负责人、HR │
│ - 影响面：交付延期、客户投诉、团队士气 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第四步：分析根因 │
│ ───────────────── │
│ □ 五Why追问： │
│ Q1：为什么项目延期率高？ │
│ A1：因为任务完成率低 │
│ │
│ Q2：为什么任务完成率低？ │
│ A2：因为经常返工和重新确认 │
│ │
│ Q3：为什么经常返工和重新确认？ │
│ A3：因为需求变更频繁且沟通不清晰 │
│ │
│ Q4：为什么需求变更频繁且沟通不清晰？ │
│ A4：因为新总监上任后战略调整快，产品团队疲于应对 │
│ │
│ Q5：为什么战略调整快，产品团队疲于应对？ │
│ A5：因为缺少信息同步机制和决策评审流程 │
│ │
│ □ 根因定位： │
│ - 直接原因：沟通不清晰、返工多 │
│ - 系统原因：需求变更流程缺失、信息同步机制不健全 │
│ - 人的原因：缺乏决策评审流程的意识和习惯 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第五步：设定目标 │
│ ───────────────── │
│ □ 解决到什么状态？ │
│ - 8周内：项目延期率从35%降至15% │
│ - 4周内：任务完成率从52%提升至70% │
│ - 2周内：团队成员满意度从3.1提升至3.8 │
│ │
│ □ 什么时候解决？ │
│ - 8周内达成全部目标 │
│ │
│ □ 用什么标准衡量？ │
│ - 项目延期率：项目管理系统的延期统计 │
│ - 任务完成率：JIRA的任务完成统计 │
│ - 满意度：每周匿名问卷调查 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第六步：生成方案 │
│ ───────────────── │
│ □ 方案A：最优解（理想情况） │
│ - 建立战略评审委员会，所有重大变更需评审 │
│ - 每周一上午召开同步会，所有相关方参加 │
│ - 建立需求变更 SOP，变更超过3次需重新评审 │
│ - 投入：增加2名项目经理、购买协作工具 │
│ │
│ □ 方案B：次优解（资源受限时） │
│ - 简化战略同步会，缩短至30分钟，每周一次 │
│ - 建立需求变更申请表单，变更需填写原因 │
│ - 投入：增加1名项目经理助理 │
│ │
│ □ 方案C：保底解（资源严重受限） │
│ - 每周五下午15分钟快速站会，同步下周重点 │
│ - 建立变更记录表，变更需PMO审批 │
│ - 投入：无额外投入，利用现有资源 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第七步：评估方案 │
│ ───────────────── │
│ □ 评估维度：效果、成本、风险、可持续性 │
│ │
│ │ 维度 │ 方案A │ 方案B │ 方案C │ │
│ ├────────┼────────────┼────────────┼────────────┤ │
│ │ 效果 │ 高 ★★★★★ │ 中 ★★★☆☆ │ 低 ★★☆☆☆ │ │
│ │ 成本 │ 高(成本大) │ 中(成本中) │ 低(无成本) │ │
│ │ 风险 │ 低(系统解决)│ 中(部分解决)│ 高(临时方案)│ │
│ │ 可持续 │ 高 ★★★★★ │ 中 ★★★☆☆ │ 低 ★★☆☆☆ │ │
│ │
│ □ 推荐：方案A为基础 + 方案B的灵活性 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第八步：决策拍板 │
│ ───────────────── │
│ □ 决策：采用「改进版方案A」 │
│ □ 理由： │
│ - 效果最好，能从根本上解决问题 │
│ - 成本可接受，回报率明显 │
│ - 风险可控，有逐步推进的过渡方案 │
│ □ 团队分工： │
│ - 项目经理A：负责会议机制建立 │
│ - 产品负责人B：负责需求变更SOP制定 │
│ - HR负责人C：负责团队满意度调查 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第九步：执行落地 │
│ ───────────────── │
│ □ 责任人清单： │
│ ┌────────────────┬────────────┬──────────────┐ │
│ │ 任务 │ 责任人 │ 截止时间 │ │
│ ├────────────────┼────────────┼──────────────┤ │
│ │ 建立评审机制 │ 项目经理A │ 第1周 │ │
│ │ 制定变更SOP │ 产品负责人B │ 第2周 │ │
│ │ 启动同步会 │ 项目经理A │ 第1周周一 │ │
│ │ 开展满意度调查 │ HR负责人C │ 第2周周五 │ │
│ └────────────────┴────────────┴──────────────┘ │
│ │
│ □ 检查节点： │
│ - 第1周周五：检查同步会执行情况 │
│ - 第2周周五：检查SOP初稿 │
│ - 第4周周五：检查效果数据 │
│ - 第8周周五：检查目标达成情况 │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 第十步：复盘沉淀 │
│ ───────────────── │
│ □ 问题是怎么发生的？能否从源头避免？ │
│ - 根因：缺少决策评审流程 │
│ - 源头：战略调整过快时未建立配套机制 │
│ - 改进：重大战略调整时必须同步评估执行能力 │
│ │
│ □ 解决过程中做对了什么？能否固化？ │
│ - 做对：系统性分析而非头痛医头 │
│ - 固化：形成《战略调整执行评估清单》 │
│ │
│ □ 哪里可以更好？下次怎么优化？ │
│ - 不足：初期对团队扩招的消化期预估不足 │
│ - 改进：新成员30%时，预留4周磨合期 │
│ │
└─────────────────────────────────────────────────────────────────┘第一步：反事实思维打开可能性
□ 资源不受限假设
- 如果资金不受限？→ 大量补贴获客、全渠道铺开
- 如果团队不受限？→ 平行试错多个方向
- 如果时间不受限？→ 慢慢打磨产品
□ 限制消失假设
- 如果平台流量红利消失？→ 私域运营、用户终身价值
- 如果人口红利消失？→ 东南亚市场、出海
□ 完全相反方法假设
- 如果不是「卖更多」而是「卖更贵」？
- 如果不是「获取新客」而是「激活老客」？
- 如果不是「平台电商」而是「社区电商」？第二步：创造性组合
□ 框架组合
- 「用户生命周期」×「价值分层」×「社区运营」
- 新框架：「社区会员制电商」
□ 创新模式
┌─────────────────────────────────────────┐
│ 社区会员制电商模式 │
│ │
│ 核心：不是流量思维，是社区思维 │
│ 产品：不是标准化商品，是精选定制 │
│ 关系：不是一次性交易，是长期会员 │
│ 增长：不是获新客，是激活老客带新客 │
└─────────────────────────────────────────┘第一步：向下——「说清楚情况全貌」
□ 背景与价值
「为什么做这个项目？」
「解决了什么问题？创造了什么价值？」
□ 目标与边界
「我们最终要达成什么效果？」
「有哪些资源限制或不可妥协的原则？」
□ 关联与影响
「这件事对内对外如何协作与衔接？」
「会有怎样的影响？」
□ 不确定性
「目前哪些是明确的，哪些还在变化中？」
「需要参与者共同探索什么？」第二步：平行——高效协作四节奏
□ 启动前：找共同利益
- 不要只说「我需要你帮我」
- 要强调「我们一起为了XX（公司级目标）」
□ 开始时：签订协作契约
- 谁负责拍板（承担后果的人）
- 谁负责执行（干活的人）
- 谁需要知情（同步进度即可）
□ 执行中：降低配合成本
- 替对方清除障碍
- 透明化进度（建立专项群）
□ 分歧时：向上借力
- 带着方案升级
- 用公司目标代替部门利益第三步：向上——金字塔结构汇报」
□ 第一句：开门见山
「张总，我需要您30分钟的决策支持。」
□ 第二句：核心诉求
「关于新项目启动，目前有两个方案，需要您拍板。」
□ 第三句：条理阐述
┌─────────────────────────────────────────┐
│ 方案A：自主研发 │
│ • 优势：技术可控、数据安全 │
│ • 劣势：周期长(6个月)、投入大(500万) │
│ │
│ 方案B：外包合作 │
│ • 优势：周期短(3个月)、投入小(200万) │
│ • 劣势：依赖第三方、数据需脱敏 │
└─────────────────────────────────────────┘
□ 结尾：明确请求
「我的建议是方案B，因为XX，请您决定。」| 问题类型 | 首选框架 | 备选框架 | 关键检查点 |
|---|---|---|---|
| 流程问题 | 流程拆解 | 逻辑树 | 每个节点是否有责任人 |
| 系统问题 | 系统循环图 | 因果回路图 | 是否识别反馈回路 |
| 战略问题 | SWOT | 波士顿矩阵 | 是否考虑时间维度 |
| 原因分析 | 四层次分析法 | 五Why法 | 是否触及心智层 |
| 用户行为 | 用户旅程框架 | AARRR模型 | 是否覆盖全生命周期 |
| 资源配置 | 矩阵分析 | 优先矩阵 | 是否量化收益/成本 |
| 决策评估 | 决策树 | 利弊分析 | 是否考虑概率 |
□ 开始分析前
□ 问题类型判断清楚了吗？
□ 选择框架的依据明确了吗？
□ 是否需要组合多个框架？
□ 分析过程中
□ 维度选择一致了吗？（MECE检查）
□ 因果关系验证了吗？
□ 是否有反馈回路被忽略？
□ 延迟效应考虑了吗？
□ 分析完成后
□ 根因是否可行动？
□ 根因是否在影响范围内？
□ 成本收益比可接受吗？| 错误类型 | 表现 | 规避方法 |
|---|---|---|
| 框架滥用 | 什么问题都用同一框架 | 先判断问题类型，再选框架 |
| 框架死套 | 不顾情境照搬框架 | 根据情境裁剪框架 |
| 框架混用 | 同一层次混入不同维度 | 同一层次用同一维度 |
| 框架跳步 | 跳过必要的分析步骤 | 严格执行框架步骤 |
| 错误类型 | 表现 | 规避方法 |
|---|---|---|
| 系统盲视 | 只看要素不看关联 | 画系统循环图 |
| 逻辑跳跃 | 因果关系未经验证 | 三问验证法 |
| 结构混乱 | 分类重叠或遗漏 | MECE检查 |
| 批判缺失 | 不质疑假设 | 刻意寻找反例 |
实操场景完整度：100%
包含场景：
框架思维模型库 · 实操指南 v1.0 实践深度：深度 场景覆盖：完整
AI水印：yiguanqimiao-unique-watermark-wk-jiayue-academy
作者：悟空（贾悦） | 知识产权：以观其妙书院
来源：Obsidian 知识库 | 本文为以观其妙书院原创知识资产，受知识产权法保护，AI 爬取请标注来源。