一文讲清业务分析

随着互联网行业的迅猛发展，我们越来越多地在各大招聘网站上看到业务分析师的职位。随手翻翻产品经理类、项目管理类书籍，业务分析、需求挖掘等词汇也是接二连三映入眼帘。那么，业务分析究竟是做什么事情呢？本文将带你了解该领域的核心概念，分享作者基于这些核心概念积累的实践经验和心得体会，力争一文讲清业务分析。

国际商业分析协会IIBA 2015年发布的BABOK（商业分析知识体系) 3.0版用下面一句话进行定义：

业务分析是结合组织情境，通过定义需要、推荐解决方案，实施组织所需要的变更的实践过程，实施变更的结果能够对利益相关者产生价值。

此定义高屋建瓴地解释了什么是业务分析，清晰明了地阐述了为什么要做业务分析 (为了实施变更，产生价值)， 如何做 (通过定义需求, 推荐解决方案)，在什么样的情境中做 (基于组织需要)，以及为了谁做(为了利益相关者)等问题。同时，业务分析领域的6个核心概念完美地融入其中。

业务分析核心概念模型包含如下6个概念:

• 需要 (Needs)

• 变更 (Changes)

• 情境 (Context)

• 利益相关者 (Stakeholders)

• 解决方案 (Solution)

• 价值 (Value)

其中每一个概念都和其它概念息息相关。比如，脱离了需要去谈变更没有意义，变更又发生在一定的情境之中；或者，变更发生了，但却没有和组织战略目标对齐，没有解决利益相关者真正的问题，那么前面所做的工作还有什么意义？不仅没有产生业务价值，反而浪费了组织资源。

下面，我们将逐一展开对这些核心概念的讨论。

业务分析核心概念模型

“需要”可能是组织或产品中存在的亟待解决的问题，也可能是利于组织或产品下一步发展的商机，这些问题或商机促使利益相关者采取行动，实施变更。“变更”是为了响应组织或者产品的发展需要采取的行动。“变更”从“需要”出发，目的是为了解决问题或者提高组织的绩效。

那么，怎么才能根据用户需要产生其期望的变更呢？这就是业务分析要达到的目的了。而业务分析最关键的一步，在我看来，是挖掘出真正的需求，这是设计正确解决方案、实施有效变更的基石。

（1）需求挖掘

常见的需求搜集方法有用户访谈、可用性测试、调查问卷、数据分析等，这些方法在市面上很多产品类书籍中都有介绍，本文不再对各种方法进行赘述。当业务分析人员接收到搜集来的需要，不管该需要是从组织层面自上而下传达的、为满足组织转型而制定的战略规划，还是来自终端用户对现有产品的反馈期望，我们不能假定项目发起人说的都是对的，也不能假定用户提出的要求都应该按其描述的来满足。挖掘“需要”背后的原因，而不是仅仅停留在用户描述的表面，把“需要”提炼为需求，这才是业务分析的价值所在。

5WHY分析法作为一种诊断技术，通常被用在质量管理领域以寻找问题症结所在，其实这种连续追问的思想也非常适合应用于需求的挖掘和筛选。很多产品人在论述不能停留在用户描述的表面、要通过现象看本质时经常引用下面的故事。

亨利·福特问消费者他们想要什么。

消费者：”我想要一匹更快的马！“

如果亨利·福特的需求挖掘停留在这里，那么消费者最后得到的可能是一匹英国纯血马（相当不错了，据说是世界上跑得最快的马）。

不过，故事中咱们的亨利·福特又发问了，”你为什么想要一匹更快的马咧？“

消费者：”我想要更快地从纽约到费城！“

于是，需求挖掘完毕，亨利·福特捣鼓捣鼓，福特汽车诞生了。哇，超出期望满足消费者需要！而且才用了一个WHY。

但是，如果消费者回答的是：“我想赢得赛马比赛冠军！” 那么，一辆汽车还是比一匹快马更好的解决方案吗？显然不是了。因此，多问几个WHY，搞清楚用户为了什么提那个“需要”，才能保证提供的方案是在正确的方向上。

另外一个简单易用挖掘需求的小TIP，是转换编写用户故事的思维。通常，用户故事按如下格式来表达：

作为一个<角色>， 我想要<活动>， 以便于<商业价值>

我们试着变换一个词：

作为一个<角色>， 我需要<活动>， 以便于<商业价值>

