业务分析处在开发过程的上游，提高业务分析的质量，可以减少后续开发、测试和集成过程中的反复确认，场景遗漏。采用可视化的业务分析工具箱可以大幅度避免文字版的业务需求描述所带来的不够完整，有误解等问题。CODING 特邀敏捷顾问、“业务分析工具箱”创始人王洪亮老师将在本次 《可视化业务分析》 课程中，带领大家掌握可视化业务分析的基本工具和方法，以提高业务分析的质量和效率。
今天我为大家介绍可视化业务分析。提到业务分析，是指以文字为主的业务描述文档 SRS，即软件需求规格说明书。在线下培训时，我会让学员做个小互动来直观感受详细的业务分析的重要性：首先让学员分组，每组选一位代表来观看展示在屏幕上的图形，把看到的内容记下来并以口头表达的方式传达给组员，组员在 A4 纸上来复现。
因为涉及到很多精确的元素位置，以口头的方式并不能正确复现。比如组员描述：“这个焦点叫圆心，正方形的边长是圆形半径的一半。”组员在复现尺寸时则会产生较大的偏差。可想而知，当我们用口头或者文字的形式，去表达很复杂的需求时，我们的开发团队、测试团队会在理解上产生偏差，从而在复现上产生错误。如果让组员把图形拍照之后交给团队去复现，则复现错误的可能性会大大降低。同样道理，我们在表达业务需求时，能够表达的信息带宽越宽、表达的信息越充分，我们传递的信息就越准确，组员理解越透彻，产品做出来就越精准。
举个例子，从 ATM 机上取钱的形式叫 IPO（Input Process Output），分别是输入参数、处理过程和输出参数。账户如果扣减失败，需要提前把扣减的账户余额退回账户，但如果只在这个条件下进行了描述，其他条件下没有标注，就有可能产生遗漏且难以被识别。而当我们发现了需要补充相关的信息时，就会引起格式上的调整。
如果我们采用如下格式来书写 SRS ，想要准确的表达给开发团队就要在文档上花很多功夫。由于全是文字，如果复制时产生了覆盖就会造成信息的丢失，因此采用纯文本方式描述业务需求会产生问题：一是难以阅读；第二是会产生一些错误并且不容易被发现；最后是修改时会产生格式调整，引起不必要的新错误。
同样的业务需求，我们可以换一种表达方式——泳道形流程图。图上矩形、菱形分别表示处理和条件，加上用户、ATM 和账户三个泳道，让每个处理者能清晰了解是谁在负责；当发生变更时，就能明显呈现出哪里发生了变更。采用可视化的方式表达业务需求，可以更好地呈现所有信息。
语言表达会增加误解的可能性，更何况语气无法在文字中表达，所以当开发人员和测试人员产生理解偏差，他们就会争论到底谁是正确的。当没法判断时，就到上游来询问 BA，如果 BA 也没法判断就会继续向上询问，为了避免浪费时间，在 BA 向开发和测试团队传达需求时，就应该清晰地传达，确保需求的正确性和可读性。如果 BA 最开始对需求描述就是错误的，而且通过文字表述的方式向客户确认，客户也没有发现错了，就会导致开发和测试白干；如果在测试时才发现场景或条件有遗漏，就会导致产品质量下降、项目延期，如果在初期能够发现遗漏，这些隐患就可以及早消除，不至于产生反复、推迟的问题；还可能遇到因为多个 BA 处理自己负责的部分，根据自己的理解去需求，导致最终结果不一致，开发无法进行的情况，这可以通过互查工具来避免。
当业务需求分析人员遇到了需求分析，简略写过后让开发人员自行发挥，就有可能与原始需求不一致，之后发现问题进行返工就会导致开发时间过度消耗。为了避免出现这样的情况，在最初就要将需求细化到一定程度，让开发人员能够按照明确需求做出正确版本。
需求没有优先级会导致用户发现产品的各种问题，这种情况可以通过迭代的方式解决，每个迭代交付一次，按照价值的优先级进行排序，用户可以更短周期地给出反馈，开发就可以做出更正确的产品；如果总是需求变更，当发生变更时，BA 机械地从上游把变更情况传递给开发人员，会产生 BA 没有责任，都是开发人员背锅的情况，那二者之间可能产生矛盾，打击士气。其实需求变更就是 VUCA 时代，谁能更好地响应变更，就具有更强的竞争力，这对整个团队来说都是非常好的事情。