极客时间已完结课程限时免费阅读

32 | 5W1H8C1D分析法：P5/P6怎么理解业务功能？

32 | 5W1H8C1D分析法：P5/P6怎么理解业务功能？-极客时间

32 | 5W1H8C1D分析法：P5/P6怎么理解业务功能？

2021-02-12 李运华 来自北京
《大厂晋升指南》
课程介绍

讲述：安晓辉

时长14:16大小13.03M

你好，我是华仔。
对于 P5/P6 级别来说，业务方面的要求主要是理解业务功能。如果你想要快速地入门业务功能，建议使用我总结的 5W1H8C1D 分析法。
这个名字看起来很长，其实它是由 4 个部分组成的：5W + 1H + 8C + 1D，实际操作的时候并不难。
1932 年，美国政治学家拉斯维尔提出了一个 5W 分析法。后来，人们在它基础上补充了 1H（How），形成了5W1H 分析法，这个方法在企业管理、日常工作和学习提升中得到的广泛应用。
我根据自己多年的实践摸索，在 5W 和 1H 的基础进一步补充了 8C 和 1D，从而形成了 5W1H8C1D 分析法，它是指用 5W1H+8C 的思路来分析和理解业务功能，并且在功能上线后熟悉运行数据（1D）。
对于 P5/P6 级别的技术人员来说，这就已经能够基本满足业务开发和晋升的要求了。
这一讲，我会针对 5W、1H、8C 和 1D 这 4 个部分逐一讲解。

5W

我们先来看 5W。不知道你还记不记得，在第 26 讲，我介绍一个 5W 根因分析法，通过 5 个 Why 来挖掘根本原因。
不过这里的 5W 指的是 5 个不同的英文单词：When（何时）、Where（何地）、Who（何人）、What（何事）、Why（何因），代表需求产生的背景和功能上线后的运行环境，类似于操作系统上下文（Context）的概念。
为什么要特别关注需求的背景呢？有两个重要的原因：
首先，客户需求背后的真正问题才是关键。
客户遇到问题之后，往往会基于自己的经验、理解和学识等给出一个解决方案，然后说这是他们的需求。
理想情况是客户非常在行，最好就是软件分析师出身的，能够清晰地分析问题并提出合理的解决方案作为需求。
但现实情况却往往不妙，很多客户对软件的理解可能仅仅停留在 Windows 或者微信上，甚至有些客户认为你会变魔法，只要他说一个“简单的”需求，你就能变出他想要的！
所以，如果我们不主动挖掘需求背后的 5W，就算完美地实现了客户的需求，也可能没有真正解决客户的问题。
其次，理解需求背景有助于设计更好的方案。
需求背景会隐含很多需求相关的信息，而这些信息会影响我们的方案设计。
举个很简单的例子，同样是垃圾桶，放在巴西贫民窟的要求和放在纽约帝国大厦的肯定不一样。
贫民窟可能有很多玩耍的小孩，将垃圾桶作为足球的射门目标，这样对垃圾桶的牢固性要求很高，对美观性就没什么要求了。
而在帝国大厦上班的大多是西装革履的白领金领，对美观性有比较高的要求，但对牢固性就没什么特别的要求了，毕竟不会经常有人去踢垃圾桶。
那么，这 5 个 W 分别是怎么回事儿呢？我一个一个地来讲吧。
第一个 W 是 When，代表和时间相关的信息，常见的有：
季节信息：春夏秋冬等。
日期信息：节日、假日等。
作息时间：白天、晚上、凌晨、早晨、上午、下午、晚上、深夜等。
比如我在某通信巨头公司做设备的时候，如果是做数据倒换工具，都要求设计得非常智能，最好是一键式操作。
为什么呢？因为数据倒换都是在晚上凌晨 2～4 点进行，这时操作人员最困、思维最迟钝的时候，如果你做的数据倒换工具需要操作七七四十九大步，九九八十一小步，并且只要一步出错就全部重来，那么谁还敢去操作？
第 2 个 W 是 Where，代表和地点相关的信息，常见的有：
国家、地区：不同的国家和地区有不同的文化、风俗、制度等。
室内、室外、街道。
建筑物。
交通工具，比如上下班做地铁，开车等。
比如我们的这门课程包括包括图文和音频，图文适合在不那么拥挤的地铁上看，但是如果你开车的话，就只能听音频。
第 3 个 W 是 Who，代表和参与者相关的信息。
注意，我这里说的是“参与者”，而不是“人”。为什么呢？因为很多外部参与者不一定是人，外部系统和动物这些都可以算参与者。常见的参与者信息有：
投资者、管理者。
使用者、维护者。
监督者、评估者：包括政府机构、监管机构等。
交互者：与当前系统交互的其他系统。
比如对于银行的 ATM 机，参与者有以下这 4 类：
顾客：使用 ATM 机器取款、存款。
银行维护人员：每天将钱放进 ATM 机器。
质检机构：根据 XX 法律对 ATM 机进行检查。
银行 IT 系统：ATM 机需要与银行的 IT 系统交互。
第 4 个 W 是 What，代表客户想要的输出结果，比如一个文档、一份报告、一个图片、一个系统和一个产品等。一般情况下，这也是我们看到的最原始的需求。
第 5 个 W 是 Why，代表客户遇到的问题。
问题是客户提出需求的驱动力，只要是客户觉得不爽的地方都属于问题的范围。
在这 5 个 W 中，Why 是最关键的，因为只有真正了解了客户提出需求的驱动力，才能真正解决客户的问题，而只有真正解决了客户的问题，那么客户才会真正满意。这也是为什么在晋升答辩的时候，评委问的最多的就是 Why，比如“为什么要做这个需求？”“这个功能解决了什么问题？”
下面这张图形象地描绘了 5W 之间的关系：

