第2章 业务建模之愿景 #

← 返回《软件方法》

2.1 什么是愿景（Vision） #

爆炸法 如果投资人在你身上绑了炸弹，命令你在几分钟之内把当前研究的系统 推销出去，而且只能找一个人推销。假设这个炸弹还能感应脑电波，推 销完毕后，如果炸弹感应到被推销的人对这个系统不感兴趣，就会爆 炸。这种情况下，为了最大可能地保住自己的性命，你会选择向谁推 销，推销时选择说什么话？这个问题的答案就是老大和愿景。 （很多人可能会第一时间想到向自己的父亲或母亲推销，但是，父母会 买单是对你的性命感兴趣，未必对你推销的系统感兴趣，炸弹依然会爆 炸！） 如果上面的场景还不足以刺激你思考，可以用加强版：如果投资人在你 和你的情敌身上绑了炸弹，命令你们几分钟时间内把当前研究的系统推 销出去，谁得到的感兴趣的脑电波强，谁就活下来。 愿景属于业务建模工作流的一部分。为了突出愿景的重要性，本书把它 单独列为一章。 如果缺乏清晰、共享的愿景，开发人员就会兴高采烈地在错误的方向上 狂奔，做得越多，浪费越多。很多年前一位技术总监的话让我印象深 刻： “知道这两个（和愿景相关度最大的）功能实现难度太大做不下去，在我 看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他 功能可以做。” 没有愿景的支持，互联网时代流行的口号“我们只做最重要的需求”“砍掉 80%的功能，专注于剩下的20%”将沦为空话，怎么判断哪条需求最重 要？砍掉哪80%？愿景就是需求排序的主要依据。 愿景如此重要，开发团队却经常不写，或者把它写成一堆空话套话。我 们现在来学习如何从空话套话中把干货提炼出来，写成愿景。 以一个待引入系统为研究对象，其愿景的定义是：在目标组织代表（老 大）看来，引进该系统应该给组织带来的改进。 通俗一点说，一个东西的愿景就是：东西最应该卖给谁，对他有什么好 处？这么简单的问题，回答起来未必容易。开发人员介绍自己的系统 时，洋洋洒洒说一大堆系统有哪些功能，采用什么技术平台、架构等， 但被问到“为什么要做这个系统”时，可能就会瞠目结舌。如果开发人员 的思维停留在“可以工作的软件”（来自“敏捷宣言”）而不是追求“可以卖 的软件”，他甚至会纳闷为什么要思考愿景这个东西！

接下来我们逐步剖析愿景定义中的每一个概念。

2.2 【步骤】定位目标组织和老大 #

2.2.1 目标组织和老大的含义 #

目标组织：待引入系统将改进其流程的组织。它可以是一个机构，也 可以是一个人群。 平时开发人员口中所说的“客户”，实际上就是目标组织，但本书不采 用“客户”这个词，因为“客户”暗含着“和我（开发人员）所在的不是一个 组织”的意思。目标组织可以是开发人员所在的组织，就像医生可以给自 己和同事看病一样。采用“目标组织”这个词，更关注“患者是谁”，而不 是“患者和医生是什么关系”。

老大：目标组织的代表。 老大是一个具体的人，是系统最优先照顾其利益的那个人，相当于某部 戏最重要的观众，如果他不满意，其他人满意也没用。 老大是最重要的观众

老大的头脑是一块块的战场。所研究的系统是军队，开发团队的领导是 军队指挥官，他负责找到自己的军队最值得投入的战场，指挥军队和敌 人厮杀，占领战场，或者防守住敌人的进攻。 定位目标组织和老大的工作，强迫开发人员做更深刻的思考。用户满意 的就是好产品？谁是用户？凭什么人家就满意啊？如果您认真思考并掌 握了本章的技能，相信可以体会到平时听到的那些正确而无用的废话是 多么不入流。

做这些深刻的思考并不容易。很多需求人员是从程序员转型而来，习惯 于从实现者的视角看问题，而不是老大的视角。 有时我问程序员：你最近做什么项目？有的程序员回答：我在做一个Java 项目。对吗？对的！这个项目对于这位程序员来说确实就是一个“Java项 目”，因为他不关心项目的核心域是医院、物流、保险还是城市规划，他 只关心这个项目能否提升他的Java技能，从而对升职加薪有帮助，所以他 把这个项目叫做“Java项目”是十分正确的。并不只是刚入职的程序员会这 样回答，有一次，我问一位有将近十年开发工作经验的架构师最近做什 么项目，架构师回答：在做一个数据仓库项目。继续聊下去，了解到其 实他做的是某通信公司的客户关系管理系统，里面用到了数据仓库，而 数据仓库的知识恰好是他比较缺乏而且感兴趣的，所以他干脆把这个项 目称为“数据仓库项目”了！

