_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. 论述:前后论点之间按照逻辑顺序相关联,最终指向中心论点 (问题树)