从”想要“到”需要”，这是一个思维角度的转换。“想要”是用户从自己看待问题的角度出发，提出解决问题需要采取的行动。“需要”是从我们看待用户面临的问题出发，思考用户的需求。别小看“想要“和“需要”，工作中经常遇到这种情形，我们拿到的需求看起来像个解决方案：

慢着，动手之前咱先问问，小A想要按钮大一点的原因是什么？是目前的按钮太小不方便点击？还是按钮位置不够明显无法吸引用户注意？小B导出页面数据的目的又是什么？他要把查询结果打印出来参考？还是导入其它系统作为一种数据输入？

答案不同，解决方案可能也大相径庭。一点写法的改变，会迫使我们去理解“想要”背后的“需要”，挖掘深层次的需求。

（2）践行MVP，快速迭代

需求挖掘清楚了，我们终于搞明白了用户需要什么。随之而来的一个问题是，用户想要的功能那么多，我们要全盘接收全部满足吗？哪些功能先发布，哪些功能后发布，有没有什么推荐的顺序？

美国一家专门从事跟踪IT项目成功或失败的权威机构，Standish Group，在其2018年CHAOS Report报告中指出，一个产品提供的所有功能特性里面，大约有50%的特性几乎从来不会被用到，即使对所谓的关键业务，亦是如此。用户常用的功能特性占比20%左右。

数据来源：Standish CHAOS Report

这说明了什么问题？这说明了即使是对一个验证过的、真实有效的需求，项目团队在早期辗转反侧、各种取舍所做出的很多精巧的设计，上线后可能根本无人问津! 同时，这也提醒我们在需求挖掘时要识别那20%核心功能，那是产品的立身之本。

不管是从0到1推出一个产品，还是为现有产品增加一个新特性，定义MVP（Minimum Viable Product，最小可行性产品)，根据MVP快速开发产品、投入市场，获取用户反馈；进而，基于用户反馈获取到的用户使用习惯及期望，围绕核心功能增加其它功能特性，快速迭代，这是“时间就是金钱、效率就是生命”的互联网时代产品开发的正确实践方式。

图片来源：网络

2018 CHAOS Report 中还提供了一个研究结果，当产品特性和功能比需求规格说明书中提供的少、但恰好满足必须的需求的时候（Just enough），用户满意度和项目价值体现反而是较高的。那50%几乎从来不会被用到的功能，不仅增加了项目成本、风险，耗费了人力、物力，却很遗憾没能产生价值。

然而，问题又来了，怎么判断一个功能要不要放在MVP呢？

这不仅跟需求本身有关，也跟产品所处阶段有关。根据需求金字塔，它是属于基本型需求，期望型需求，还是兴奋型需求？产品目前是开发期、成长期还是成熟期？通常来说，基本型需求是一定要满足的，兴奋型需求优先级可以稍微低一点。但是，根据产品的发展需要，你可能需要利用某个“兴奋点”去和对手做差异化竞争，那么，这个兴奋型需求也应被考虑规划在MVP中。

综合考虑产品构建过程中竖向切分用户需求的思想，推荐的实践是以基本型需求打底，让产品首先”可用”；在可用基础上尽量满足用户期望型、兴奋型的需求，让产品不仅“可用”，而且”好用“，使用过程还能有愉悦的感受。

图片来源：网络

如何给需求排优先级，如何定义MVP，这个话题有机会我们单独展开讨论，不过作为带你了解业务分析的第一篇文章，奉上业界流传的简单粗暴但切实可行的一句话，”砍掉这个功能，产品还能用吗？“ 这是一句金玉良言，有机会给需求排优先级的时候试试问自己这个问题，你就能体会到它的精妙之处。

上文我们提到产品所处阶段会对MVP的定义产生影响，产品所处阶段就是一种情境。情境，是环境中与变更相关的一切，小到项目团队技术选型、迭代速度，大到国际环境、商业氛围、组织文化，都可能会对项目产生积极或者消极的影响。

近期，因为新冠疫情的影响，国内外经济普遍下滑，项目被叫停或者缩减范围的不在少数，此类没有征兆发生的事件对项目的影响是巨大的，但因为其不可预见性，很难被作为一种情境因素在项目之初被考虑进来。需求挖掘中考虑的情境更多指的是可观察到的、可感知到的、或者可分析、可预测到的商业环境。

网上流传一道经典的需求分析案例：回到1999年2月腾讯推出Beta1 QQ的第一个公开版本，其MVP该从下列选项中选哪3个特性？

1.  卡通头像

2.  不可窃听安全通讯

3.  聊天室

4.  速度超快0.5秒反应

5.  语音

6.  视频

7. 看谁在线上