如果所研究系统是针对特定人的定制系统，例如“老婆让我为她且只为她 做一个小东西”，就不用讨论了，那个人就是老大。不过这种情况很少， 一般都要做定位的思考。

我把定位目标组织和老大所要做的工作列在图2-4中，分为三种情况来考 虑。需求人员在定位过程中要善于具体化，把产品当成项目来做。

“定制系统”即平时所说的“项目”，“非定制系统”即平时所说的“产品”。

2.2.2 定位情况1：定位目标人群和老大 #

对于图2-4中的情况1，初步判断所研究系统是改善个人的工作，但是没有 指明某特定个人——所有人都可以购买和使用。即使如此，我们也需要 做出取舍，思考系统首先应照顾哪个人群的利益，因为不同人群对系统 的要求是不一样的。 一个老头找到PS可乐公司，告诉他们的主管，“我可是你们的忠诚客户 啊！我喝过的可乐罐排成线，可以从苹果园排到通州（北京从西到 东）。现在我老了，我对你们的可乐下一个版本提出如下要求：第一， 我有胃病，下一个版本不要有这么多气；第二，我有糖尿病，下一个版 本里面不要有糖。”PS可乐公司的主管很感动，哇，这么棒的顾客，把要 求提得那么具体，省下好多我们调研需求的时间，好，下个版本就这么 办！ 可惜，现实生活中不会有这样的场景。老头老太太可以买可乐喝，甚至 可以买给自己的宠物喝，PS可乐公司不会拦着。问题在于，老头老太太 提的要求，或者为他们的宠物提的要求（注意用词：是要求，不是需 求），PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标人群 是青少年。可惜，很多时候我问建模人员：“可乐卖给谁？”得到的回答 大多是“卖给消费者”“卖给想喝可乐的人”等对做出好卖的可乐没有帮助 的、正确而无用的废话 。

@startuml
class 水
class 白水
class 碳酸饮料
class 果蔬汁
class 茶饮料
class 运动饮料
class 纯净水
class 天然水
class 矿物质水
class 可乐型碳酸饮料
class 非可乐型碳酸饮料
class "100%果蔬汁"
class "低浓度果蔬汁"
白水 --|> 水
碳酸饮料 --|> 水
果蔬汁 --|> 水
茶饮料 --|> 水
运动饮料 --|> 水
纯净水 --|> 白水
天然水 --|> 白水
矿物质水 --|> 白水
可乐型碳酸饮料 --|> 碳酸饮料
非可乐型碳酸饮料 --|> 碳酸饮料
"100%果蔬汁" --|> 果蔬汁
"低浓度果蔬汁" --|> 果蔬汁
@enduml

**竞争使得产品分类越来越细，不再有针对所有人的产品。 **

在原始人眼里，喝水是很简单的事情，也没多少选择，靠着河就喝河 水，靠着泉就喝泉水。随着社会的发展，喝水变得越来越复杂，水的种 类不断分化，“水”的含义也在变化（Ries，2005）。“我进超市去买几瓶 水带在路上喝”，您猜会买什么？图2-5展示了超市里摆的各种水，它们都 力争在顾客的大脑中占到一个位置，打败竞争对手，进入顾客那容量有 限的胃中。

更严格的做法可以画出类图，对类的每个属性以及所关联类的每个属性 展开比较，找出最“像”的属性值集合。

@startuml
class 中学生 {
    - 姓名
}
class 性别
class 年级
class 家庭
class 城市
class 学校
class 家庭类别
class 城市类别
class 学校类别
中学生 -- 性别 : 关联
中学生 -- 年级 : 关联
中学生 -- 家庭 : 关联
中学生 -- 城市 : 关联
中学生 -- 学校 : 关联
家庭 -- 家庭类别 : 关联
城市 -- 城市类别 : 关联
学校 -- 学校类别 : 关联
@enduml

• 错误一：从功能加上“人群”二字得到目标人群

一款聊天软件，目标人群定位为“聊天人群”。这种省事的定位，是一 种“正确而无用的废话”。就像开餐馆一样，如果问目标客户是什么人， 直接回答来吃饭的人或肚子饿的人没有任何增值作用，不能帮助餐馆做 出更好卖的菜品。要离开“吃饭”这个功能来定位，例如定位为政府公务 员、IT公司程序员、工地民工等。这三种不同的目标人群，带来的餐馆 风格是不一样的。政府公务员可能去××会馆，适合IT公司程序员的是×× 湘菜馆，工地民工到××大排档。

• 错误二：吃窝边草