1H

H 代表 How，也就是如何，它和 5W 共同组成了 5W1H 分析法，又叫六何分析法。
在分析和理解业务的时候，How 不是指设计方案，而是指业务需求的处理逻辑。
需求有简单和复杂之分。有的需求可能很简单，客户想要的东西很明确，一两句话就能够说清楚；但绝大部分需求都没有这么简单，一般会涉及到多个步骤、多次交互和多个状态变化等，这种情况就要把需求的处理逻辑描述清楚。
比如取款就是一个需求，但它包含多次交互，要插卡、输入密码、输入金额、打印账单、取钱这一系列步骤，How 就是用来描述这整个流程是怎么运行的。

8C

5W1H 关注的是需求的功能属性，而 8C 关注的是需求的质量属性。需求最终是不是真正以合理地方式实现了，既要看功能属性是否满足需求，也要看质量属性是否符合要求，两者缺一不可！
所以我们还需要加一些约束条件（Constraint），也就是我所说的 C。这个约束条件怎么理解呢？
不知道你还记不记得，我在第 23 讲中提到过，OKR 中有时需要添加有些辅助指标，比如光说“新增用户数 2000 万”可能还不够，还得加上“投入资金不超过 1 亿”和“新用户月留存率不低于 40%”。
因为如果疯狂通过红包刺激提升新增用户数，一来花钱太多，二来吸引的大部分是羊毛党，很难转化为忠实用户，这显然不是我们真正想要的。
其实约束条件就相当于这些辅助指标，它们的作用是一样的。
对于业务需求，我总结了 8 个 C：
性能（Performance）
性能是指系统提供相应服务的效率，一般包括响应时间和吞吐量，是很多系统架构设计的关键约束条件之一。
比如同样是提供信息给用户浏览的 Web 网站，一个日访问量 1 万，一个日访问量 10 亿，它们的设计是完全不一样的。
成本（Cost）
成本是指为了实现系统而需要付出的代价，也是很多系统架构设计的关键约束之一。
比如客户只愿意出 100 万来买这个系统，最后我们却设计了一个耗费 1000 万的系统，要么客户不愿买，要么我们自己亏损降价。无论哪种结果，最后都是我们赔本。
时间（Time）
时间是指客户要求的交付时间，它会影响项目的进度安排，从而会影响项目的设计方案。
比如一个项目的交付时间很紧，那么系统设计可能就不能太复杂或者太庞大。
技术（Technology）
技术是指客户指定的技术。
比如客户现在用的都是 Windows 的机器，那么就可能要求我们基于 Windows 平台开发。
可靠性（Reliability）
可靠性是指系统长时间正确运行的能力。
比如出于法律法规或行业统一标准，银行、证券和电信这些公司对宕机时间有严格的要求。
安全性（Security）
安全性是指对信息安全的保护能力。
比如涉及到钱、身份证号和社会保险号等隐私信息的需求，在这方面的要求很高。
合规性（Compliance）
合规性是指满足各种行业标准、法律法规、规范等，比如 3C、SOX、3GPP、ITUT 等。
尤其是对于金融类相关的业务来说，政府监管要求和法规要求是非常严格的。
兼容性（Compatibility）
兼容性是指我们提供给客户的系统与客户其它已有的系统兼容的能力。
这个约束主要在 2B 领域比较常见。特别是在大企业、大公司中，多个系统都是互相交互、互相配合的。新的系统必须能够和已有的系统配合，否则将无法运行。

