2.3 识别业务价值
业务分析的重要性在于首先做正确的事情。理解客户的业务，关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。
而我们面临的困难是，客户提出的需求往往都是直接的软件功能，而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析，就丧失了帮助客户优化解决方案以及改进业务流程的机会。
如何寻找业务价值？
以敏捷开发方法中的用户故事为例，找出客户要解决的业务问题的一个简单办法是，用以下方式概括每个用户故事的内容。
As…（角色），I want to…（完成什么样的功能），So that…（解决什么问题，带来什么价值）。
“So that…”说明了该故事的业务价值，即要解决的业务问题。准确地寻找业务价值将有利于我们设计出最适合的“I want to”，这很可能优于客户直接提出的功能要求。
需要注意的是，不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例，BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。
在该用户故事的两种不同表述中，由于第一种表述只说明了需要的功能，没有说明业务价值，在功能设计时，我们可能会将“行程统计数据”的内容设计得过于详细而造成浪费，使用户不明白此功能的意图；而第二种表述的业务目标就非常明确，可以帮助我们更加容易地设计出适合的解决方案。
此外，BA在了解客户的业务问题时，最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。
避免分析错误
在实际工作中，我们发现BA容易忽略以下两个方面的分析工作，从而做出错误的 决定。
1．客户要求实现某些现有业务流程或遗留系统的功能
例如，客户需求的功能，是当前遗留系统中已经使用多年并且未收到过任何抱怨的功能。因此客户和BA往往认为这个功能是合理的，忽略了深入的分析和思考。但是这种思考不全面而做出的决定可能会与可以预见的新功能产生冲突。
在ABC公司的遗留系统中，用来收集报税数据的问卷内容是通过Excel表来维护的，而Mary在前台也是通过下载Excel问卷，填写完毕后再上传。
在新开发的系统中，问卷被改为在线方式，同时辅助以其他必要功能提升Mary的用户体验和满意度。因为客户方的员工都是财务背景出身，非常喜欢使用Excel表，而之前用Excel表维护问卷内容也被证明是非常有效的，所以客户坚持在新系统中延用这种方式。经过仔细地分析，我们发现在针对提高Mary用户体验的新功能上线后，使用Excel表维护问卷内容将大大增加维护的工作量并且提高错误率，而这与项目的相关目标背道而驰。ThoughtWorks在列举了问题的细节后，说服客户采用了新的解决方案。
2．客户要求利用新的IT系统改变当前的业务流程
客户发现目前的业务流程有不合理的地方，希望在新的IT系统里直接改变这些流程。如果不经过仔细的分析，这种做法可能会很危险，业务流程的盲目改变可能会给一部分用户造成麻烦，为客户实施该软件形成强大阻力。那么了解清楚目前这些流程存在的价值和原因事关重要，从而可以帮助我们为客户提供科学的、逐步优化其流程的IT解决方案。
在ABC公司的业务流程中，Kim和Mary之间的一些交流是通过邮件来完成的。这里存在两个业务风险：第一，Kim和Mary交流的重要信息被散落在各自的邮件里，系统无法记录，在遇到法律问题时，难以划分责任；第二，Kim和Mary可能会使用邮件发送一些保密性较强的内容，如果发错，后果不堪设想。
在开发新系统时，客户要求我们增加了一个消息功能，使Kim和Mary之间的交流可以方便地在系统内部完成。该功能上线后，很好地化解了这两个业务风险，同时收到了Mary这类用户的良好反馈。然而这却给该会计师事务所在某些国家分支机构里的Kim这类用户的工作带来了不小的影响。由于之前使用邮件系统，Kim可以将Mary的邮件转发给相关的同事并利用邮件丰富的功能进行结果的跟踪；而新上线的消息功能达不到邮件的所有要求，所以增加了他们的工作难度。此外，由于Mary对这个功能的青睐，发送消息的数量远远超过了在使用遗留系统时发送邮件的数量，超出了客户想提高Mary的满意度而在短期内所能承受的代价。
在遇到以上问题时，我们与客户一同分析，提出了折中的解决方案，付出了较少的代价将消息系统和客户的邮件进行集成，同时帮助客户制定了对此项业务流程改进和配套IT解决方案的蓝图。