做一个老年陪伴机器人，要从老人这个巨大的人群中定位出老大。需求 人员就把老大定位为住在自己对门的郑老先生，毕竟大家是熟人，方便 调研嘛。问题是，郑老先生的老伴还健在呢，他不是最需要这个产品的 人。公司投入大量金钱去研发产品，难道就是为了邻居老大爷高兴？应 该把目光放远，不局限于自己的小区，自己的城市。如果经过严肃思考 发现，某个白人老人更适合当老大，应该想办法去调研这个老人的现 状。 上面的情况还算好的。如果所开发的系统恰好是需求人员自己用得上 的，需求人员干脆就把自己当老大了！例如，做一款幼儿园家长用的 app，需求人员想，哟，我儿子也刚好上幼儿园，干脆就把自己当老大 吧，自己想要什么功能就做，不要的就不做！ 这样的做法确实给需求人员省了不少力气，不用花时间到第一线调研 了，坐在电脑旁让思想“自由飞翔”就可以。软件行业的民粹主义者大力 推崇这样的做法，喊出了“吃自己的狗粮（dogfooding）”“工程师文化”等 得到广大软件人员响应的口号——问题是，“软件人员喜欢”和“目标人群 喜欢”很多时候是不一致的。 没有交易的情况下，农民要吃东西只能自己种，而且自己种的东西只能 自己吃。现代社会中，为别人生产以获得利润是常态，过于强调“吃自己 的狗粮”很容易成为需求人员另一个偷懒的庇护所。 一名专业研究白血病的医生，如果自己也得了白血病，在不影响日常生 理功能的情况下，“吃自己的狗粮”也许在研究白血病方面会比其他医生 动力更足、体会更深，获得的成果更大，但这种情况发生的概率有多少 呢？以上面幼儿园家长app为例，“身为IT人士的幼儿园家长”可能不是最 需要这个app的幼儿园家长。

• 错误三：虚构老大 还有一种偷懒的庇护所是虚构一个老大，还美其名曰Persona。这种做法 说白了也是鼓励建模人员免去深入第一线调研的辛苦，安心闭门造车。 如果内心里觉得深入第一线调研至关重要，就不会找这个庇护所了。例 如，为女性做一个产品，建模人员深入第一线调研，面对的调研对象是 一个个具体的女性。如果建模人员把调研的精力花在罗玉凤身上，留给 林志玲的精力就不多了，所以必须思考罗玉凤更像老大还是林志玲更像 老大的问题。相比起来，关在办公室随意捏造一个符合自己要求的“女 性”省事多了。

2.2.3 定位情况2：定位机构范围和老大 #

第二种情况，系统改进的目标组织是某个机构。这个机构可能是一个公 司、一个政府单位、一个部门、一个小组、一个家庭。 这时需要考虑的一个问题是如何恰当圈定所研究机构的范围。这个问题 没有标准答案，可能要尝试很多次。如果发现所圈定机构内部的大多数 流程和改进不相干，说明圈的范围可能大了；如果发现很多要改进的流 程未涉及，说明圈的范围可能小了。 很多时候，从系统的名字都可以推测范围大小。例如，“××企业管理系 统”改进的可能是整个企业，而“××营销管理系统”改进的可能是企业里的 市场营销部。 另一个推测方法是：画一个圈，把大多数可能被（部分/全部）替换责任 的系统（人脑系统/电脑系统……）圈在里面。 例如：要开发一个企业内部员工训练平台，初步判断替换的责任大多属 于人力资源部人脑系统的工作，这时可以把人力资源部作为研究对象。

请注意上面的用词，“大多数可能被替换责任的系统”，而不是“大多数系 统用户”。因为此时待引入系统的边界尚未确定，不能先入为主地把某些 人脑系统称为用户（本书后面会说到，不是“用户”，而是“执行者”）。系 统要做的改进和训练专员的工作有关，不代表训练专员一定是该系统的 执行者，也许人力资源总监会觉得把训练专员的全部责任转移到新电脑 系统可能是更好的方案，这样，业务流程就不需要训练专员的参与了。 所圈定的范围大小和老大的职权范围相关。如果老大只是人力资源总 监，把整个公司作为研究对象就太大了；如果老大只是大学里面某个学 院的院长，把整个大学作为研究对象就太大了。 在定位机构范围和老大的时候，思维是逐步逼近的。最开始机构中的某 个涉众（可能不是老大）提到要做一个什么系统，还提供了一些模糊的 目标，建模人员根据这些素材推敲到机构范围，再定位老大，揣摩老大 的愿景，再从愿景来判断之前的范围是否要调整。如果范围变化，老大 可能要再做调整……循环往复，逐步逼近。