1D

D 代表 Data，也就是数据，反映了业务上线之后的效果（Result）。
我之所以不用结果对应的单词 Result，而要用 Data，是因为说到效果，很多技术人员的思考都很简单，只有超出预期、符合预期、不达预期 3 个结果。但是这种理解不管是在日常工作还是在晋升答辩的时候，都是远远不够的，所有的结果最好都能用数据来说明，所以我特意选择了 Data 来强调这点。
常见的 Data 包括两个方面：
一是业务效果，比如 DAU、MAU、活动参与人数、订单数、成交量、成交额和运营效率等。
二是系统效果，比如峰值 TPS、接口性能、响应时间、崩溃率、可用性、成本和开发效率等。
至于要怎么总结数据，你可以采用第 28 讲介绍的 4D 总结法。

小结

现在，我们回顾一下重点内容。
P5/P6 级别在业务方面的要求主要是理解业务功能，可以通过 5W1H8C1D 分析法快速入门，上线前分析和理解业务功能，上线后熟悉运行数据，
5W 包括 When（何时）、Where（何地）、Who（何人）、What（何事）和 Why（何因），代表需求产生的背景和功能上线后的运行环境；H 是指 How（如何），代表业务需求的处理逻辑。
8C 包括性能、成本、时间、技术、可靠性、安全性、合规性、兼容性，代表保证质量符合要求的约束条件（Constraint）。
D 是指 Data（数据），反映了业务上线之后的效果，包括业务效果和系统效果。

思考题

这就是今天的全部内容，最后留一道课后思考题给你吧。能不能采用 5W1H8C1D 分析法来分析一下你做过的一个典型的需求呢？你在分析的过程中有什么新的收获吗？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 16

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
31 | 导学：为什么业务和管理是晋升高级别的基石？
下一篇
33 | AARRR漏斗模型：P7/P8怎么掌握业务领域？
unpreview
 写留言

