作为一个产品人员或需求人员，你有没有这样的苦恼。领导叫你写需求规格说明书，你需求说明书里面的其他内容全写完了，就剩下系统的业务目标还在那里冥思苦想。软件项目需要做哪些业务内容，业务功能，这些功能、内容怎么组织，怎么细化，你都谙熟于心，唯独回答项目的“业务目标”总是好困难。
你有没有这样的经历，接过来售前人员写的方案，你看到了项目背景，现状问题，业务目标，谁是谁，傻傻分不清楚。然后心里默默在骂：“这群傻X售前，公文写了一堆，而我却看不懂在讲什么”。
你会觉得业务目标定义真的很难吗？我以前会这样觉得，因为我不知道什么才是一个业务目标的完整构成，我也不知道为什么每个人对业务目标的写法都不同，甚至有时候，我自己写业务目标的时候，都是胡编乱造，每个地方写的业务目标都没有统一的逻辑。
但是问题总是要解决，然后这几天做了一下梳理，应该可以用统一的思路来定义一个业务目标。如下所示：
- 业务目标的分析思路 = 从上往下分析+从下往上表达
- 业务目标描述 = 使用的解决方案 + 达成的目标 + 已量化的影响
一个朴素的案例
最近看了一个牛梨田的视频。我想转化一下做业务目标分析的现实案例
从上往下分析
背景：在远古社会，人们学会了种植庄稼，但是种植庄稼需要提前松土，使得在更蓬松的土壤上种植农作物，更易于农作物吸收泥土营养，长的更好。
问题：但是人们每次即使是很小块的土地，松土都很费力，因为要依靠人工一个位置一个位置地用锄头及各种工具松土。有些人在日复一日的耕种中，也在思考，是否可以让松土的工作变得更快，更轻松？
解决方案：直到有一天，一个人看到一只野牛在田野里欢脱地散步，于是，他有了一个想法，是否可以让牛来帮忙耕田，于是，就有了牛拉犁的演化过程。
从下往上表达
牛拉犁作为一个生产工具出现，我们定义这个生产工具的业务目标：
使用的解决方案（工具）：牛拉犁
达成的目标：替代人工松土，让松土的工作变得更快更轻松。
已量化的影响：以前每亩地松土需要5天，现在只要2天就可以解决（打比方而已，实际不一定）
拼接起来完整的表达就是：
使用牛拉犁替代人工松土，让松土的工作变得更快更轻松。使得以前每亩地松土需要5天，现在只要2天就可以解决
一个系统的案例
接下来我们用一个实际软件系统的案例，来进行业务目标的分析和描述
从上往下分析
背景：某市政府需要采集该城市的标准地址，标准房屋，标准人口，标准单位数据，作为城市精细化管理的基础。同时城市也分拨了一定的经费，要求，城市的200多万个房屋，500多万个人口，20多万个单位的数据能在今年的6月30日之前完成采集，并形成存档，以及未来可日常更新这些数据。
问题：如果单纯靠人工进行数据采集，那么采集效率低下，且数据整理的难度大，而且难以抓工作完成情况，后续数据更新维护更是困难。
解决方案：所以该城市政府希望建设一个数据采集软件平台，辅助数据采集的日常工作和监督管理工作。
从下往上描述
使用的解决方案（工具）：数据采集软件平台
达成的目标：辅助数据采集的日常工作和监督管理工作，提高采集效率，辅助数据整理，采集人员绩效考核及数据更新维护等工作。
已量化的影响：在6月30日之前完成200多万个房屋，500多万个人口，20多万个单位的数据采集工作，同时采集完的数据可实现实时更新。
拼接起来完整的表达就是：
*使用数据采集软件平台，辅助数据采集的日常工作和监督管理工作，提高采集效率，辅助数据整理，采集人员绩效考核及数据更新维护等工作。确保在6月30日之前完成200多万个房屋，500多万个人口，20多万个单位的数据采集工作，同时采集完的数据可实现实时更新。
总结
“业务目标”：
在分析业务目标的时候，我们需要从业务背景出来，来了解当时的环境下产生的问题，再提供相应的合理的解决方案。
而在分析之后在表达业务目标的时候，则需要结论优先，告诉别人我们的解决方案，再讲这个解决方案可以实现什么目标（也就是解决了哪些问题，让要做的事情变得更美好），最后量化描述解决方案的会提供的预期的影响。
最终，我们总结：
- 业务目标的分析思路 = 从上往下分析+从下往上表达
- 从上往下分析 = 背景 + 问题 + 解决方案
- 从下往上表达 = 使用的解决方案 + 达成的目标 + 已量化的影响
想想，好像也没那么难了，为什么难，也许是因为没有找到合适的方式理解它，解释它，然后应用它。
题外话
目标和问题，这两个名词，也是很搞不懂。后面想想有什么区别呢？可以用味道不同来讲这两个词的不同。
如：我现在的困惑是解不出这道题，这是问题表述，带着负面的不开心的味道
如：我希望能解出来这道题，这是目标的表述，带着一些有所期望的味道
但是他们在反映人的需求上面，其实本质是一样的，都是有了问题，希望能解决问题。
真希望世界上没有那么多专业名词，不过想想也就罢了，还是继续好好想想，在了解了这些专业名词之后，要怎么有效地应用到实践中吧。