• 错误一：目标机构的IT主管是老大 很多时候，开发团队并不能常见到真正的机构负责人，常见到的干部可 能是该机构下属的IT部门主管，头衔可能是“信息中心主任”。这个IT主管 平时从事的也是计算机或软件方面的工作，大家一见面，大谈特谈“微服 务架构、大数据、云计算……”，业务方面却难得深入讨论。

IT主管不是老大，因为系统要改进的不是目标机构IT部门的流程，而是业 务部门的流程。所以，老大应该是业务部门主管或机构负责人，视系统 改进波及的范围而定。当然，如果改造的就是目标机构IT部的流程，那 就另当别论了。我们谈论项目中的涉众时，很多时候简单地划分为甲方 乙方，这是不够的。要看涉众实际做的工作，甲方的IT部门其实也是“乙 方”。 以看病做类比。患者病情比较严重或者患者不便交流的时候，和医生频 繁打交道的可能是患者的家属，但切不可因此把患者家属架上手术台。

• 错误二：机构之上的大领导是老大 例如，要做一个系统，改进某大型电商企业仓储部门的拣货效率问题， 把老大定为该电商集团公司董事长，就选得不合适了。大领导是大，可 是大领导脑子里关心的是一个集团、一个市、一个省甚至一个国家的指 标的改进，不关心具体某个软件系统给某个小局部带来的改进。大领导 的某些期望，可能适用于成千上万个系统，无法直接指导建模人员寻找 和过滤特定系统的需求。 大领导作为老大，也不符合我们之前提到的“爆炸法”。例如，向国家领 导人推销所开发的系统，如果成功了，当然回报最大，问题是推销时能 向国家领导人说什么呢？说“提高了拣货效率”？国家领导人关心的是国 家层面上的“GDP”“通胀率”“就业率”等指标，所以推销词只能说“可以为 GDP做贡献”，而这句推销词适合上百万种产品，国家领导人能从这么 多“为GDP做贡献”的候选者中挑中你的系统的概率微乎其微！ 大领导可能也会对某个小局部提出要求，但这种情况下也要从大领导关 注的机构范围层面上领会其中的精神，而不是简单认为大领导说的就是 这件小事。例如，国家领导人到上面提到的那家大型电商企业视察，对 仓储部门的某台自动拣货机很感兴趣，还即兴发表了重要讲话。不能说 这台自动拣货机的老大就是国家领导人，也不能简单地认为国家领导人 说的话仅仅是针对这台自动拣货机或针对这家大型电商企业。

• 错误三：谁出钱谁就是老大 改进的资金有各种各样的来源，但不能说谁出钱最多谁就是老大，还要 选择要改进的机构，把它作为研究组织，其负责人是老大。出钱的各方 可以作为老大下面的各种涉众，他们的利益也是要考虑的。 还是以看病做类比。患者治病的钱可能是自己出，也可能是家属出，政 府出，同房病友捐赠，甚至由医院免单。不管怎样，上手术台的还是患 者。

• 错误四：把其他涉众当作老大 有的时候需求人员把老二老三当作了老大，这种错误要分两种情况看。 如果需求人员已经尽力去调研和思考，只不过高层人员之间的微妙关系 以及决策的来源确实比较难探究，那问题不大，毕竟已经尽力，总比没 想过这个问题要好得多，也许我们的竞争对手根本没想过这个问题，或 者把老八当成了老大。

如果需求人员出于偷懒，一发现自己能接触到的某个人比较有权力，就 干脆把他当老大以求尽快完成任务，这就不应该了。 就像考试一样，试卷难度大没关系，只要尽力了就好，因为对手也难， 竞争态势没有变化。如果偷懒没尽力，那就不好说了。

既然这里提到了“其他涉众”，那就多说几句。愿景只关注老大的目标， 不代表不考虑其他人的目标，只是现在先放下，后面再考虑。其他人的 目标叫做涉众利益。愿景实际上就是系统最重要涉众的利益。

涉众，指受到系统影响的各种人。拿拍电影做类比，需求像电影剧本， 涉众像电影观众。剧本只有一份，观众却各不相同，即不同观众的欣赏 角度和口味不同。鲁迅说过：一部红楼梦，经学家看见《易》，道学家 看见淫，才子看见缠绵，革命家看见排满，流言家看见宫闱秘事。

软件系统也是如此。以本章开头举的生产执行管理系统为例，老大制造 部王部长关注的是“缩短从接到市场部订单到交付产品的时间周期”，车 间工人更关心“我这个岗位的工作量会不会增加”，库管员可能担心“以后 不好搞手脚”。

演员（执行者，Actor）在台上表演，观众（涉众，Stakeholder）在台下看

