业务分析处在开发过程的上游，提高业务分析的质量，可以减少后续开发、测试和集成过程中的反复确认，场景遗漏。采用可视化的业务分析工具箱可以大幅度避免文字版的业务需求描述所带来的不够完整，有误解等问题。CODING 特邀敏捷顾问、“业务分析工具箱”创始人王洪亮老师将在本次 《可视化业务分析》 课程中，带领大家掌握可视化业务分析的基本工具和方法，以提高业务分析的质量和效率。
今天我为大家介绍可视化业务分析。提到业务分析，是指以文字为主的业务描述文档 SRS，即软件需求规格说明书。在线下培训时，我会让学员做个小互动来直观感受详细的业务分析的重要性：首先让学员分组，每组选一位代表来观看展示在屏幕上的图形，把看到的内容记下来并以口头表达的方式传达给组员，组员在 A4 纸上来复现。
因为涉及到很多精确的元素位置，以口头的方式并不能正确复现。比如组员描述：“这个焦点叫圆心，正方形的边长是圆形半径的一半。”组员在复现尺寸时则会产生较大的偏差。可想而知，当我们用口头或者文字的形式，去表达很复杂的需求时，我们的开发团队、测试团队会在理解上产生偏差，从而在复现上产生错误。如果让组员把图形拍照之后交给团队去复现，则复现错误的可能性会大大降低。同样道理，我们在表达业务需求时，能够表达的信息带宽越宽、表达的信息越充分，我们传递的信息就越准确，组员理解越透彻，产品做出来就越精准。
举个例子，从 ATM 机上取钱的形式叫 IPO （ Input Process Output ），分别是输入参数、处理过程和输出参数。账户如果扣减失败，需要提前把扣减的账户余额退回账户，但如果只在这个条件下进行了描述，其他条件下没有标注，就有可能产生遗漏且难以被识别。而当我们发现了需要补充相关的信息时，就会引起格式上的调整。
如果我们采用如下格式来书写 SRS，想要准确的表达给开发团队就要在文档上花很多功夫。由于全是文字，如果复制时产生了覆盖就会造成信息的丢失，因此采用纯文本方式描述业务需求会产生问题：一是难以阅读；第二是会产生一些错误并且不容易被发现；最后是修改时会产生格式调整，引起不必要的新错误。
同样的业务需求，我们可以换一种表达方式——泳道形流程图。图上矩形、菱形分别表示处理和条件，加上用户、ATM 和账户三个泳道，让每个处理者能清晰了解是谁在负责；当发生变更时，就能明显呈现出哪里发生了变更。采用可视化的方式表达业务需求，可以更好地呈现所有信息。
语言表达会增加误解的可能性，更何况语气无法在文字中表达，所以当开发人员和测试人员产生理解偏差，他们就会争论到底谁是正确的。当没法判断时，就到上游来询问 BA，如果 BA 也没法判断就会继续向上询问，为了避免浪费时间，在 BA 向开发和测试团队传达需求时，就应该清晰地传达，确保需求的正确性和可读性。如果 BA 最开始对需求描述就是错误的，而且通过文字表述的方式向客户确认，客户也没有发现错了，就会导致开发和测试白干；如果在测试时才发现场景或条件有遗漏，就会导致产品质量下降、项目延期，如果在初期能够发现遗漏，这些隐患就可以及早消除，不至于产生反复、推迟的问题；还可能遇到因为多个 BA 处理自己负责的部分，根据自己的理解去需求，导致最终结果不一致，开发无法进行的情况，这可以通过互查工具来避免。
当业务需求分析人员遇到了需求分析，简略写过后让开发人员自行发挥，就有可能与原始需求不一致，之后发现问题进行返工就会导致开发时间过度消耗。为了避免出现这样的情况，在最初就要将需求细化到一定程度，让开发人员能够按照明确需求做出正确版本。
需求没有优先级会导致用户发现产品的各种问题，这种情况可以通过迭代的方式解决，每个迭代交付一次，按照价值的优先级进行排序，用户可以更短周期地给出反馈，开发就可以做出更正确的产品；如果总是需求变更，当发生变更时，BA 机械地从上游把变更情况传递给开发人员，会产生 BA 没有责任，都是开发人员背锅的情况，那二者之间可能产生矛盾，打击士气。其实需求变更就是 VUCA 时代，谁能更好地响应变更，就具有更强的竞争力，这对整个团队来说都是非常好的事情。
例如判定矩阵，我遇到过一帮业务专家研究什么情况下叫故障，我问判断设备是否故障有多少因素？专家说共四个因素，那么每个因素有两个选项，列成表格形式，一共是 16 种组合。这个问题就迎刃而解，整个项目可以快速往下推动。软件开发团队使用正确的工具，可以起到非常大的改进作用，甚至缩短交付周期进而提高整体代码质量。在整个软件开发的过程中，BA 的角色叫业务分析师，他的定位是在领域专家和技术专家之间搭建起一个桥梁，将领域专家提出的领域需求翻译成一个技术需求，让技术专家能够实现正确的过程。BA 拿出一份需求文档，两方都有相同的理解，这才是一个优秀的 BA 应该做的事情。
以 Scrum 环境为例，在 Scrum 中团队没有进行细化，所以 BA 也是团队的一部分。在团队里 PO 跟最终用户进行沟通，将收集到的最初业务需求分解成用户故事，进行价值排序并设定产品计划、产品战略等等，那么 BA 就应该是把最初拿到的以用户故事为单位的需求，转换翻译成开发团队能够看懂，并且能够正确实施的需求过程，因此 BA 是介于这二者之间的一个沟通桥梁。需求处在开发过程的最上游，那么需求分析的质量改善就会对下游产生一个杠杆作用，因此 BA 不要去做低价值的事情，而是需要让团队价值得到更好地体现。
需求变更是常态，如果能够提前去想到应对变化的措施，那就真正掌握了如何提高灵活性。 变化不仅体现在代码上，在需求层面也需要响应变化，才能够真正推进整个软件工程。需求文档写出来开发团队要看、测试团队要看，在 Scrum 中 Scrum Master 、PO 、UI 、最终用户、干系人都要看，但每个人所处的立场不一样，希望看到信息也是不同的，如果把文档以合适的形式来组织，让每个角色都能快速理解并且保证高质量，那么整个软件开发过程都能得到很大程度的提升。
例如虚拟一个巴士租赁项目：国内旅行社要租赁国外的巴士安排旅客行程，接到订单就将乘客安排上巴士，行程结束司机结算相应费用。用如下流程图的方式将巴士租赁的主要业务逻辑画出来，可以发现在某些情况下并没有说明判断基准。遇到一个业务需求时，可能会有各种各样的条件来判断这些步骤是否可以往下推动，把这些条件全部列出时整个流程图会变大、没有分层导致难以阅读和维护，而且非常难以变更，如果想实现不论条件如何判断这张图都不发生改变，那么就需要通过解耦合的方式让文档产生一份固定和一份可变动的。
可以从下图看出判定矩阵的构成形式，前面是条件，每一个条件的选项按照 Excel 的形式列出，用这种方式列出所有的四种组合，动作全是派车，那么最后的结论就很清晰。用这种方式可以确保条件覆盖率达到 100%。如果有遗漏那是因为所采用的工具没法达到 100% 覆盖率，比如纯文字描述。如果是一个更庞大的表格，达到上百甚至上千行时，也可能产生人为的遗漏，因此需要采用更科学的工具进行自我校验。
下图表格的构成形式，前面是条件、中间是操作、后面是预期，这种 Give When Then 的形式就是测试用例，测试人员拿到表格，可以直接作为测试用例使用。这个判定矩阵不仅能提供 100% 的覆盖率，还能够引导程序员开发出正确的代码，达到一个好的效果。
状态之间是通过具体的操作进行切换的，例如状态 4 无法切换到状态 1，用这种方式把前面流程相应的状态全部梳理出来，就可以进行下一步的分析。举两个例子：一是贷款审批，实际上内部有三个步骤，第一步核实用户的真实身份，第二步核实用户的征信状况，第三步核实银行卡与用户信息的一致性。内部在处理数据时有子状态，但是对外都显示“贷款审批”，所以会分为内部状态和外部状态。另一种叫主状态和子状态，比如说出国手续的步骤可以分为机票——酒店——签证，每一个子过程都有自己的状态，并且三者是并行，全部状态完成之后整个过程才算完结。
如图所示，在当前状态下能否进行左边的操作，如果能就打勾，这就是所谓的决策矩阵。如果列出一个 M×N 的矩阵，那么该矩阵一定是覆盖所有的场景，列出了所有的状态操作。实际上在画流程图时只提供画对勾的操作，不会表达出空白格所代表的信息，所以决策矩阵可以用来了解列出的异常信息。
善用工具可以更好地呈现业务需求，让开发人员的理解更深刻。例如纲举目张：在需求中每一个未确认点就是渔网的一个孔，把网子撑起来才能够看到有多少孔没有填充，利用数学或者客观规律来找到这些潜在的点，然后逐个确认，才能够达到提升质量、提高效率的目的。如果遵循这些原则，可以发展出新的工具，也能够更好适应不同的业务场景。
一图胜千言，以上的所有案例都在讲如何用可视化的方式去展示相应的业务需求，例如图示、图片、图表、表格、流程图等等。业务需求分析一定要完整，要保证以下几个方面：
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.