精选留言(12)

  • 王同学
    2021-02-20
    接手一个项目维护的工作，5W1H8C1D可以快速了解业务。但是没有有质量的文档，就没法按照5W1H8C1D快速了解业务，基本上靠遇到问题就问的口口相传的方式，但是总感觉理解很片面，请问这种情况下有什么好办法可以快速了解业务？

    作者回复: 如果我是新人，我的做法是自己来画核心功能的系统序列图，一般一个系统的核心功能不会超过10个，掌握了核心功能后，很多其它功能基本可以触类旁通。 如果我是刚接手一个团队，我会要求团队成员花时间整理核心功能的系统序列图，沉淀成文档。

    32
  • 银剑
    2021-02-23
    5W1H1D都挺好理解哈，就是对8C这个有点疑问，个人理解8C中的性能和可靠性应该是对标架构设计的三大基本要求之二吧，还有成本和时间是项目管理四要素的其中两个，技术、安全性、合规性、兼容性这几个都属于非功能需求。 那么问题就是为什么是选择这8个出来组成8C，架构和项管没列入的扩展性和需求范围也很重要吧，而选入的如技术和合规性这种非功能需求并不是通用的，那为什么不选择其它的非功能需求呢，而且说是质量属性，技术和合规性跟质量感觉也不是很搭呀，所以这个有点迷惑的感觉。
    展开

    作者回复: 性能不一定是架构设计才要求的，很多需求都要考虑性能和可靠性。 时间、成本、技术、安全性、合规性、兼容性是非功能需求，但是是要基于功能需求来的，如果你做过2B的业务、外包业务、内部各种管理支撑系统，对这些就会有更深的理解。

    共 2 条评论
    8
  • humor
    2021-02-20
    老师，有两个学习方面的问题， 1.我听说写代码大部分都是粘贴复制，修修改改，既然现在搜索引擎(百度，谷歌)那么发达，想要什么功能都可以百度到，那我们还有必要学习吗，想写什么功能直接百度不就可以了吗？ 2.还有高级别和低级别的开发的最大差别是什么呢？我感觉就是知识的深度和广度，但是这些知识在百度都可以搜索到啊，用到的时候直接搜不就可以了吗？
    展开

    作者回复: 搜索引擎可以帮助你了解API、代码的基本编写步骤，但是没办法告诉你如何写出实现你业务功能的代码。 高级别的开发和低级别的开发最大的差别是：高级别的人知道怎么做最好，低级别的人知道怎么做才能完成。 形象点来说，很多技术点，如果别人不告诉你，你根本不知道去搜什么关键字。例如，你知道false sharing对性能的影响么？如果别人没告诉你，你可能永远都不会想到去搜这个东东。

    7
  • 胖子
    2021-02-27
    若是单从理解业务功能的角度来看，8C可以不用吧？

    作者回复: 就是为了约束业务的呀，只是不同的业务有不同的C而已，例如如果你给2B业务，成本、合规等就比较很常见；做2C业务，性能、可靠性、安全就比较常见。

    3
  • 彦君
    2021-04-01
    5W1H的核心是Why，这个认知很重要

    作者回复: 当你清楚why后，如果你觉得产品的需求不合理，可以直接用why来分析。

    2
  • Geek_a2e439
    2021-02-18
    我之前总结过并指导自己的是5W1H1B，B是标杆，规划需求前需要先搞清楚标杆是怎么做的有没值得借鉴的。 学习这篇后就是 5W1H1B1D8C～目前主要用于检查

    作者回复: 挺好的，标杆的作用可以用于对比和学习，只是有时候可能没有标杆，你自己就是标杆 ：）

    2
  • 怀揣梦想的学渣
    2022-07-08
    8C中，成本的约束，使部分项目的开发倾向于功能插件化的开发，客户勾选一个功能就加点钱，客户感觉预算超了就取消部分功能的勾选，无论选不选，功能都打包存在，让客户去纠结和选择。有的客户会在使用时临时加预算，有点像网上买电脑说的3千预算进贴吧，最后消费2万多。仅限于我自己遇到的部分场景。

    作者回复: 这个设计很不错啊 ：）

    1
  • 毛成方
    2023-01-09 来自广东
    需求：用户签到获得积分 5W:在零点之后用户会习惯打开某APP 在个人中心首页点击签到以获得签到积分奖励 H：处理好签到获得积分结算以及签到中心积分展示逻辑 8C：性能： 成本：预算10W 时间：3个工作日 技术：后台：Java 客户端：安卓和iOS 可靠性：一旦宕机 用户之前的积分可恢复 安全性：用户签到积分不会被黑客获取不会丢失 合规性：符合法律法规 兼容性：积分结算系统要和卡券、商城消费等系统打通。 1D：查看每天成功签到的人数以及积分结算结果
    展开

    作者回复: 思路OK

    共 2 条评论
  • 白茶清欢
    2022-02-14
    1D包含了业务指标和技术指标，理论上讲业务指标和运营关系更大吧，能作为晋升的参考吗？

    作者回复: 都可以，技术上的数据和业务上的数据都能够作为晋升参考

  • MAX
    2021-09-11
    为什么是8C，英文单词前缀不一样，很难联系起来

    作者回复: Constraints，“约束”的英文单词

  • 周平
    2021-04-22
    对公司的主要产品，做了一次5W1HnC1D的分析。虽然是非常浅的思考，感觉如果深入一下，还是有很多工作量，尤其是对1D来说，但还是有一些收获的，相当于站在一个高度，对产品进行了一次建模。 我认为这套方法论就是对产品建模的方法论。 本堂课拓展了我对Who的理解，很多外部参与者不一定是人，外部系统和动物这些都可以算参与者。 对于时间，地点的举例，让我也发现，原来这些也算做时间，也算作地点，我思考更加宽泛。 也明白了什么是How，在分析和理解业务的时候，How 不是指设计方案，而是指业务需求的处理逻辑。 我想对于算法来说，就是这个结果是怎么得出来的，公式是怎么推导的。 后面有机会，对每一项5W1HnC1D再深入分析一轮。
    展开

    作者回复: 多尝试，熟练后学习业务就很快

    共 2 条评论
  • 小司
    2021-02-14
    有个疑问5w根因分析法，跟这里的when，who，what…使用场景的区别能总结一下吗？

    作者回复: 两讲里面都分别介绍了各自的应用场景呀😂😂