一部戏应该演什么内容，不是由演员决定的，而是由台下各 种观众的口味角逐而定。观众按照重要性排排坐。这部戏先要照顾第一 排观众的口味，然后再照顾第二排观众的口味……同理，软件系统也要 依次照顾各排涉众的利益。涉众利益之间的冲突和平衡，决定了系统的 需求。对于实在照顾不到的后排涉众，很多时候只好抱歉了，这个系统 可能会损害你的利益。

当然，演员也可以充当观众，甚至有的大牌演员还能坐在前排，影响剧 本的部分内容。

涉众利益的介绍先说到这里，在本书后面的第6章“需求之系统用例规 约”和第7章“需求启发”中，还会详细谈到涉众利益的细节问题。

2.2.4 定位情况3：定位目标机构 #

第三种情况，系统是为某一类机构服务。那么，除了第二种情况中要做 的工作之外，还需要插入一步：定位目标机构。定位目标机构的思考方 法和定位目标人群的思考方法是一样的。

要做一个电子病历产品卖给医院，说“客户是医院”肯定不够。医院也一 样越来越细分，有大型三甲医院，也有二级医院、中心卫生院，甚至社 区卫生服务中心……还有根据性别细分的男子医院、女子医院，根据人 体器官细分的口腔医院、肝病医院、肛肠医院……还不要忘了国外的医 院，美国的JHH、Mayo、乌干达的@%&，孟加拉的&￥#……通过类图比 较属性值，慢慢缩小范围，最终定位具体的医院，例如“大兴中医 院”（见图）。

@startuml
' 定义类
class 医院 {
}
class 医院等级
class 城市
class 患者
class 性别
class 语言类别
class 城市类别
' 关联关系
医院 -- 医院等级 : 关联
医院 -- 城市 : 关联
医院 -- 患者 : 关联
患者 -- 性别 : 关联
患者 -- 语言类别 : 关联
城市 -- 城市类别 : 关联
@enduml

可能有人会担心，哎呀，要是我们只关注“大兴中医院”，那“协和医院”的 需求是不是漏掉了？问题是，“大兴中医院”想要的都还没有满足，去 想“协和医院”干什么？认为需求“漏掉”的想法是幼稚的。需求是一口深 井，永远做不完。只要您愿意，可以满世界去调研所有医院，甚至不用 调研，拍脑袋就可以得出上万条“需求”。 和定位目标人群一样，在定位目标机构的时候，也要警惕自己是不是犯 了“吃窝边草”的错误。例如针对上面提到的电子病历产品，错误的做法 是轻易地把目标机构定位本地比较熟悉的一家医院，却没有进一步思考 这家医院是否是最合适的医院。 这个方面，我印象最深的就是“新桃源酒家”。和开发团队讨论他们的餐 饮系统，同样要问到“哪个餐馆最像系统所针对的餐馆”的问题，开发团 队的同事答“新桃源酒家”。问桃源酒家在哪，就在公司旁边。投真金白 银去做一个系统，目标组织不知不觉定义成“地理位置离开发公司最近的 餐馆”，多可惜。应该放开眼界，认真思考，如果思考结果指向兰州的某 家“兰州料理”店，应该毫不犹豫地飞过去调研。 也许有人会说：“哈，说得轻巧，公司要生存，刚好我爸是李刚，和本地 的客户有关系，先把窝边草给吃了活下来再说。”这样的想法也没问题， 只是必须承认当前我们所做的系统是一个给那个窝边草客户定制的系统 （项目），而不是自欺欺人地假设自己在做非定制系统（产品）。当 然，在分析设计时，考虑将来的复用是没问题的，但在做需求时不能首 鼠两端。

2.2.5 其他一些要点 #

• 1．开发团队领导不是老大 建模人员还有一个偷懒的庇护所适用于上面列举的各种情况——老大就 是我们开发团队的领导（总经理、研发总监或部门经理等），因为领导 让我做什么我就做什么。 这个答案来得太容易了，不需要思考，而且放之四海而皆准。这样的答 案对做出好卖的产品没有帮助。这个时候，还是要进一步揣摩领导心中 的目标客户是什么样子，而不是简单地把自家领导当成客户。自家领导 不是老大，他是决定老大的人。 用前文提到的“爆炸法”来思考，自家领导就是在您身上绑炸弹让您去卖 东西的人，您居然还想把东西卖给他，好傻好天真啊！ 当然，开发团队成为买方的时候，领导就是老大。例如，购买开发工具 ，购买开发技术培训服务，购买 这本书……不过这时开发团队已经不 再是“开发团队”了。针对上面列举的这几个研究对象，它们的“开发团 队”是工具厂商开发团队、培训教育机构和本书作者。

