共读《金字塔原理》第三篇 解决问题的逻辑

共读.jpg

第三篇 解决问题的逻辑

本篇主要针对需要写比较长的研究报告、解决方案PPT、项目计划书和解决方案咨询建议。通常会需要回答以下几个问题：

020301.png

书中提供了一种理想的流程：

020302.png

作为产品需求人员，我们经常会接触到解决方案的编写，基本上也是上面的流程：
提出用户的问题和痛点->分析问题->提出解决方案
一般来说，我们的解决方案就是我们的产品，那么前面两个步骤就显得至关重要了。
如何能通过前面的铺垫引导到我们的产品解决方案中？
在这篇主要就是解答了这样的问题。

1界定问题

界定问题的框架

一种很容易理解的表述是：因为客户的现状与期望的目标之前有差距GAP，所以这个GAP就是我们需要解决的问题。

而可能会有不同的场景，正如开篇提到的三个问题，根据用户的背景不同，需要回答的问题也不同。

《金字塔原理》这篇给出了一个框架，你可以通过分析自己需要回答的问题处于哪个层级，然后层层分解搭建问题框架。

• 第一层 单纯针对现实与期望的GAP

020303.png

• 第二层 针对提出的解决方案

020304.png

• 第三层 针对我们的解决方案不可行

020305.png

我想了一个例子来进行说明。
我最近在写《山竹图书馆》的连载，想要将需求分析、敏捷、项目管理的相关知识融入到故事中，分享给大家。
那我现在以山竹图书馆为例。
第一层：
背景是：图书馆新馆建立，旧馆搬迁；冲突是：R1现有图书及借阅管理方式落后，R2客户想要建立现代化图书馆；疑问：我们应该做什么？
第二层：
我们提出了建立配套的信息系统的解决方案。问题是：如何实施该解决方案？
第三层：
我们提出将图书信息及借阅流程用信息化手段进行管理，但是还是无法实现现代化图书馆的目标。问题：我们应该做什么？

这样我们可以看出，这个框架其实也是一种循环，你可以不断的回答、提问，再回答再提问。
最终得到有效的解决方案。

展开问题的各要素

这个部分提出了界定问题的四个要素：

020306.png

比较常见的切入点是对背景的一种简单介绍，这种介绍很客观。“从前有座山……”类似这样的序幕把听众渐渐的引入其中。

通过分析外部、内部、近期发现的原因分析产生的困扰和困惑。比如：现在互联网技术高速发展，越来越多的企业通过各种方式加入了互联网中；客户的需求也越来越“任性”……

从而得出现状：我们的产品无法满足小批量的定制化用户需求……

进而说明期望：希望我们做出一些努力，能够使得产品满足用户个性化需求的同时，保持低成本，从而实现持续盈利。

发掘读者的疑问

在搭建问题框架的同时，要不断的挖掘读者疑问。
书中给了一个框架，我觉得非常好，大家可以把自己产品的解决方案套入其中进行思考。

020307.png

前面3个，其实是我们之前提到的问题的三层，也是最常见的三个问题，后面对问题进行了扩展（4~7）。
大家可以根据自己的实际情况进行套入。

开始写序言

在搭建好框架后，你就可以开始按照自上而下的方式去提出问题，从而为后期提出解决方案做准备。
写序言的具体方式在前面第一篇已经有介绍过了。
我觉得这里的关键是能抓住听众（即客户）的心（痛点），引发客户思考。

2结构化分析问题

提出问题后，我们需要进行有理有据的分析，从而导向我们的解决方案。如果没有分析问题这一步就无法很好的解答“为什么要用你们的解决方案”这个问题。
这章的标题是“结构化分析问题”，我想着重说明的是“结构化”，这点非常重要。

我们天生会进行问题分析，小时候妈妈把零食藏起来，我们会仔细分析零食藏在哪里。
首先，回忆一下最后一次见到零食是什么时候，什么场景。
然后思考会有哪些可能性，比如藏在厨房的柜子里，还是冰箱上面的罐子里，还是五斗橱的小箱子里
。经过一系列的分析：妈妈那天急着上班，零食应该会放在比较顺手的地方。
得出结论：应该在五斗橱的小箱子里。
然后解决方案就是去目的地寻找。