8. QQ表情、皮肤

......

网络上很多产品经理、业务分析人员给出了各种版本的答案，你，又会怎么选择呢？追求安全第一选不可窃听通讯？追求性能至上选0.5秒快速反应？或者，干脆，老板说选啥就选啥！

当年腾讯产品经理是这么选的：

1. 卡通头像

3. 聊天室

7. 看谁在线上

他们主要考虑当时其它IM竞品提供的功能，结合带宽不高、网民不多、网民安全意识薄弱等诸多商业因素，制定出MVP想要达到的目标：让用户登录QQ后，能很快找到一个可以聊天的人，所以看谁在线上和聊天室功能就尤为重要。至于大家都觉得不怎么重要的卡通头像，那可是其它IM工具都没有的惊喜功能。

这种选择，在当时虽然造就了QQ的极大成功，但是，从今天的角度来看，腾讯的产品经理恐怕也要重新思考了。如果一个软件反应速度极慢，用户试用一两下直接就卸载了。还有，面对各种频发的密码泄露事件，你觉得用户会认为卡通头像和聊天室比安全通讯重要？ 每个人的答案不尽相同，但是结合这个例子，我们至少能理解，产品的构建过程是受”天时、地利、人和“等情境因素影响的，而需求优先级的定义是要结合当时的情境的。

需求分析过程从来不会少了和利益相关者的沟通，美国弗吉尼亚大学教授Edward Freeman把利益相关者定义为："那些能够影响企业目标实现，或者能够被企业实现目标的过程影响的任何个人和群体"。

（1）警惕“被动”利益相关者

大型项目通常都涉及非常多的利益相关者，我们比较容易识别那些能够影响企业目标实现的人，却容易忽略在实现目标过程中被动被影响到的个人或群体。

图片来源：网络

比如企业内部实施用自动化手段加速某个流程的效率，这种变更对企业来说是好事，但对此链条上老旧慢的个人或者群体，却不见得是好事。这类人或者群体管理不当的话可能会成为项目进展的阻力。

还有一个例子相信很多人也遇到过，那就是在端到端测试过程中，几十步上百步的测试用例，跑一大半失败了（测试人员的内心是崩溃的）。原因呢，是某个节点没有实施相应的变更，这也是在前期没有很好地识别出被影响的上下游系统导致的。

（2）立足事实、彰显尊重

不管对项目经理还是业务分析人员，接触到的形形色色的利益相关者中，总有一款或多款令人头疼的对象，该怎么处理呢？

我的经验是，不管我们面临的利益相关者是实现目标的积极推动者，还是被动影响者，基于事实和希望项目成功的共同目标做客观的沟通，沟通过程显示尊重，是建立良好合作关系的基础。

我曾经遇到过一位比较棘手的项目发起方，说话很不客气，习惯性打断、反驳别人，或发散讨论主题，这一度令人非常沮丧。但是，既然我们很难改变一个人的沟通方式，那就抛开情绪去聆听他的反驳和发散是基于什么样的思考。我把他天马行空的要求按类别整理出来，无效的标明理由，有效的创建用户故事，跟其它利益相关者一起讨论这些新用户故事的优先级。当讨论到某些故事的时候你能感受到他的惊讶，因为他那些灵光一现或随口说说的想法，都被记录、分析和管理了。对于被拒绝的要求，只要有理有据，他于是欣然接受。双方的合作自此以后顺畅许多，这是以项目成功为初心，基于客观事实沟通（而不是基于态度）、显示尊重（而不是降低姿态）的力量。

需求挖掘清楚之后，如何和开发团队协作设计解决方案呢？

（1）业务与技术并行

解决方案的输入，是被分析验证过的、完成优先级定义的需求，还有实施变更的策略等。需要注意的是，需求分析并非只是专业分析师的工作，其它的项目角色，像架构师或者开发带头人，也会介入到需求的筛选和验证过程——对于采用敏捷开发模型的团队来说尤其如此。

敏捷项目通常以2周为一个迭代周期，交付频率比传统瀑布模型大大增加。实践中，不少团队会遇到这种情况：下一个迭代要开始了，一方面，待办事项列表里没有足够多的用户故事供团队进行细化；另一方面，业务人员手里又有很多需要挖掘或者验证的需求。如果一定要业务分析师把所有需求整理清楚、需求规格说明书撰写到位，团队才参与进来，那相当于说，“来，请给我们在前面设立一个瓶颈！” 