这里说的“购买”是广义的，不仅是付出金钱，也可以是付出声誉、官 职、时间等。我没有付钱给微信和Google，但确实是在花我最宝贵的“时 间”来使用它的服务。 “投币法”可以帮助需求人员排除开发者自身的影响，不仅有助于找老 大，也有助于在后面的需求工作中排除设计的干扰。

• 投币法又叫团灭法 为了锁死人类的软件技术，三体人派出智子（参见刘慈欣小说《三 体》）监控所有软件开发人员的行为，一旦发现某人有编制软件的 行为，将在该人的大脑中产生长达十分钟的电击信号，让其痛不欲 生。为了使将来的奴隶——人类的生活不至于倒退，三体人在地球 上安放了很多软件开发机。只要对着开发机说清楚软件的功能和性 能并投币，开发机将生成所需软件并部署好。

• 2．人群和机构，谁是战场 要开发一个系统挑战新浪微博，或者思考新浪微博应该提供什么新功 能，研究的目标组织应该怎么选？很多人在不知不觉中会把新浪公司作 为研究组织，但这意义不大，因为研究新浪公司的内部流程对思考系统 的需求没有太多价值。正确的做法是把目标人群——明星大V人群作为研 究组织，然后从里面挑出最像明星大V的明星大V作为老大，例如苍井老 师。 不过，要观察苍井老师及其团队的运作，难度是比较大的，所以很多时 候建模人员就害怕了，千方百计要退回来研究新浪公司。这相当于在黑 暗的地方丢了钥匙，却到明亮的地方找，只是因为这里亮堂。 针对正式机构可能已经有很多人做过严肃的建模，而针对松散的人群， 这方面资料要少很多，许多改进点只靠拍脑袋发现。所以，对松散的“目 标人群”做业务建模，是创业很好的入手点。 当然，如果要改进的是新浪公司内部的运营工作，把新浪公司作为研究 对象是合理的。总之，关键战场在哪里，就把它作为研究的对象。 一般来说，公司初始阶段，关键是要把客户从竞争对手那里抢过来，强 调“出奇”，这时定位的战场可能是目标人群；公司发展到成熟期，就要 开始练内功，强调“守正”，这时定位的战场可能是公司内部。

• 3．人群和人群，谁是战场 还是以上面的新浪微博作为例子。运用“投币法”，我们知道苍井老师只 关心这个系统的功能和性能能否高效地帮她向粉丝散播魅力，不关心这 个系统是路上捡到的，还是新浪、搜狐甚至是外星人开发的。 把运营的公司隐去后，系统连接的两端都是人群，这时问题就更微妙一些：哪个 人群是战场？

更为稀缺的人群的头脑应优先选为战场。新浪微博能够击败其他微博， 很大部分原因是攻克了明星大V人群的大脑（可能是用金钱），让他们在 新浪开微博，粉丝也就闻风而至了。

再例如做一个在线看病的平台，一端是患者，一端是医生，谁的大脑是 兵家必争之地？我想在某些发展中国家应该是医生，因为穹顶之下不缺 好患者，缺的是好医生。

这里可能会有建模人员说，战场在哪里弄那么清楚干什么，我全面开花 不行吗？好吧，就算资源充足，要全面开花，那也得告诉我进攻的第一 炮打向哪里吧！ 许多建模人员的老爸不是李刚，却有“如果我爸是李刚”的思想和做派，这是很可悲的。

★“如果”二字害人不浅。建模人员嘴皮子一动，就把很难的前提条件当成 已经存在的了——“如果时光可以倒流”、“如果我是皇帝”。

★在给某单位做一个内部项目时，建模人员A自作主张加进去一些用例。 我认为这些用例和客户的愿景关系不大，可以去掉。A反问道：如果做一 个通用的产品在市场上卖呢？“如果”！是否做通用产品，这可是一个重 大的商业决策，建模人员却认为将这个系统变成通用产品拿到市场上卖 （目标组织变了）是一件轻而易举的事情。事实上，这涉及整个愿景的 转变，甚至公司战略的转变，而且需求受影响的可能不只是当前这个系 统。市场是残酷的，谁吃肉谁喝西北风，可不能随便“如果”。

★我听过的最让人震惊的“如果”是关于敏捷的一个宣传。在喊了“唯快不 破”等鼓舞人心的口号后，说了这样一句：如果允许新手一次走两步，他 甚至可以击败象棋大师（现在应该改为击败AlphaGo了）。一股“普天之 下皆我妈”的味道。

• 4．老大可以变化吗 当然可以。一个战场搞定之后，军队奔向第二个战场。或者说，根本不 存在变化的问题。老大、愿景、需求都是基于现状寻找最值得的改进。 改进过后，又是新的现状了，还是基于现状寻找最值得的改进。进一步 也可以说，需求只有真假对错，没有变化。说需求有变化，那是从一个 静止时间点来看的。