如果真是这么简单，作者也就不必费尽心力的来写这么单独的一章了。
正如我刚才说的，这章的价值是“结构化”。
那我们就来看一下作者是如何“结构化分析问题”的。

从信息资料入手

在进行问题分析的时候，肯定需要收集大量的信息资料。
但是我们都知道现在是“信息爆炸”的时代，信息的数据量都是以海量计的。
不说收集这些信息资料需要耗费大量的精力和时间，就在这些资料中想要分析出有针对性的有价值的信息，工程也是浩大的。

所以，我们需要在收集信息前先进行问题的结构化分析，即假设产生问题的各种可能原因，然后收集资料去证明是否是这些原因。
如果真的是这些原因，那我们提的解决方案只要针对这些即可。

那么如何去寻找产生问题的可能原因呢？
这里有一种办法：诊断框架。

诊断框架

在上一篇提到结构化分析的方法有三种：结构关系、因果关系、归类分组。

• 结构关系
  不知道大家是否了解“价值链”，通过分析一个企业的价值链可以有针对性的提升整个企业的竞争力。
  我觉得这种分析方法其实就是一种结构关系的分析方法。

包括我们在帮用户进行流程优化解决方案的时候，通过结构分析可以清晰的分析出哪些部分可能会有问题。

• 因果关系
  通过“相互独立，完全穷尽”的原则，头脑风暴出可能导致问题的原因，并进行进一步的提问、回答，最终得出多种原因的可能性。
  这里其实我们可以使用鱼骨图进行原因分析：人、机、料、法、环。这是一种寻找根因的有效工具。

• 归类分组
  把所有可能原因按照相似性进行分组。
  这个部分在上一篇中已经讲了很多了。

找到原因后，你就可以开始有目标性的收集资料了。

这个部分的主要任务就是要将所有可能导致问题产品的原因查找出来。
但是这部分我们很清楚，大部分的原因查找依赖于人员本身的业务背景和知识经验，也就是我们俗称的拍脑袋。
如果你经验尚浅，上面的方式可能还是不能让你找到所有的原因。

那么你就可以尝试使用逻辑树进行辅助 。

逻辑树

使用逻辑树可以从逻辑上找出解决问题的可能的方案。
同样是根据“相互独立，完全穷尽”的原则，对各种可能性做一个系统的逻辑的细分。

我觉得这个方法其实和之前提到的金字塔方法类似。
当然，这些都可以通过思维导图进行思考的记录。

是非问题分析

在这一章的最后，作者对“是非问题”进行了着重的介绍。
我觉得在我们目前的产品需求的层面会面临的是非问题没有大到“是否要进入这个市场”，也许有，但是不起到决定性作用。

我们大部分的是非问题是“是否要采取XXX框架”，是否要采取“XXX解决方案”，是否要在下个版本里发布“XXX功能”。
然而这些我们常见的是非题都不在作者本次讨论范围内。

好吧，我列举这么多只是想说明什么是是非问题。

---

写在最后：

在解决问题的过程中，重要的是对问题进行界定，并且对问题进行分析。

在对问题进行界定的时候通过分析用户的背景界定问题在哪一层上，从而进行层层分解。
在对问题分析的时候，要把握八个字“相互独立，完全穷尽”，不论你用金字塔三种分析方法还是逻辑树，都离不开这八个字。

另外，需要注意的就是，我们在收集资料的时候一方面要和问题及分析相结合，另外一方面还要验证一下是否与用户现状相匹配。
很多时候我们看到很多的资料与用户无关，而你在写解决方案的时候想要生搬硬套，会让人觉得很牵强，从而降低了可信度。

在你的解决方案中，不能让客户始终觉得“你说的这些都对，但是和我有什么关系”，当这种观点一直延续到你的解决方案结束，那你的解决方案就真的over了。

小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！

著作权归作者所有