2.2 需要和解决方案
在前言中，对分析涉及的活动进行了介绍：
- 理解利益相关者；
- 理解情境；
- 理解需要；
- 理解解决方案；
- 组织并持久保存解决方案信息。
对我而言，一些关键定义是按顺序来的。为此，参考《Guide to the Business Analysis Body of Knowledge Version 3》（BABOK v3）一书中介绍的业务分析核心概念模型（Business Analysis Core Concept Model，BACCM），其中定义了6个核心概念，如表2-1所述。
这里最相关的核心概念是需要和解决方案，因为它们描述的是分析主题。理解这两个概念之间的区别非常重要，很多IT项目因为在基于解决方案加速前行之前未能确定需要，遭受了巨大痛苦。
在启动一个项目之前，你可能已经知道，应该要明白为什么要启动——换句话说，你要解决的问题是什么。如果你理解了想要解决的问题，或想要利用的机会——需要——就有可能选择最有效的解决方案，并避免把无谓的时间和精力投入到开发一个不需要的解决方案上。我猜你也能说出几个参与的IT项目，其中团队跳过问题的理解直接冲进解决方案的交付。我也曾参与过这样的项目。
为什么团队即便知道理解需要是优秀的实践，但还是会反复地跳过对需要的理解？有时是由于受到项目发起人的压力，这些发起人偏好特定的解决方案并蒙受一些在第4章介绍的认知偏见的痛苦。更可能是，团队不知道如何描述需要，以帮助确定合适的解决方案。其实这样的技术一直存在而且就在我们眼皮底下：目的和目标。
BABOK v3中包含业务目的和业务目标（本书中简化为目的和目标）的定义，如表2-2所示。这些定义的好处是提供了一种方法来区分这两个容易混淆的概念。
具体而言，目的是想要完成的事情（想要满足的需要），目标是如何衡量成功实现目的的程度。在本书中对每个术语在什么时候使用以及在什么地方使用都会非常注意。
既然目标是要可衡量的，当团队建立目标时，把目标的一组特征记在心里是有好处的。这组特征通常称为SMART，如表2-3所述。注意这一缩写代表不同的意思，这里选择使用这一缩写，而其中A代表“达成一致”（agreed upon）以加强团队对目标及其含义达成一致的理念，从而更可能对将要做什么形成共识。
为了强化良好目标的特征，Tom Gilb在《Competitive Engineering》中建议了表2-4所示的属性集，每个目标都能找出这些属性。
注意，在这个例子中限制和基线是一样的。这表明如果这是项目的目标，而你未能改变一周内收到的纸质索赔申请数量的话，项目就失败了，但任何改进都至少是在正确方向上前进了一步。在其他情况下，你会看到把基线和目标值之间的中间值设置为限制，这意味着如果你未能完成某些改进，项目就是失败的。设置这些属性的一个重要价值是为了决定目标值和限制应该是多少而引发的讨论，这让大家对项目成功的样子形成更加明确的理解。
首先理解需要并能够通过目的和目标进行描述，让你有机会与团队针对为什么考虑开始（或继续）一个特定项目建立共识。这也为提出“这个需要值得满足吗？”这一问题形成了一个基础。因而在表2-4纸质索赔申请的例子中，团队就可以问：
立刻提升我们处理纸质索赔申请的能力是值得的吗？
为什么我们认为收到的索赔将会增加？
纸质索赔申请是我们处理索赔能力的最大障碍吗？
我们提升纸质索赔能力的同时要放弃什么？
将需要和解决方案分开考虑，让团队有机会发现多个潜在解决方案，并且当要确定交付的解决方案时还能从中选择。拥有这些可选项，增加了团队高效交付解决方案的机会，而这些解决方案在满足利益相关者需要的同时，还能满足诸如时间和成本等限制。
将需要和解决方案分开考虑也有助于澄清利益相关者和团队的责任。需要来自于利益相关者，特别是项目发起人（sponsor），而解决方案来自于团队。现实并非如此泾渭分明。团队肯定会帮助利益相关者用一种有用的方式描述需要，而团队肯定也需要跟利益相关者密切合作识别潜在的解决方案。
最后，将需要和解决方案分开考虑也和思维模式的转变联系起来，即专注于交付价值——从关注产出转为关注结果，这将在下一节讨论。