一家航空公司把自己定位为“低价的快乐航空”，那么以下做法 不合适的是___。b c都存在一定的原则冲突

A）不提供机上餐饮，只提供花生米和水 B）在机舱里撒彩纸屑庆祝乘客生日 C）模仿唐老鸭的嗓音讲解乘机规则 D）所有飞机用同种机型

2.3 【步骤】提炼改进目标 #

一份愿景中，改进目标可以是一个，也可以是多个。改进目标应该是可 以度量的。我把愿景相关的概念画成类图，如图所示。

@startuml
' 系统改进目标模型图
skinparam Linetype ortho
' 定义类及属性
class 系统 {
}
class 改进目标 {
    - 名称
}
class 老大 {
}
class 组织 {
}
class 行为 {
}
class 用例 {
}
class 路径 {
}
class 改进 {
    - 改进值
}
class 指标 {
    - 名称
    - 详细描述
    - 当前值
}
' 关联关系与多重性
系统 -- "1" 改进目标 : 带来
改进目标 ..> 改进 : 度量
改进 ..> 指标
指标 ..> 行为 : 适用
用例 --|> 行为
路径 --|> 行为
老大 -- 组织 : 代表
组织 -- 改进目标 : 以……的视角
改进目标 -- 行为
' 显示组合关系
组织 *-- 行为
路径 --* 用例
@enduml

2.3.1 改进目标不是系统功能需求 #

改进目标是“系统改善组织行为的指标”而不是“系统能做某事（系统的功 能）”。

改进组织行为的指标，不是做某事

改进目标和系统功能是多对多的：一个改进目标可能会带来系统的多个 功能，一个系统功能可能覆盖多个改进目标。如“提高防汛决策 准确度”是改进目标，不是功能。系统没有提供这样一项功能，领导输入 一个准确度数值，确认，防汛决策准确度“duang”的一下就提高了。只有 在各个岗位分别使用系统的“查看云图”“上报水库运行情况”等功能之 后，“防汛决策准确度”这个指标才能得到提高。

比起拍脑袋胡说系统有什么功能，要得到可度量的改进目标更加困难。 当目标组织是正式机构时，老大可能是公司管理层或政府官员，日程安 排很紧张，需求人员不可能经常接触到他。如前文所说，代表机构和需 求人员接触的接口人是“甲方信息中心主任”这样的人，需要通过或绕过 接口人去揣摩真正老大的意思。

就算有机会接触到机构负责人，可能会发现他说的话比较“艺术”，这是 他用来展示控制权的方式，也是辨别手下人是否和自己一条心的手段。 需求人员依然需要通过各种手段揣摩老大云雾缭绕的话语背后的度量指 标。需求人员可以阅读老大的其他讲话、报告，咨询老大派来的接口 人，也可以求助本方高层——同样的一句话，小兵思维层次不够高，觉 得云里雾里，也许高层早已洞若观火了。

如果老大是人群的代表，有时还是比较好接触到的。例如要做面向民工 的“黑米”手机，老大是民工中的民工，一顿烧烤就可以让他尽吐真言。 不过事情依然很困难，这位民工中的民工虽然容易亲近，却不能清楚地 表达自己存在的问题和改进目标，需要需求人员认真去倾听和观察，体 察他的痛苦。这个问题我们在第7章“需求启发”中还会再说到，“涉众会做 但不会定义”。

这些揣摩技能，我们每个人都有。我们每天都在揣摩上司、同事、配偶 的意思，只不过现在要把这项技能用在软件开发上。设想一下，如果不 是开发软件，而是给目前单身的老大介绍个相亲对象。老大说：“帮我找 个条件不错的”，您不也得从老大的角度揣摩“不错”的度量指标吗？老大 更看重的是脸、身材、皮肤、性格、学历、家底？切不可因为自己喜欢 凤姐，就给老大带个凤姐回来。

有时建模人员说：“哪有什么度量指标啊，我们做的那个系统就是个政绩 工程，客户领导去××省考察回来，说××省有一套××系统，我们也要 有！”其实，“政绩”二字本身就隐含着数字的概念，政绩工程也一样有度 量指标。需求人员仍然需要好好去揣摩：老大关心什么样的政绩指 标？“揣摩上意”本来就是某些体制下官场的基本生存技能。

思考度量指标，可以用以下方法。

针对形容词来思考符合这个形容词和不符合这个形容词的情况 。例 如，目标里有个形容词“规范”，我们可以问：目前怎么个不规范，请举 一个最头痛的例子。如果改进之后，老大觉得规范多了，那是什么样的 情况？通过这样追问，得到“规范”的度量是“格式不合格的报表所占的比 例”。类似的度量还有：

