三读《有效需求分析》，我有这些感受想分享给你

一、谁适合读此书？

《有效需求分析》这本书其实在产品圈内挺出名的，尤其是B端产品经理的圈子中。很多朋友看过了之后都大呼“过瘾”、“牛逼”、“很赞”，我自己第一遍看完的时候也是这样的感受。

但是等我第二遍去看的时候，我突然发现我好像很多内容都没有看懂，感觉除了一些很令人惊叹的案例比较有印象之外，其他的一些内容再看的时候完全都想不起来。

这周末我又翻起来了这本书，准备第三遍去看它，而且还用了铅笔做标注和笔记。这次阅读很快，没有拖拉，基本上2天时间就全部看完了。除了一些精华知识之外，我还看到了一些其他的东西，是我第一遍和和第二遍看的时候都没有发现的内容。这些内容很关键，让我对此书的判断有了更加深刻的理解，而不是人云亦云般地跟着夸，跟着推荐。

关于这本书适合谁来读，我先将结论放在前头：

1. 没有2年以上的产品经验的朋友不建议看此书；
2. 没有做过中大型的B端产品项目的朋友不建议看此书；
3. 没有一定的技术基础或者深入体会过项目从0到1过程的朋友不建议读此书；

当然，以上只是我的建议，不建议读不代表不能读。只是说如果不满足条件去阅读，那么此书的功效只能发挥一点点，你看完了之后可能会发现它并没有传说的那么玄乎……

二、此书的精华有哪些？

1. “我们不是在画活动图，而是在做流程分析；不是在画类图，而是在厘清数据关系；不是在画用例图，而是在识别场景”。

以上这句话，如果你能get到全部，并会在工作中灵活运用它。那么恭喜你，在产品方法论方面有了自己的一套体系。

2. “传统的需求分析是站在技术视角展开的，关注的是‘方案级需求’；而业务驱动的需求思想则是站在用户视角展开的，关注的是‘问题级需求’”。

开篇的这部分内容是我初看此书最为震撼的一点，以前我们总是说不要听客户说什么，而是要去分析客户背后真正的意图是什么，需求是什么的。其实简单总结一下就是：我们要分清楚，什么是方案级需求，什么是问题级需求。

之前张小龙戏称每天都有1亿人在教他做产品，其实这些用户提出的需求大多数都是方案级需求，例如“微信的语音不能拖动进度条，不能加速播放”，“微信不能互删好友，应该要像QQ一样进行互删”，“微信文件传输的大小限制应该提高到1G”……

如果直接听客户反馈的方案来做，那么一款产品就会慢慢地被用户主导，无节制地蔓延和扩散。

所以，书中举出的“吃饼干”的例子很真实，我觉得比“墙上钉钉子挂画”的例子要接地气的多了。小孩子半夜要吃饼干，本质是因为饿了想吃东西，而不是一定非要饼干。

3. “从宏观角度来看，组织应用类软件系统需求可以分为价值需求（目标场景、干系人关注点、干系人阻力点）、详细需求（对应前面的背景，也分为3个线索）两大部分。价值需求主线包括目标场景，干系人关注点、阻力点两个角度；而详细需求则由行为需求（也称功能需求）、数据需求、非功能需求三条主线组成”。

本书的精华知识都在上面的这张图上，作者也是按照上述的框架来行文的。此处重点关注详细需求模块中的三个主线：

1. 功能主线；
2. 数据主线；
3. 非功能主线；

这三个模块是书中的重点，也是最难理解和串联起来的部分，如果你觉得自己没有看懂这本书，那么很大可能就是这三个模块没有串起来，可以重点多看几遍，带着问题去思考。

4. “需求=预计-现状”。

我觉得这个公式可以和俞军的产品价值公式（产品价值 = （新体验 – 旧体验）- 迁移成本）相媲美了。很多时候我们一直在聊需求，需求，需求的，那么什么是需求，当我听到需求的时候我应该关注什么？

这个公式就给出了答案，当你听到“需求”的时候，你应该关注预计和现状。用户的预期是什么样的，现状又是什么样的，这些都需要去调研，只有这两块一起抓，才能更加准确的把控“需求”。而不是嘴上天天挂着需求，但是却像无头苍蝇一样，只会盯着客户想要的东西，一直对比竞品有什么。

5. “我们才是解决方案专家，客户只是问题专家”。

只有先定义好了问题，才对其原因进行分析，然后制定相应的解决方案。所以，先收集问题，然后再分析问题，最后再明确解决方案。这三步听起来似乎很简单就能做到，但是现实是能按顺序且各个阶段彼此独立去完成的人很少。

例如我自己在收集问题的时候就很容易拿到问题就开始分析，然后分析了一顿之后可能卡住了，就不知道自己接下来是攻克这个问题还是继续收集问题，或者是其他了。简单概括一下就是：别忘记自己到底在这个环节要做什么！

6. “主、变、支流程的分类是为了帮助大家更好地识别流程，别陷入它是哪类流程的细节争论”。

之前有一些产品朋友和我交流流程图相关的知识，会发现一些流程图给我看看，其实我评价流程图画的好不好主要就是看三个点：

1. 基础的对齐，布局是否清晰，阅读无障碍；
2. 有没有区分核心流程和次级流程，也就是否含有主、变、支流程的层级；
3. 是否传达了清晰的意思，让我一个非业务认识也能迅速了解其含义；

其中第二点其实很重要，也是很多产品新人朋友很容易犯错的一个点，觉得流程图就是要大而全，然后很多分支，很多判断，很多元素，看起来才会让人觉得这个画图的人很牛逼。但是其实这显然是一个误区，作为一个阅读者，我要在庞大的信息中找到我想要的内容或者迅速上手这些东西，会特别累，也很低效。