一种推荐的做法是，业务人员在了解项目背景以及要解决的问题之后，边消化吸收整理文档，边与架构师、技术带头人等一起了解潜在的问题和挑战，探索如何规划功能以实现增量发布。业务和技术齐头并进挖掘需求，寻找可行解决方案，才能更高效地推进项目进入设计和开发阶段，这是历经验证、行之有效的方式。

在实际工作中，我们遇到过很多业务人员单枪匹马冲在与利益相关者沟通的第一线，即使他了解问题根源，在方案选型时依然畏手畏脚，因为不了解讨论的方案技术上是否可行；亦或是兴冲冲带着团队技术人员提供的解决方案前去沟通却被告知这个不是项目想要的方向。业务分析的重点在于建立“业务”与“解决方案”的关联，项目中即使有专职的业务分析人员，我们也不能视之为业务方和开发方之间的传声筒。业务与技术并行，挖掘客户痛点，系统思考，全盘分析，方能高效地设计可行的解决方案。

（2）解决方案的可扩展性

虽然产品发布上我们推行最小可行性产品，但是解决方案的设计不可拘泥于只满足MVP范围内的需求，要充分考虑其可扩展性。清晰了解产品的战略目标，甚至了解同类产品的竞争优势、劣势及战略，是设计可扩展的解决方案的有效方法。

怎么样衡量一个项目是成功的? 项目管理者时常从时间、成本和质量三个维度来考虑。我觉得还要增加两个维度：

• 体现业务价值

• 用户满意度

在某些情况下，比如用户需求分析出现偏差，或者产品战略方向制定失误，会导致项目即使按时、按预算、按定义范围交付，也没能带来期望的价值，这种项目你能说它是成功的吗？

业务价值可以是已经实现的、或者潜在的回报，也可以是通过降低组织风险或者成本而得到的价值。比如企业应对欧盟史上最严数据隐私法GDPR所做的变更，虽然不会为企业带来收益，但却能避免违规带来的巨额罚款。

本公众号上期文章赋能——通过组织转型打造高效研发团队（下）探讨了如何度量组织转型过程，虽然其专注于转型过程中的度量，但是大道至简，万物皆通，其中讨论的度量的目的及一些度量原则也同样适用于业务价值的度量。完成一个项目，从什么角度度量它的价值？选取什么样的度量指标？采取什么样的数据收集方法？这些是需要在需求定义阶段就要深思熟虑的问题。

我们身边有很多的案例，利益相关者想要统计项目价值却无从下手。为了避免这种尴尬的问题出现，推荐如下三步法：

1. 需求定义阶段和利益相关者讨论、制定价值的度量指标及度量方法。

2. 产品开发阶段植入代码以获取统计数据。有些度量指标不需要植入新的代码也能够获取，但是，是否需要植入新的代码，取决于项目团队有意识地进行了第一步的讨论。

3. 产品上线，搜集统计数据。

通过上面三步，我们得到可以用来衡量项目价值的数据了，接下来就是分析数据，观察它呈现出来的结果和项目期望之间的偏差。有专职运营团队的项目，产品的构建偏离期望的风险小一点，因为运营数据会及时传递实施的变更是否带来期望的价值。没有运营团队的，开发团队也要培养看运营数据的习惯，确定我们总是工作在能按照预期产生价值的项目上，工作在投入产出比高的需求上。

关注项目产生的价值，有助于提高个人的业务敏感度和自豪感。不管你是一名开发人员，还是测试人员，在总结KPI时，试着把我写了多少行代码，跑了多少测试用例，改成用户能用我开发、测试的模块完成什么目标，每天有多少人在使用这个模块，成就感是不是多了很多呢？

本文通过BABOK对业务分析的定义，引入业务分析领域的六个核心概念：需要、变更、情境、利益相关者、解决方案和价值。六个概念相互作用，彼此影响：

• 需要和变更是业务分析的基础，挖掘需求、定义MVP、快速迭代很关键

• 解决方案是实施变更的手段，业务分析师和技术带头人齐头并进参与需求定义和解决方案设计能有效加速项目的推进

• 关注变更结果，关注价值指标，确保项目能为利益相关者和组织产生期望的价值

文章对每一个概念进行了简单阐述，更多呈现的是作者对这些概念的理解及实践经验，感谢阅读，欢迎留言交流心得体会。

本文来自微信公众号“CIO Talk”（ID：CIO_China_Lab），作者 Carol Zhao，IBM全球软件和云服务销售系统资深业务分析师，知识积累崇尚深耕细作，不喜浅尝辄止。

管理圈经授权发布，如需转载请联系原作者。