方便——完成一张订单的平均操作次数高效——从受理到发证的时间周期

从初步设想的解决方案倒推 。可以这样思考：如果没有这个解决方案， 涉众要付出什么代价？例如，初步的解决方案是做一个手机上审批费用 申请的app，可以反过来问“如果没有这个app，可能会怎样”，“领导不在 办公室时不方便审批”，那么度量指标可能是“平均审批周期/领导不在办 公室的时间”。最终的解决方案未必是手机app，要是能打个响指，空中 飘来一朵云，领导在云上划拉两下就行，谁耐烦带个手机弄得鼓鼓囊囊 的呢？

借鉴机构的 KPI（关键绩效指标） 。很多机构都归纳了自己的KPI，所 研究系统可能就是改进其中的一部分，借鉴过来就可以。

2.3.2 改进目标不是系统的质量需求 #

改进目标针对的是组织某个行为的指标，而不是系统行为的指标。 要从组织的视角去看系统对于组织的意义。系统的一项质量需 求可能是“从接收到请求到回应的时间应在2秒之内”，这是对系统行为的 度量。愿景的改进目标是思考在组织的视角之下这条需求的意义，可能 是“缩短申请的平均审批周期”，如图所示。

        系统的质量需求是对系统行为的度量
        组织的改进目标是对组织行为的度量

2.3.3 改进是系统带来的 #

有的建模人员“大彻大悟”，说“老大的目标就是为了赚更多钱，当更大 官……不管什么系统，万变不离其宗”。没错，老大最终就是想升官发 财，但这个回答是“正确而无用的废话”，对于探索系统的需求没有帮 助。目前官当得不够大、赚钱还不够多的原因可能有很多条，而每条原 因又有各自的若干原因。很可能所研究系统能解决的仅仅是“赚钱少”这 个大问题的原因的原因的原因中的一到两条。

• 过大的目标 “减少医疗事故”这个目标过大了，适用于各种各样的改进（包括更换另 一种品牌的手术器械），没有“移动病区护士系统”特有的味道
• 恰当的目标 ”减少错误执行医嘱的发生率“

如何定位系统能带来的恰如其分的改进目标，可以使用管理学中的“鱼骨 图”来帮忙。 UML中没有鱼骨图，可以用类图代替，如图所示。

@startuml
skinparam Linetype ortho
"无菌操作不到位" --|> "护士原因"
"未根据个体差异调节速度" --|> "护士原因"
"宣教不到位" --|> "护士原因"
"特定年龄群体患者增加" --|> "患者原因"
"特定疾病患者增加" --|> "患者原因"
"药品质量不达标" --|> "材料和药品原因"
"输液工具不达标" --|> "材料和药品原因"
"护士原因" --|> "输液反应投诉多"
"患者原因" --|> "输液反应投诉多"
"材料和药品原因" --|> "输液反应投诉多"
@enduml

2.3.4 改进目标应来自老大的视角 #

改进目标描述的是系统给目标组织带来的改进，应该从老大和目标组织 的视角来定义。不过在实践中，需求人员会觉得要揣摩老大的目标太 难，不知不觉就把它改成开发团队的目标。这种“目标”通常如下：

一年以内，网站的会员达到一千万； 系统的市场占有率达到40%。

这种不费吹灰之力得到的“目标”没有意义——你想会员达到一千万就能 一千万吗？需求人员要动脑筋思考，系统必须在哪些地方给目标组织带 来竞争对手所无法达到的改进，例如：

“YP网”的目标是剩女发起相亲的平均成功率达到60%以上。

这样，目标组织（上面这句话就是剩女人群）才会乐意引进这个系统。

2.3.5 多个目标之间的权衡 #

如果愿景里只表述了一个改进指标，那么可以默认其他指标是不变的。 不过，有的时候老大的改进可能会有多个目标（当然也带来了多个指 标），而且目标之间还有可能会产生冲突。这时，需要对目标排序，揣 摩出老大首要关心的目标。 例如，一个给地产经纪计算佣金的系统，老大要求在尽可能短的时间内 计算出佣金，同时计算要准确，每一步的操作过程事后可以追究。这几 个目标是有冲突的，要“准确”，要“每一步可以追究”，“快”就要受到影 响。经过揣摩，发现老大最看重的是“准确”。在计算规则不断变化的情 况下，也不能出任何计算错误，否则导致分配不公，影响经纪人的工作 积极性。了解了这一点，就会意识到最开始设想的解决方案是有偏差 的，这个系统的实现不需要精美的图形界面，但是规则的调整要灵活， 而且不能出错。