_Aleph

# 4S 问题解决法总览

block-beta
  %%{init: {'theme':'neutral'}}%%
  columns 5
起源 PSAC:4
space:5
逻辑推理 演绎:2 反演/溯因:2
space:5
解决思路 做出假设 拆解问题 设计思维:2
space:5
id1["Statement"] TOSCA:2 形成共情 视角陈述
space:5
space:5
id2["Structure"] 假设树 问题树 建立设计要求:2
space:5
space:5
id3["Solve"] 八度分析法:2 EDIPT:2
space:5
space:5
id4["Sell"] id5["设计故事线 + 产出"]:4

id1 --"按需迭代"--> id2
id2 --"按需迭代"--> id3
id3 --"按需迭代"--> id4
id2 --> id1
id3 --> id2
id4 --> id3

# PSAC

咨询之中的问题解决思路：Problem-Solving Approach of Consulting

适用于解决战略问题，由麦肯锡公司 (McKinsey & Company) 开发并完善形成，其基础建立在笛卡尔的《方法论》原则之上。

问题解决方法的形式：

以假设为驱动的思路，是从关于解决方案可能是什么的一个假设起步，对其进行测试和验证的过程。为此，我们使用假设树来实现。其缺点是先入为主，难免让我们掉入采用潜在的解决方案陷阱，学名叫做证实性偏差 (confirmation bias)，即一旦找到能证实假设的证据，便更有可能会相信它们，而非寻找与假设相悖的证据。

以问题为驱动的思路，是将问题拆分成由小元素（即模块：关于典型重复性商业问题的一套已拆分出来的元素，并已预先包装完成）组成的问题树，从而对问题进行全面建构，以系统化的角度来审视问题的不同方面，对解决方案不带任何预设的想法，从而避免掉进采用潜在解决方案的陷阱。其局限性是，使用问题树尽管能拆分问题，但无法保证所有拆分后的问题能够得到解决。同时，使用问题树所需要的分析工作比假设金字塔更多。

设计思维关注的是人们对人工制造出来的物品所产生的体验，因为这些物品代表的是问题解决方案。从最基本的层面来看，问题的存在表面人们的需求和欲望并没有得到满足，表明现有解决方案没能满足人们的需要。设计思维的使命，是将观察转变为洞察 (insight)，将洞察转变为能改变人生的产品和服务。

# 溯因推理

溯因推理就是我们利用有限的观察结果为数据生成最合理、最简洁的解释。这种解释可能并不正确，必须经过检验和论证。运用设计思维的人们，会压制它们自身对问题的假设，利用在观察用户的过程中产生的理解，来提出有关解决方案的假设。随后，人们会以原型的形式对这些假设进行迭代测试，使其收敛为最合适的解决方案。

设计的关注点在于事物应该是怎样的，如何设计出人工制品来满足需求。设计人员构思出一套行动方案，刻意创造出全新的人工制品作为解决方案，将现有的情景转变为理想之中的情境。对于每一个需要解决的问题，都存在一个需要设计出来的解决方案。

# 设计思维 (Design Thinking)

#1 什么是设计思维

哔哩哔哩：一个案例看懂什么是设计思维（Design Thinking）

Design Thinking

设计思维是对人的需求进行观察和挖掘 (Empathize)，并将这种观察和挖掘置于问题解决过程的核心 (Define)。设计思维提倡设计人员对解决方案进行迭代测试，将他们对遇到问题的人（即用户）的了解转化成为解决方案中对用户喜好的明确判断，进而开发出潜在的解决方案 (Ideate)，然后将其转换为原型 (Prototype)。这套原型要能够利用来自解决方案实施者的反馈进行迭代测试 (Test)。

设计思维不是线性的，要时刻准备迭代！

阶段 1：共情

共情的方法

阶段 2：定义