所以当我们在梳理一些比较复杂的业务流程的时候，不妨试着采用“主、变、支”的分层方式来思考并绘制流程图。

主线流程：正常情况下，完成此业务的主线流程是什么样的？用户最常使用到的流程是什么？提炼这些东西，就是主线流程；

变体流程：除了正常情况之外，但是也可能很高频出现的流程有哪些？例如在电商平台下单购买是主线流程，那么修改地址，取消订单，修改备注等都是变体流程；

支撑流程：还是上面的例子，我们要搭建电商购物的流程，除了主线流程和变体流程之外，我们也要考虑一些支撑的流程，例如支付流程，客服售后流程，物流轨迹跟踪流程等；

如果我们没有采用这种层级划分，而是一条路走到黑，那么这个业务流程图肯定很复杂，阅读者也很难get到全面的信息。

7. “数据与信息是有差距的，而这个距离就是‘Why’所带来的，多问问用户为什么要看到这些数据，基于这些数据有什么作用……”

书中举了一个天气的例子，这个例子在朋友圈中我就完整地经历过。

有一次我看到杨堃老师来深圳出差的时候发了一条朋友圈，大意是“来深圳之前，查看了一下深圳的天气预报（可能是18°左右），以为会冷，结果穿的太厚了，下了飞机赶紧脱衣服”。然后过了一段时间之后，深圳降温了（可能是15°左右），他又来了深圳出差，这次他又发了一条朋友圈，大意是“上次来深圳穿的太厚了，然后我这次少穿了点，结果下了飞机冻成狗” 。后来第三次的时候，我看到他还没出差的时候就发了朋友圈问“各位深圳的朋友能不能告诉我现在深圳穿什么衣服，我两次都没有摸准，这次我决定先问问大家再考虑穿什么”……

去异地出差前看天气预报，了解大概多少度，这个在我们生活中很常见。但是多少度并不能帮助我们解决问题，因为我们想看多少度的本意其实不是为了看到数据，而是为了拿到信息。

数据并不一定是信息，数据可能与信息有很大的差距。

通过以上的案例，让我们试着去思考一下工作中我们经常做的一些和数据相关的报表类的工作是否也有步入误区。例如给用户看到的数字，图表，图示到底是数据还是信息？用户在这个场景下，到底是要数据还是要信息或者是其他的？我们有把控精准客户的需求是什么吗？

这个案例对我有很大的启发，希望你也能有所收获。

8. “领域建模的核心目的在于厘清系统中应该引入哪些业务数据（范围），它们之间是什么关系，因此业务数据越多、越复杂，领域建模的工作就越重要”。

书中提到了一个“四色建模法”，相比较干燥地叙述如何进行“领域建模”，这个方法更加通俗而且容易查缺补漏。但是我自己对领域建模这一块的理解还不够深刻，所以我从网上摘录了一些解释，感兴趣的朋友自己搜索关键词进行学习，以下内容均来自网络。

• 时标型（Moment-Interval）对象（也称为过程数据）：具有可追溯性的记录运营或管理数据的时刻或时段对象，用粉红色表示；
• PPT（Party/Place/Thing）对象（也称为自然数据）：代表参与到流程中的参与方/地点/物，用绿色表示；
• 角色（Role）对象：在时标型对象与 PPT 对象（通常是参与方）之间参与的角色，用黄色表示；
• 描述（Description）对象：对 PPT 对象的一种补充描述，用蓝色表示；

三、我如何评价此书

为了写这篇读书笔记，我又重新翻阅了一遍这本书，相当于到现在为止其实我已经阅读了4遍了。此书有一些内容确实很赞，会让人时不时有那种“啊哈moment”，但是多阅读了几遍之后我还是发现了一些瑕疵，所以我把自己的一些观点放在最后。瑕不掩瑜，此书还是可以称为YYDS，我依然一如既往对它打高分。

1. 前期的行文结构混乱

我看书的时候经常会先去看看目录，看看有没有什么精彩的内容可以先阅读，或者了解一下大概本书会讲什么内容。本书前面几章的连贯性不强，虽然整体结构是总—分—分结构，但是前期的“总”部分没有做到很好的提纲挈领的作用，导致阅读的时候会有点割裂。

为啥这个时候是讲这个？我想看的内容啥时候讲呀？怎么这个章节说的内容和前面的章节没有连贯起来呢？

2. UML的一些知识没有讲清楚

“数据主线子篇”有很多案例很丰富，但是作者的行文风格还是有点太“IT化”，对一些比较生涩的概念解释不够清晰。所以我在前面推荐的时候就说了，此书适合有一些IT基础或者有从0到1经验的朋友阅读。如果你没有基础，那么此章节的内容可能会看不太懂或者似懂非懂，其实并没有什么效果。

如果想要对UML的知识做一些补课，那么我首推《火球：UML大战需求分析》这本书，如果对这一块的内容啃的差不多了，也可以试着阅读《大象：Thinking in UML》这本书，不过此书难度很高，不太好啃。

3. 虎头蛇尾，最后的几章草草收尾

上面我摘录的精华知识，其实大多数都是前面几章的，后几章的内容篇幅很短，也有点草草收尾的感觉。

除了这个之外，一些关键的章节或者知识点的完结部分也没有做总结和案例分析，如果你看完了，可能就看完了，之前看过了什么可能就不太记得了。

所以，这本书确实是需要多看，反复看几遍，在脑海中形成了知识图谱之后才能完整地将所有的知识串联起来。