在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，BA（业务分析师）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA 可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。
那么在这样的敏捷项目中，BA 如何能够适应这种交付模式，完成高质量的业务分析，协同团队为客户交付高价值的软件呢？
项目背景
ABC 公司是一家知名的国际性会计师事务所，业务规模庞大，分支机构遍布全球 170 多个国家。
ThoughtWorks 受邀对其“全球派遣服务 (International Assignment Service)”业务部门提供 IT 解决方案，以及软件系统的开发。该系统包括收集其客户的全球派遣雇员的报税数据，以及管理 ABC 公司税务咨询师对这些数据的进行审核、汇算和出具报告的业务流程；逐步替换其目前已远远不能满足业务和性能需求的遗留系统。
该系统主要有两类用户，一类是 ABC 公司客户方被派往不同国家工作的雇员（以下简称 Mary），这些雇员使用该系统填入报税需要的数据。另一类用户是 ABC 公司的税务咨询师（以下简称 Kim），负责审核、处理 Mary 提交的数据。
BA 在该项目中面临的主要挑战
- 该项目为分布式开发，ABC 公司的决策方在美国，而 ThoughtWorks 的开发团队在中国，沟通反馈周期有时较长。
- 由于 ABC 公司对用户体验的重视，需要频繁交付软件，以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期，增加了分析中出现缺陷的风险。
- 当开发过程中发现问题时，无法马上与客户取得沟通，开发进度可能会受到影响。
识别业务价值
业务分析的重要性在于首先做正确的事情。理解客户的业务，关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。
而我们面临的困难是，客户提出的需求，往往都是直接的软件功能，而不是需要解决的业务问题。如果 BA 只专注于针对客户需要的功能进行系统分析，就丧失了帮助客户优化解决方案以及改进业务流程的机会。
如何寻找业务价值？
以敏捷开发方法中的用户故事为例，找出客户要解决的业务问题的一个简单办法是，用以下方式概括每个用户故事的内容：
As…（角色），I want to…（完成什么样的功能）,So that…（解决什么问题，带来什么价值）
“So that…”说明了该故事的业务价值，即要解决的业务问题。准确的寻找业务价值将有利于我们设计出最适合的“I want to”，这很可能优于客户直接提出的功能要求。
需要注意的是，不要把解决方案或功能当成该用户故事的价值。以 ABC 公司业务系统中的一个用户故事为例，BA 对该需求业务价值的了解程度将直接影响到解决方案的优劣。
作为 (As…)
我想要
(I want to…)
以便
(So that…)
是否阐明了价值？
Mary
即时浏览我的行程统计数据
了解我在各个国家或地区停留的时间以及从事的活动
否
Mary
即时浏览我的行程统计数据
我可以迅速地检查我所输入的在各国家或地区停留时间及从事活动的数据是否正确（以保证我可以依照法律要求提交准确的报税数据）
是
在该用户故事的两种不同表述中，由于第一种表述只说明了需要的功能，没有说明业务价值，在功能设计时，我们可能会将“行程统计数据”的内容设计的过于详细而造成浪费，使用户不明白此功能的意图。而第二种表述的业务目标就非常明确，可以帮助我们更加容易地设计出适合的解决方案。
此外，BA 在了解客户的业务问题时，最好请客户提供一些真实案例 / 场景来证实其观点并加深自己的理解。
避免分析错误
在实际工作中，我们发现有以下两个方面的分析工作容易被 BA 忽略，而做出错误的决定。
- 客户要求实现某些现有业务流程或遗留系统的功能
例如，客户需求的功能，是当前遗留系统中已经使用多年、且未收到过任何抱怨的功能。所以客户和 BA 往往认为这个功能是合理的，忽略了深入的分析和思考。而这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。
在 ABC 公司的遗留系统中，用来收集报税数据的问卷内容是通过 excel 表来维护的，而 Mary 在前台也是通过下载 excel 问卷，填写完毕后再上传。
在新开发的系统中，问卷被改为在线方式，并辅助以其他必要功能提升 Mary 的用户体验和满意度。但由于客户方的员工都是财务背景出身，非常喜欢使用 excel 表，而之前用 excel 表维护问卷内容也被证明是非常有效的，所以客户坚持在新系统中延用这种方式。经过仔细的分析，我们发现在针对提高 Mary 用户体验的新功能上线后，使用 excel 表维护问卷内容将大大增加维护的工作量及错误率，而这与项目的相关目标背道而驰。ThoughtWorks 在列举了问题的细节后，说服客户采用了新的解决方案。
- 客户要求利用新的 IT 系统改变当前的业务流程
客户发现目前的业务流程有不合理的地方，希望在新的 IT 系统里直接改变这些流程。如果不经过仔细的分析，这种做法可能会很危险，业务流程的盲目改变可能会对一部分用户造成麻烦，为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要，从而可以帮助我们为客户提供科学的、逐步优化其流程的 IT 解决方案。
在 ABC 公司的业务流程中，Kim 和 Mary 之间的一些交流是通过邮件来完成的。这里存在两个业务风险：1）Kim 和 Mary 交流的重要信息被散落在各自的邮件里，系统无法记录，在遇到法律问题时，难以划分责任；2）Kim 和 Mary 可能会使用邮件发送一些保密性较强的内容，如果发错，后果不堪设想。
在开发新系统时，客户要求我们增加了一个消息功能，使 Kim 和 Mary 之间的交流可以方便地在系统内部完成。该功能上线后，很好地化解了这两个业务风险，同时收到了 Mary 这类用户的良好反馈。然而这对该会计师事务所在某些国家分支机构里的 Kim 这类用户的工作却带来了不小的影响。由于之前使用邮件系统，Kim 可以将 Mary 的邮件转发给相关的同事，并利用邮件丰富的功能进行结果的跟踪。而新上线的消息功能达不到邮件的所有要求，所以增加了他们的工作难度。此外，由于 Mary 对这个功能的青睐，发送消息的数量远远超过了在使用遗留系统时发送邮件的数量，超过了客户想提高 Mary 的满意度而在短期内所能承受的代价。
在遇到以上问题时，我们与客户一同分析，提出了折中的解决方案，花费了较少的代价将消息系统和客户的邮件进行集成，同时帮助客户制定了对此项业务流程改进和配套 IT 解决方案的蓝图。
理清需求优先级
在频繁上线的项目中，其中一个重要的实践是确定需求的优先级，使得重要的功能能够先被开发出来投入使用以便及时收集用户反馈。一般的做法是要求客户排好需求优先级，然后与项目相关成员一同制订迭代开发和上线计划。但由于客户决策方所处角色以及思维角度的局限性，对优先级的评定可能存在盲目。建议 BA 参照以下价值维度帮助客户对优先级进行评定。
从客户价值维度分析需求优先级
需求价值维度分析图
价值维度
说明
愿景目标
该功能点是否契合项目的愿景和业务目标？
与项目目标的契合程度越高者优先级越高
时间限制
客户的业务是否有一定的时间表？
如果该功能点必须在某时间点前投入使用，则该需求必须被排入相应时间的发布计划中
市场卖点
该功能点是否是吸引特定目标用户的卖点？
如果客户的资金存在问题或者需要市场的快速认可，则可以考虑将该需求列为高优先级
有无替代方案
该功能点有无方便的替代方案？
如果有简单易行的替代方案，则该需求的优先级较低
客户内部政治因素
该功能点是否存在客户内部的政治因素？
例如某功能只对小部分用户提供价值，但会决定客户内部某个重要组织对这个项目的投资和评价，则可以考虑将该需求列为高优先级
投资收益
该功能点的开发成本和客户所能获得的收益是否匹配？
例如客户某工作流程浪费了一个小组人员大量时间，但对其他部门或工作环节无影响。如果开发相应的软件功能造成的投入大于客户在一定时期内可以节省的资金，则该需求的优先级较低
技术依赖性
其他需求是否依赖于该功能点？
如果依赖于这个功能点的需求优先级高，那么该功能的优先级应更高
技术风险对优先级的影响
除了来自客户方面的决定因素，我们还应考虑技术实现方面的影响。如果一些技术风险较高的功能可以先进入开发阶段，则问题会尽早地被暴露。开发人员在项目早期解决这些问题会有利于开发成本的节约。所以除以上客户价值维度外，应再参考以下矩阵来权衡需求的优先级。
需求优先级矩阵
客户价值维度和需求优先级矩阵并不是优先级高低的计算器，而是与客户以及团队沟通交流的工具。不同项目的影响维度也会有所不同。由于各项因素的复杂性，客户价值维度和技术风险因素需综合考虑，不可以权重来计算。BA 可以与客户对以上因素的内容达成一致，使得客户在评定需求优先级时可以快速、准确地做出判断。同时，通过对价值维度的分析，我们将有机会清晰地了解到功能优先级高或低的原因，以便我们能够准确地编制项目开发和上线计划，并合理地划分用户故事范围。
借助价值维度分析，管理客户期望值
有些客户的决策人可能会依据自己的喜好划分优先级，这对于项目能够按目标成功交付造成一定的风险。此外，客户在功能的设计和验收阶段也容易对单个功能追求完美，造成额外工作量，增加项目范围。而这部分额外工作可能并不合理或者价值较低。长期如此，团队在开发过程中将逐渐偏离项目目标。如果能借助优先级维度对这些额外需求进行分析，则可以提供更有说服力的依据，帮助客户做出正确决定，达成 BA 和项目经理对客户期望值的有效管理，从而降低交付风险。
发挥团队其他成员在业务分析中的作用
在频繁交付的项目中，如果 BA 独自承担业务分析工作，难免会出现疏漏。ThoughtWorks 曾与 ABC 公司的 IT 部门合作完成其业务系统的一些集成工作。在合作过程中发现，ABC 公司 IT 部门的开发人员在业务分析中参与度很低，由此造成了如下问题：
- BA 需要写大量需求文档，故从需求分析到软件交付的周期较长
- 设计缺陷的发现滞后
- 在需要频繁交付的情况下，解决方案质量较差，方案优化能力较弱
而 ThoughtWorks 的开发人员由于在业务分析中的参与度较高，则有效地避免了以上问题。
开发人员如何参与分析
开发人员是软件功能的实现人员，对方案的实现工作量有较准确的估计。在明确项目目标或业务问题后，BA 如果能够和开发人员一同分析解决方案，将更有效地为客户找到兼顾成本和效果的方案。
在收集到客户需求后，BA 可根据业务价值对需求进行分析，判断客户提出的功能或解决方案是否能很好地满足该业务价值或要解决的业务问题；或者按照自己的理解设计出满足该业务价值的功能或解决方案。
完成上述工作之后，BA 应与开发人员就需求和业务价值进行充分沟通，验证功能实现的可行性，同时积极探寻更优方法。如果开发人员提出符合业务价值的不同方案，BA 则可以要求开发人员提供一些关于开发工作量、方案优劣、技术风险方面的比较数据，从而帮助自己有效地与客户沟通并挑选最佳方案。甚至可以根据分析结果帮助客户调整该需求的优先级。对于技术难度和风险较高的功能点，建议邀请资深开发人员参与讨论。
与开发人员沟通中遇到的挑战与解决方法
由于上述方法需要与开发人员大量沟通，有些 BA 在应用以上实践时也遇到了以下挑战。
- 开发人员缺少参与业务分析的热情
在 ThoughtWorks，大多数开发人员都喜欢积极思考、主动为业务分析提供帮助，大大减少了需求分析上的漏洞。然而在 ABC 公司的 IT 部门中，开发人员很少主动为业务分析出谋划策，尤其是团队中资历较浅的成员，甚至不愿意参与解决方案的讨论。团队成员的优势没有得到充分发挥，开发人员只管按需求埋头苦干，结果功能和解决方案的问题往往在测试或者验收阶段才暴露出来，不可避免地造成了浪费。
站在开发人员成长的角度，从 ThoughtWorks 实践来看，积极地理解业务、思考解决方案能够更快地提高技术能力。故此 BA 可以找出一些实际案例，协同项目经理与团队各成员进行沟通，鼓励大家积极参与业务分析，逐步形成开发人员与 BA 协作的良好氛围。
- 开发人员容易就客户需求或解决方案产生争论
开发人员在积极参于分析的过程中，有时会对软件功能的价值吹毛求疵，在细节上与 BA 产生较多争论，使 BA 在应付开发人员的问题以及与客户求证答案之间疲于奔命。
解决此类问题，可采取以下方法：
- BA 在收集需求时，尽可能充分地了解客户要解决的业务问题，以便能够快速回答开发人员的问题
- 面对开发人员对解决方案的质疑时，应保持良好的心态，清楚地了解开发人员顾虑的问题和原因
- 如果自己掌握的信息确实不能证明现行方案的合理性时，协同开发人员，找到更优方案并与现行方案进行优缺点比较
- 将新旧方案与客户沟通，则可快速帮助客户做出判断
不要忽略测试人员在业务分析中的贡献
由于测试人员所处角度和对细节的关注，往往可以发现一些功能细节的设计漏洞。所以在用户故事进入开发前，BA 与质量保证人员对相关业务价值进行充分沟通，会在功能进入开发之前为 BA 创造更正设计缺陷的机会。
做为质量保证人员，如果充分了解功能背后的业务价值，相对于只了解功能需求，将可以写出更加完善的测试用例，提高测试覆盖率。这会为交付高质量的软件把好最后一道关。
结语
业务分析是困难的，特别是我们面对未知领域的时候。如果只是简单地按照客户的具体需求进行软件开发，那么我们交付给客户的价值将非常有限。然而识别业务价值、帮助客户分析需求优先级、保障团队协作，将有效提升团队对软件的设计能力，解决客户真正的业务问题，交付更大价值。
作为一名业务分析人员，当您在尝试以上实践时，可能会发现自己对客户业务的理解变得更加深刻。在与客户的沟通中，也能够更加容易地提出有价值的问题以及建议，从而提升客户对项目团队的信任，为成功交付项目打下良好基础。
* 注：“客户价值维度”的概念由 ThoughtWorks 咨询师李光磊提出。在此对李光磊表示感谢。
感谢张凯峰对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论