定义阶段要求设计人员：

  1. 使用共情地图（用户画像） / 行程地图 / 洞察卡等工具，对单独的数据进行处理
  2. 对定量的数据进行定性分析，从而将结构化的数据提炼成关于用户问题的一致理解 a. 归纳用户的需求：情感/实体上的需要与欲望，用动词形式表达出用户需要帮助的地方 b. 找到需求背后的洞察：关于用户行为、思考或感受的深度认知 c. 总结所有的需求和洞察，形成设计规则
  3. 定义视角陈述：「用户」需要「需求」，因为「洞察」。
  4. 对视角陈述进行「怎样才能」的提问，形成问题陈述

阶段 3：构思

构思的步骤：

  1. 生成不同解决方案概念，注重数量和多样性，不用考虑质量：
    1. 类比思维
    2. 头脑风暴
    3. 形态分析
    4. SCAPER 问题清单
  2. 利用结构化评估过程进行收敛
    1. 指标：设计标准/可落实性/可行性
    2. 请同行发表看法

指导方针：

阶段 4：原型

将构思转化为实体，为用户创建解决方案的近似物，从而达到学习、管理风险和沟通的目的。

阶段 5：测试

#2 什么时候适合使用设计思维

#3 设计思维的核心特征

# TOSCA 框架

TOSCA 是以下单词的首字母缩写：

在问题陈述阶段，我们需要考虑以上几点，从而使核心问题呈现出来。

Trouble 是期望与结果/愿望与现实之间的差距。为了能够阐述明白 Trouble，可以从以下三点考虑：

Owner 是找出谁应该对 Trouble 负责，参考 RACI 矩阵中的负责人，比如公司中的股东/CEO。问题所有者的意义在于：

Success Criteria 是要描述出成功应有的样子，会发生在什么时候（例如项目管理中的 SMART 原则）。注意在描述达到的目标是什么时，要避免复述 Trouble。在思考成功标准的过程中，一个重要关注点就是要看到其中是否包括明确的可量化目标。

Constraints 是要找出 Owner 面临的约束是什么，应该如何权衡。为此，要考虑以下三种类型的约束：

Actors 可参考 RACI 矩阵中的知情人/咨询者/执行者。按照支持态度，Actors 可分为支持者/中立者/反对者。我们要特别留意潜在的反对者。

# Statement

问题陈述是发现核心问题，并不断塑造问句的迭代过程。

核心问题应该是问句，而非陈述句。问题的范围应该符合 TOSCA 框架：

核心问题的迭代过程，要求 Owner 具备从多个角度/不同利益相关者的视角看待同一个问题的能力。这种能力被称作共情。共情有两种方法：

# MECE 拆分原则

将一个问题拆分成若干个必要条件的子问题，每一个子问题要满足：

# Structure

#1 建构原则

在问题建构阶段，使用 MECE 原则，对假设/问题进行拆分，即所谓的假设树和问题树。一般而言，除非我们相信自己的假设，否则应该使用问题树对核心问题进行建构。

如果使用假设树，则需要考虑：

以问题为驱动的建构形式以笛卡尔《谈谈方法》中提到的四个原则为基础，可以总结为：

#2 建构方法

确定了原则之后，我们就可以使用一些预先定制好的、通用的分析框架，或者说是模型，来切分问题。框架可以分为四类：

面对复杂的问题，单一的框架是远远不够的。我们要集思广益，多维度地征求专业人士的建议，然后综合所有人的框架，形成可以解决某个问题的独一无二的框架。

# Sell

#1 使用金字塔原理推销解决方案

哔哩哔哩-金字塔原理 哔哩哔哩-SCQA

不要在材料报告中展示解决问题的过程 要像问题所有者解释和论证给出的建议

文本架构：

  1. 使用 SCQA 引出核心论点
  2. 使用归类/论述模式构建主线
    1. 归类：所有论点都是对中心论点的支撑 （MECE 原则）
    2. 论述：前后论点之间按照逻辑顺序相关联，最终指向中心论点 （问题树）