【译说】作者 Karl Wiegers 在数十种可用的商业分析实践和方法中,发现这六种特别有价值,而且使用起来也很有趣。本文约 3500 字,阅读全文大约需要 9 分钟。

就像技艺精湛的木工一样,经验丰富的商业分析师 (BA) 会积累丰富的实践经验、技巧和工具,并懂得何时该用哪种工具。诸如 IIBA 的《商业分析知识体系指南》、James Cadle 等人合著的《商业分析技巧:123 个成功必备工具》以及我与 Joy Beatty 合著的《软件需求》(第三版)等书籍,都介绍了数十种此类工具。
本文将介绍六种我认为在很多情况下都特别有价值的 BA 技巧。这些技巧也很容易向其他利益相关者解释,有助于让他们更积极地参与到商业分析过程中。
根本原因分析
客户最初向商业分析师提出的问题可能并非真正的问题所在,而只是一个表象。或者说,利益相关者提出的可能并非问题,而是他们期望的解决方案。商业分析师必须评估解决方案是否有效,以及是否真正解决了问题。在着手构思解决方案之前,先进行根本原因分析,以了解问题的本质。
根本原因分析是一个逆向思考的过程,需要反复追问“为什么”,直到找到可以着手解决的根本问题。当商业分析师与管理层合作,探讨如何解决业务问题或取得卓越成果时,这种方法尤为重要。最初提出的原因可能并不直接可行,甚至可能并非最终的根本原因。因此,仅仅解决它并不能解决问题。你需要继续追问“为什么”,才能深入分析问题的根源。
我们可以使用鱼骨图来展示根本原因分析,如图 1 所示。假设问题的症结在于公司产品在初始版本发布时未能满足客户需求。首先,在一条水平线上写下问题陈述:

图1 -以鱼骨图形式展示的部分根本原因分析
现在,需要召集一组相关的利益相关者进行回顾性思考。询问:“为什么我们无法满足客户需求?” 也许有人会说团队没有从最终用户那里获得足够的需求反馈。将此原因写在从目标陈述线延伸出的对角线上。这只是一个开始,你需要更深入地了解。你可以问:“为什么无法满足客户需求?”
另一个人会说:“我们尝试与真实用户沟通,但他们的经理说他们太忙,没时间与软件团队合作。” 还有人抱怨说,代理客户代表没有很好地表达实际用户的需求。将这些二级原因写在从父问题对角线延伸出的水平线上。
继续进行这种分层分析,逐一找出最初的原因,直到所有参与者都认同他们理解了当前目标无法达成的原因、真正的症结所在以及可操作的根本原因。现在,我们可以充满信心地开始构思解决方案,确信自己正朝着正确的方向前进。
业务目标模型
团队理解问题之后,下一步是描述关键利益相关者期望解决方案达成的目标:即他们的业务目标。这些目标应明确预期的业务成果,并确定衡量指标,以判断目标何时达成。业务目标为后续所有工作提供指导方向,并使所有利益相关者齐心协力,共同打造有效的解决方案。
定义业务目标可以帮助我们确定何时解决了问题、满足了需求或抓住了机会。它们驱动着解决方案概念的创建,进而引导需求收集活动,以定义解决方案的具体功能、特性、范围和优先级。
业务目标模型以可视化的方式将业务问题与业务目标、相关的成功指标以及最终的解决方案概念联系起来。图 2 展示了一个餐厅在线订餐系统的部分业务目标模型,该系统旨在补充餐厅目前通过电话接单的方式。

图 2 - 业务目标模型将业务问题、目标、成功指标和解决方案联系起来
当业务问题和目标相互交织时,建模尤为重要。
问题引出目标,目标引出更详细的问题,更详细的问题又引出另一个目标,以此类推。如果没有这种分析,就无法确保提出的解决方案能够达到预期效果。
产品倡导者模型
产品开发项目涉及众多利益相关者。有些利益相关者是客户,有些客户是用户。大多数产品都有多个用户群体,他们的需求差异很大。指望任何一个人能够理解所有这些用户群体的需求并恰当地平衡他们的利益是不现实的。
产品倡导者方法是一种有效的技巧,可以调动具有代表性的客户,确保开发团队能够满足他们多样化的需求和限制。产品倡导者是特定用户群体的关键用户代表。在这个模型中,需求信息的流动涉及一个或多个产品倡导者,与一个或多个商业分析师 (BA) 的协作:

图 3 - 产品倡导者是特定用户群体的关键代表
首先,为每个主要用户群体寻找一位产品倡导者。有些人可能属于多个用户群体,并能够代表所有这些群体的需求。在其他情况下,一个庞大的用户群体可能需要细分为多个子群体,每个子群体都必须在需求讨论中得到代表。
产品倡导者代表其用户群体的需求和限制。他们与 BA 合作,确定优先级并解决来自多个用户群体的需求之间的冲突。他们还可以参与开发和执行反映真实使用场景的测试。这是我本人强烈推荐的一个模式。
用例模型
一旦确定了一些关键用户,就需要向他们收集需求。收集需求可以侧重于产品功能或预期产品的使用情况。我强烈推荐后者。“用例”是了解用户将如何使用产品以及他们设想如何与产品交互的绝佳方法。我认为用例是 BA 的得力助手。
用户每次与产品交互时,心中都有一个意图,即他们想要完成的事情:一个目标或一项任务。这些意图和任务都构成一个用例。当需求收集参与者说“我想[做某事]”时,这个[做某事]很可能就是一个用例。这张来自我信用卡发卡银行网站的截图,展示了几个常见的信用卡用例:

一个用例包含三个主要组成部分:
对正常或最常用步骤序列的描述:基本流程
基本流程的变体,称为替代流程
可能阻止用户实现目标的例外情况
通过将收集需求的重点放在用户需要如何使用解决方案上,商业分析师可以推导出解决方案所需的功能。识别替代流程和例外流程有助于商业分析师和产品负责人确定功能的优先级,从而为迭代和发布计划提供依据。用例也自然而然地引出了创建测试用例这一步骤。
这种以用户为中心的视角降低了遗漏必要功能的可能性。这也有助于团队避免浪费时间实现那些因无法帮助用户完成已知任务而最终无人使用的功能。如果我是一名刚开始积累实用技能的新手商业分析师,用例将是我首先要添加的内容。
对话图模型
我非常喜欢分析建模,即绘制图表来直观地表示软件系统及其需求。商业分析师可以选择多种模型来描述问题或解决方案的各个方面,包括流程、数据和状态。我最喜欢的模型是对话图,它能够高效地表示、验证和改进用户在用户界面中的导航方式。
对话图使用了状态转换图的简单概念和符号。图 4 展示了一个用于管理公司研究实验室化学品库存的跟踪系统的部分对话图。它展示了用户在创建订购新化学品的请求时可能遵循的各种路径。矩形框表示对话框元素,例如菜单、屏幕、页面和对话框——用户可以与系统交互的任何位置。箭头表示这些对话框元素之间可能的导航路径,以及触发每次导航的操作。

图 4 - 对话图展示了用户与产品交互过程中可能的导航路径
对话图描绘的是用户界面的架构,而非显示细节。对话图可以揭示许多问题,例如:
导航死胡同,用户不确定下一步该做什么;
需要过多显示或用户操作的活动,或许可以简化;
用户开始操作后无法撤销;
功能缺失,例如执行风险操作前需要确认;
错误处理不合理或根本没有处理;
重复元素,揭示了重用对话元素的机会。
在用户体验专家进行详细的屏幕设计之前,对话图有助于项目参与者对系统的预期行为达成共识,并设计出更佳的用户体验。
决策表模型
许多系统涉及多变量决策,其中多个因素的特定值组合决定了产品的行为。业务规则是此类复杂逻辑的常见来源。在分析需求时,很容易忽略某些组合,或者忽略多个组合会导致相同结果这一事实。决策表是一种有效的工具,可以简洁地组织这些信息和结果。
决策表列出了所有因素的可能值,并指出系统针对每种组合的预期操作。这些因素可以表示为真或假的陈述句,是或否的问题,或者可以有两个或多个可能值的条件。
让我们回到之前提到的化学品追踪系统。系统是否应该接受特定用户提出的新化学品请求取决于四个因素:
请求者是否拥有请求化学品的权限
公司仓库或供应商处是否有该化学品
该化学品是否在需要安全操作培训的危险化学品清单上
请求者是否接受过此类危险化学品的操作培训
如果尝试用自然语言将这四个因素的所有逻辑组合都写成功能需求,很快就会变得冗长而复杂。很容易遗漏某些组合,或者包含一些逻辑上不合理的组合。
图 5 以决策表的形式展示了这些逻辑组合。该表清晰地表明了系统应该接受还是拒绝每个请求。理论上,这四个二元(是/否)条件可以导致十六种可能的结果,但只有五种是可操作的。像这样的决策表有助于开发人员、测试人员、用户和其他利益相关者高效地记录、分析和交流复杂的知识。

图 5 - 化学品追踪系统的示例决策表
选择工具,任何工具
以上就是我最喜欢的商业分析和需求探索技巧。当然,商业分析师应该熟练掌握的工具还有很多。不过,如果我要去客户现场,我一定会确保公文包里装着这六种工具。
点击阅读原文,可以查看原版英文文章。转载注明出处。
往期好文直达>>>
增长理论
AARRR | PMF理论 |A/B测试 | PMF原则 |推荐营销 | 高级产品经理思考逻辑 | 产品框架大全 | 增长战略框架 |反增长黑客的长期主义
海外增长案例
Tinder | Linkedin | Clubhouse| Slack | Hoka | Duolingo | Cal AI|Netflix |A24|Medium|小商品案例合集|Kahoot!|Uber
实操方法
市场细分 | 品效最佳比例 | 增长设计 | 价值主张 | Z时代营销 | AB测试 | 2025Youtube收入 | PM思维训练 |B2B颠覆性增长框架|表情包营销|氛围营销|早期产品验证框架|30天营销启动|创业试运营|3-Touch口碑营销|产品发布时间计算公式|AI时代的内容突围|玩转Substack|用好ChatGPT|从大富翁学游戏化产品|Reddit|纳米达人
SaaS
7阶段增长法 | 5条黄金规则 | SaaS增长1-10 |SaaS产品验证



