软件方法第2章业务建模之愿景

第2章业务建模之愿景

谁挽起弓箭，射天空的火舌，谁偷仙丹飞天，月宫安守青天

《天问》；词：周耀辉，曲：刘以达，唱：达明一派；1989

****************************************************************************

您在阅读《软件方法》时如果发现错误，欢迎通过下面提供的邮箱、微信或QQ告知。如果作者认为有道理，决定在下一次发布时根据您的意见修改，将付给您5.12元报酬，并在书中说明您的贡献。报酬通过支付宝或微信支付。（1）任何您认为的错误都可以，包括错别字。（2）同一错误仅支付最先指正者报酬。（3）请根据最新版本作指正。QQ和QQ邮箱：1493943028@qq.com，微信：umlchinapan

****************************************************************************

2.1什么是愿景（Vision）

爆炸法：

如果投资人在你身上绑了炸弹，命令你几分钟时间内把当前研究的系统推销出去，而且只能找一个人推销。假设这个炸弹还能感应脑电波，推销完毕后,如果炸弹感应到被推销的人对这个系统不感兴趣，炸弹就会爆炸。这种情况下，你会选择向谁推销，推销时选择说什么话，保住自己性命的可能性最大？这个问题的答案就是老大和愿景。

（很多人可能会第一时间想到向自己的父亲或母亲推销，但是，父母会买单是对你的性命感兴趣，未必对你推销的系统感兴趣，炸弹依然会爆炸！）

如果上面的场景还不足以刺激你思考，可以用加强版：如果投资人在你和你的情敌身上绑了炸弹，命令你们几分钟时间内把当前研究的系统推销出去，谁得到的感兴趣的脑电波强，谁就活下来。

愿景属于业务建模工作流的一部分。为了突出愿景的重要性，本书把它单独列为一章。

如果缺乏清晰、共享的愿景，开发人员就会兴高采烈地在错误的方向上狂奔，做得越多，浪费越多。很多年前一位技术总监的话让我印象深刻：

“知道这两个（和愿景相关度最大的）功能实现难度太大做不下去，在我看来这个项目已经没有价值，但是开发人员还乐在其中，觉得还有其他功能可以做。”

没有愿景的支持，互联网时代流行的口号“我们只做最重要的需求”、“砍掉80%的功能，专注于剩下的20%”将沦为空话，怎么判断哪条需求最重要？砍掉哪80%？愿景就是需求排序的主要依据。

愿景如此重要，开发团队却经常不写，或者把它写成一堆空话套话。我们现在来学习如何从空话套话中把干货提炼出来，写成愿景。

以一个待开发系统为研究对象，其愿景的定义是：在目标组织代表（老大）看来，引进该系统给组织应该带来的改进。

图2-1是愿景的一个例子：

系统：

生产执行管理系统

老大:

龙翔公司制造部王部长

目标（度量）:

*缩短从接到市场部订单到交付产品的时间周期。度量：（交付时间-接单时间）/件数

图2-1 愿景示例

通俗一点说，一个东西的愿景就是：东西最应该卖给谁，对他有什么好处？这么简单的问题，回答起来未必容易。开发人员介绍自己的系统时，洋洋洒洒说一大堆系统有哪些功能，采用什么技术平台、架构等等，但被问到“为什么要做这个系统”时，可能就会瞠目结舌。如果开发人员的思维停留在“可以工作的软件”（敏捷宣言语）而不是追求“可以卖的软件”，他甚至会纳闷为什么要思考愿景这个东西！

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

2.2 建模步骤1-1 定位目标组织和老大

2.2.1 目标组织和老大的含义

目标组织：待开发系统将改进其流程的组织。它可以是一个机构，也可以是一个人群。

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

老大：目标组织的代表。

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

图 2-2 老大是最重要的观众

老大的头脑是一块块的战场。所研究的系统是军队，开发团队的领导是军队指挥官，他负责找到自己的军队最值得投入的战场，指挥军队和敌人厮杀，占领战场，或者防守住敌人的进攻。

图2-3 在老大的大脑里厮杀

定位目标组织和老大的工作，强迫需求人员作更深刻的思考。“用户满意的就是好产品”？谁是用户？凭什么人家就满意啊？如果您认真思考并掌握了本章的技能，相信可以体会到平时听到的那些正确而无用的废话是多么不入流。

做这些深刻的思考并不容易。需求人员很多时候是从程序员转型而来，习惯于从实现者的视角看问题，而不是老大的视角。

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

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

	情况	系统改进范围	定位老大的步骤
1	针对特定人的定制系统	某个特定人	这个人就是老大
2	针对人群的非定制系统	某个人群	定位目标人群定位老大
3	针对某特定机构的定制系统	某特定机构	定位机构范围定位老大
4	针对某类机构的非定制系统	某类机构	定位机构范围定位目标机构定位老大

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

图2-4 定位目标组织和老大所要做的工作

情况1类似于“老婆让我为她且只为她做一个小东西”，就不用讨论了。我们从情况2开始讨论。

2.2.2 定位老大情况2-定位目标人群和老大

对于图2-4中的情况2，初步判断所研究系统是改善个人的工作，但是没有显式指明某特定个人——所有人都可以购买和使用。即使如此，我们也需要做出取舍，思考系统首先应照顾哪个人群的利益，因为不同人群对系统的要求是不一样的。

一个老头找到PS可乐公司，告诉他们的主管，“我可是你们的忠诚客户啊！我喝过的可乐罐排成线，可以从苹果园排到通州（北京从西到东）。现在我老了，我对你们的可乐下一个版本提出如下要求：第一，我有胃病，下一个版本不要有这么多气；第二，我有糖尿病，下一个版本里面不要有糖。“PS可乐公司的主管很感动，哇，这么棒的顾客，把要求提得那么具体，省下好多我们调研需求的时间，好，下个版本就这么办！

可惜，现实生活中不会有这样的场景。老头老太太可以买可乐喝，甚至可以买给自己的宠物喝，PS可乐公司不会拦着。问题在于，老头老太太提的要求，或者为他们的宠物提的要求（注意用词：是要求，不是需求），PS可乐公司不会放在重要的位置来考虑，因为PS可乐的目标人群是青少年。可惜，很多时候我问建模人员：“可乐卖给谁？”得到的回答大多是“卖给消费者”，“卖给想喝可乐的人”等等对做出好卖的可乐没有帮助的、正确而无用的废话。

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

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

图2-5 超市里摆的各种“水”抢夺顾客的胃（此处“水”的含义不是H₂O，而是“可饮用物质”）

图2-6展示了品牌不同、功能类似的产品如何匹配到不同的目标人群或老大。

依云幼儿园大班小朋友黄小明

旺仔熬夜加班的程序员赵广才

红牛小清新女孩韩梅梅

iPad 四川叙永县水头中学初二学生李红艳

小米平板滨海电子职业学院学生雷阳

读书郎在远洋国际中心上班的女职员张莉

图2-6 产品和人群的对应

定位目标人群和老大的思考方法是不断追问“谁比谁更像？”、“为什么？”。类似下面的对话：

A--这个网站目标客户是？

B--中学生。

A--初中生更像还是高中生更像你说的“中学生”？

B--都可以的。

A--不能“都可以”，必须要比出谁比谁更像。

B--初中生吧？

A--为什么？

B--因为大多数初中生还没掌握基本的学习方法，需要我们的网站帮忙。

A--哪个年级的初中生更合适？

……

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

图2-7 通过类图帮助定位目标人群

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

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

常见错误二：吃窝边草。

做一个老年陪伴机器人，要从老人这个巨大的人群中定位出老大。需求人员就把老大定位为住在自己对门的郑老先生，毕竟大家是熟人，方便调研嘛。问题是，郑老先生的老伴还健在呢，他不是最需要这个产品的人。公司投入大量金钱去研发产品，难道就是为了邻居的老大爷高兴？应该把目光放远，不局限于自己的小区，自己的城市。如果经过严肃思考发现，德州（美国，不是山东）的某个白人老头更适合当老大，应该想办法去调研这个老头的现状。

上面的情况还算好的。如果所开发的系统恰好是需求人员自己用得上的，需求人员干脆就把自己当老大了！例如，做一款幼儿园家长用的app，需求人员想，哟，我儿子也刚好上幼儿园，干脆就把自己当老大吧，自己想要什么功能就做，不要的就不做！

这样的做法确实给需求人员省了不少力气，不用花时间到第一线调研了，坐在电脑旁让思想“自由飞翔”就可以。软件行业的民粹主义者大力推崇这样的做法，喊出了“吃自己的狗粮（dogfooding）”、“工程师文化”等得到广大软件人员响应的口号——问题是，“软件人员喜欢”和“目标人群喜欢”很多时候是不一致的。

没有交易的情况下，农民要吃东西只能自己种，而且自己种的东西只能是自己吃。现代社会中，为别人生产以获得利润是常态，过于强调“吃自己的狗粮”很容易成为需求人员另一个偷懒的庇护所。

一名专业研究白血病的医生，如果自己也得了白血病，在不影响日常生理功能的情况下，“吃自己的狗粮”，也许在研究白血病方面会比其他医生动力更足、体会更深，获得的成果更大，但这种情况发生的概率有多少呢？以上面幼儿园家长app为例，“身为IT人士的幼儿园家长”可能不是最需要这个app幼儿园家长。

常见错误三：虚构老大。

还有一种偷懒的庇护所是虚构一个老大，还美其名曰Persona。这种做法说白了也是鼓励开发人员免去深入第一线调研的辛苦，安心闭门造车。如果内心里觉得深入第一线调研至关重要，就不会找这个庇护所了。在具体的访谈中，开发人员面对的是一个个具体的女人林志玲、罗玉凤，而非抽象的“女人”。你把精力花在罗玉凤身上，留给林志玲的精力就不多了。

2.2.3 定位情况3-定位机构范围和老大

第3种情况，系统改进的目标组织是某个机构。这个机构可能是一个公司、一个政府单位、一个部门、一个小组、一个家庭。

这时需要考虑的一个问题是如何恰当圈定所研究机构的范围。这个问题没有标准答案，可能要尝试很多次。如果发现所圈定机构内部的大多数流程和改进不相干，说明圈的范围可能大了；如果发现很多要改进的流程未涉及，说明圈的范围可能小了。

很多时候，从系统的名字都可以推测范围大小。例如，“××企业管理系统”改进的可能是整个企业，而“××营销管理系统”改进的可能是企业里的市场营销部。

另一个推测方法是：画一个圈，把大多数可能被（部分/全部）替换责任的系统（人脑系统/电脑系统…）圈在里面。

例如：要开发一个企业内部员工训练平台，初步判断替换的责任大多属于人力资源部人脑系统的工作，这时可以把人力资源部作为研究对象：

图2-8 把大多数可能被替换责任的系统圈在里面

请注意上面的用词，“大多数可能被替换责任的系统”，而不是“大多数系统用户”。因为此时待开发系统的边界尚未确定，不能先入为主地把某些人脑系统称为用户（本书后面会说到，不是“用户”，而是“执行者”）。系统要做的改进和训练专员的工作有关，不代表训练专员一定是该系统的执行者，也许人力资源总监会觉得取消所有的训练专员可能是更好的方案，也就是说，训练专员的全部责任转移到新电脑系统上，业务流程就不需要训练专员的参与了。

所圈定的范围大小和老大的职权范围相关。如果老大只是人力资源总监，把整个公司作为研究对象就太大了；如果老大只是大学里面某个学院的院长，把整个大学作为研究对象就太大了。

在定位机构范围和老大的时候，思维是逐步逼近的。最开始机构中的某个涉众（可能不是老大）提到要做一个什么系统，还提供了一些模糊的目标，建模人员根据这些素材推敲到机构范围，再定位老大，揣摩老大的愿景，再从愿景来判断之前的范围是否要调整。如果范围变化，老大可能也要再做调整……循环往复，逐步逼近。

图2-9 逐步逼近真正的老大和愿景

错误一：目标机构的IT主管是老大

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

IT主管不是老大，因为系统要改进的不是目标机构IT部门的流程，而是业务部门的流程。所以，老大应该是业务部门主管或机构负责人，视系统改进波及的范围而定。当然，如果改造的就是目标机构IT部的流程，那就另当别论了。我们谈论项目中的涉众时，很多时候简单地划分为甲方乙方，这是不够的。要看涉众实际做的工作，甲方的IT部门其实也是“乙方”。

以看病做类比。患者病情比较严重或者患者不便交流的时候，和医生频繁打交道的可能是患者的家属，但切不可因此把患者家属架上手术台。

错误二：机构之上的大领导是老大

例如，要做一个系统改进某大型电商企业仓储部门的拣货效率问题，把老大定为该电商集团公司董事长，就选得不合适了。大领导是大，可是大领导脑子里关心的是一个集团、一个市、一个省甚至一个国家的指标的改进，不关心具体某个软件系统给某个小局部带来的改进。大领导的某些期望，可能适用于成千上万个系统，无法直接指导建模人员寻找和过滤特定系统的需求。

大领导作为老大，也不符合我们之前提到的“爆炸法”。例如，向国家领导人推销所开发的系统，如果成功了，当然回报最大，问题是推销时能向国家领导人说什么呢？说“提高了拣货效率”？国家领导人关心的是国家层面上的 “GDP”、“通胀率”、“就业率”等指标，所以推销词只能说“可以为GDP做贡献”，而这句推销词适合上百万种产品，国家领导人能从这么多“为GDP做贡献”的候选者中挑中你的系统的概率微乎其微！

大领导可能也会对某个小局部提出要求，但这种情况下也要从大领导关注的机构范围层面上领会其中的精神，而不是简单认为大领导说的就是这件小事。例如，国家领导人到上面提到的那家大型电商企业视察，对仓储部门的某台自动拣货机很感兴趣，还即兴发表了重要讲话。不能说这台自动拣货机的老大就是国家领导人，也不能简单地认为国家领导人说的话仅仅是针对这台自动拣货机或针对这家大型电商企业。

错误三：谁出钱谁是老大

改进的资金有各种各样的来源，但不能说谁出钱最多谁就是老大，还是要选择要改进的机构作为研究组织，其负责人是老大。出钱的各方可以作为老大下面的各种涉众，他们的利益也是要考虑的。

还是以看病做类比。患者治病的钱可能是自己出，也可能是家属出，政府出，同房病友捐赠……，甚至是医院免单。不管怎样，上手术台的还是患者。

错误四：把其他涉众当作老大

很多时候需求人员确实比较难探究高层人员之间的微妙关系以及决策的来源，把老二老三当作了老大。不过，把老二老三当老大，总比没想过这个问题要好得多，也许我们的竞争对手根本没想过这个问题，或者把老八当成了老大。

愿景只关注了老大的目标，不代表不考虑其他人的目标了，只是现在先放下，后面再考虑。

其他人的目标叫做涉众利益。愿景实际上就是系统最重要涉众的利益。

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

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

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

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

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

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

2.2.4 定位情况4-定位目标机构

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

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

图2-11 通过类图帮助定位目标机构

可能有人会担心，哎呀，要是我们只关注“大兴中医院”，那“协和医院”的需求是不是漏掉了？问题是，“大兴中医院”想要的都还没有满足，去想“协和医院”干什么？认为需求“漏掉”的想法是幼稚的。需求是一口深井，永远做不完。只要您愿意，可以满世界去调研所有医院，甚至不用调研，拍脑袋就可以得出上万条"需求"。

和定位目标人群一样，在定位目标机构的时候，也要警惕自己是不是犯了“吃窝边草”的错误。例如针对上面提到的电子病历产品，错误的做法是轻易地把目标机构定位本地比较熟悉的一家医院，却没有进一步思考这家医院是否最合适的医院。

这个方面，我印象最深的就是"新桃源酒家"。和开发团队讨论他们的餐饮系统，同样要问到“哪个餐馆最像系统所针对的餐馆”的问题，开发团队的同事答“新桃源酒家”。问桃源酒家在哪，就在公司旁边。投真金白银去做一个系统，目标组织不知不觉定义成“地理位置离开发公司最近的餐馆”，多可惜。应该放开眼界，认真思考，如果思考结果指向兰州的某家“兰州料理”店，应该毫不犹豫飞过去调研。

也许有人会说：哈，说得轻巧，公司要生存，刚好我爸是李刚，和本地的客户有关系，先把窝边草给吃了活下来再说。这样的想法也没问题，只是必须承认当前我们所做的系统是一个给那个窝边草客户定制的系统（项目），而不是自欺欺人地假设自己在做非定制系统（产品）。当然，在分析设计时，考虑将来的复用是没问题的，但在做需求时不能首鼠两端。

2.2.5 其他一些要点

2.2.5.1 开发团队领导不是老大。

开发人员还有一个偷懒的庇护所适用于上面列举的各种情况——老大就是我们开发团队的领导（总经理、研发总监或部门经理等），因为领导让我做什么我就做什么。

这个答案来得太容易了，不需要思考，而且放之四海皆准。这样的答案对做出好卖的产品没有帮助。这个时候，还是要进一步揣摩领导心中的目标客户是什么样子，而不是简单地把自家领导当成客户。自家领导不是老大，他是决定老大的人。

用前文提到的“爆炸法”来思考，自家领导就是在您身上绑炸弹让您去卖东西的人，您居然还想把东西卖给他，好傻好天真啊！

当然，开发团队成为买方的时候，领导就是老大。例如，购买开发工具，购买开发技术培训服务，购买这本书……。不过这时开发团队已经不再是“开发团队”了。针对上面列举的这几个研究对象，它们的“开发团队”是工具厂商开发团队、培训教育机构和本书作者。

这里说的“购买”是广义的，不仅是付出金钱，也可以是付出声誉、官职、时间等。我没有付钱给微信和Google，但确实是在花我最宝贵的“时间”来使用它的服务。

“智子法”可以帮助需求人员排除开发者自身的影响，不仅有助于找老大，也有助于在后面的需求工作中排除设计的干扰。

智子法：

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

2.2.5.2 人群和机构，谁是战场？

要开发一个系统挑战新浪微博，或者思考新浪微博应该提供什么新功能，研究的目标组织应该怎么选？很多人在不知不觉中会把新浪公司作为研究组织，但这意义不大，因为研究新浪公司的内部流程对思考系统的需求没有太多价值。正确的做法是把目标人群——明星大V人群作为研究组织，然后从里面挑出最像明星大V的明星大V作为老大，例如苍井老师。

不过，要观察苍井老师及其团队的运作，难度是比较大的，所以很多时候建模人员就害怕了，千方百计要退回来研究新浪公司。这相当于在黑暗的地方丢了钥匙，却到明亮的地方找，只是因为这里亮堂。

针对正式机构可能已经有很多人做过严肃的建模，而针对松散的人群，这方面资料要少很多，许多改进点只靠拍脑袋发现。所以，对松散的"目标人群"做业务建模，是创业很好的入手点。

当然，如果要改进的是新浪公司内部的运营工作，把新浪公司作为研究对象是合理的。总之，关键战场在哪里，就把它作为研究的对象。

一般来说，公司初始阶段，关键是要把客户从竞争对手那里抢过来，强调“出奇”，这时定位的战场可能是目标人群；公司发展到成熟期，就要开始练内功，强调“守正”，这时定位的战场可能是公司内部。

2.2.5.3 人群和人群，谁是战场？

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

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

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

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

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

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

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

2.2.5.4 老大可以变化吗？

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

扫码或访问http://www.umlchina.com/book/quiz2_1.htm完成在线测试，做到全对以获得答案。

1. 一家航空公司把自己定位为“低价的快乐航空”，那么以下做法不合适的是

 A) 不提供机上餐饮，只提供花生米和水

 B) 在机舱里撒彩纸屑庆祝乘客生日

 C) 模仿唐老鸭的嗓音讲解乘机规则

 D) 所有飞机用同种机型

2. 以下是一位初中数学老师某天的工作描述。

6:45-7:10 坐K566公交到学校

7:10-8:00 挑出一些几何课的图，交代课代表在黑板上先画好，整理教学工具、课件U盘

8:10-8:50 上午第一节课（3班几何）等腰梯形，导入课程，内容展开

9:00-9:40 上午第二节课（3班几何）等腰梯形，巩固练习，小结，布置作业，抽空批改之前作业

9:40-10:10 课间休整

10:10-10:50 上午第三节课（4班几何）等腰梯形，导入课程，内容展开

11:00-11:40 上午第四节课（4班几何）等腰梯形，巩固练习，小结，布置作业，抽空批改之前作业

11:40-13:00 午餐、午休

13:00-14:30 批改作业。课代表送作业上来，摊开摞好，一本本批改，给分

如果做一个系统改善该老师的工作，这个系统最应该提供的功能是

 A) 把书上的图复制到黑板上，动态添加和清除辅助线

 B) 扫一下作业自行给出得分

 C) 统计作业和测试情况

 D) 信息不足，看不出来

3. 如果有一位程序员告诉您说“我在做一个Python项目”，这时您应该想到

 A) 他可能从自己的角度定义所做的项目

 B) Python怎么这么火，我也要学

 C) 编程语言背后的道理是一样的

 D) 还是我做的Java需求量大

4. 请把左侧功能类似的不同软件系统和右侧不同的老大画线对应

微信 a 发达公司销售总监侯总

QQ b 意见领袖任大炮

微博 c 武汉市滑坡路小学学生黄艺博

A) 1-a，2-b，3-c

B) 1-a，2-c，3-b

C) 1-b，2-a，3-c

D) 1-b，2-c，3-a

E) 1-c，2-a，3-b

F) 1-c，2-b，3-a

5. 请把左侧功能类似的不同软件系统和右侧不同的老大画线对应

Rational Rhapsody a 青华大学软件专业学生王思葱

Enterprise Architect b 生产战斗机的LoMa公司研发总监Pony Ma

StarUML c 生存下来进入发展期的京西购物网研发总监李总

A) 1-a，2-b，3-c

B) 1-a，2-c，3-b

C) 1-b，2-a，3-c

D) 1-b，2-c，3-a

E) 1-c，2-a，3-b

F) 1-c，2-b，3-a

6. 以“微信多开”app为研究对象，以下对老大的定位最贴切的是：

A) 微信用户张大龙

B) 山水集团总经理高小琴

C) 阿尔法公司总经理郑乾

D) “微信多开”app研发团队领导张多龙

7. 研发部要添加一名C#程序员，由人力资源部负责出面招人，请问针对这名C#程序员（一个人脑编程系统），老大是？

A) 人力资源部经理

B) 研发部经理

C) 公司总经理

D) C#程序员

8. 请针对曾经红极一时的“快播”软件，按照图2-7画出客户的类图，并推测出“快播”的老大。

2.3 建模步骤1-2 提炼改进目标

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

图2-12 愿景相关概念的类图

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

改进目标是“系统改善组织行为的指标”，而不是“系统能做某事”（系统的功能）。请比较图2-13左右两列的内容。

像目标的表述	不像目标的表述
提高回访订单转化率	建立一个CRM系统
减少每张处理订单需要的人力	提供自助下单功能
缩短评估贷款风险的周期	能够对贷款申请作风险评估

图2-13 改进组织行为的指标，不是做某事

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

图2-14 改进目标 vs. 系统功能

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

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

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

这些揣摩技能，我们每个人都有的。我们每天都在揣摩上司、同事、配偶的意思，只不过现在要把这项技能用在软件开发上。设想一下，如果不是开发软件，而是陪老大到澳门泰国的休闲场所玩。老大说“帮我找个一流的技师”，您不也得从老大的角度揣摩“一流”的度量指标吗，老大更看重的是三围？脸蛋？年龄？技术？切不可因为自己喜欢凤姐，就给老大带个凤姐回来。

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

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

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

方便——完成一张订单的平均操作次数

高效——从受理到发证的时间周期

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

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

图2-15 关键绩效指标

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

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

图2-16 系统的质量需求是对系统行为的度量

图2-17 组织的改进目标是对组织行为的度量

2.3.3 改进是系统带来的

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

例如，“移动病区护士系统”的愿景一开始如图2-18所示。

系统：

移动病区护士系统

老大:

Z大学附属第*医院院长张**

目标:

*减少医疗事故

图2-18 过大的目标

“减少医疗事故”这个目标过大了，适用于各种各样的改进（包括更换另一种品牌的手术器械），没有 “移动病区护士系统”特有的味道。改为图2-19的内容更合适。

系统：

移动病区护士系统

老大:

Z大学附属第*医院病区护士长李**

目标:

*减少错误执行医嘱事件的发生率

图2-19 恰当的目标

如何定位系统能带来的恰如其分的改进目标，可以使用管理学中的“鱼骨图”来帮忙，如图2-20。

图2-20 鱼骨图帮助定位真正的问题

UML中没有鱼骨图，可以用类图代替，如图2-21。

图2-21 类图代替鱼骨图

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

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

一年以内，网站的会员达到一千万。

系统的市场占有率达到40%。

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

“YP网”的目标：男屌丝发起约会的平均成功率达到30%以上。

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

2.3.5 多个目标之间的权衡

如果愿景里只表述了一个改进指标，那么可以缺省地认为其他指标是不变的。不过，有的时候老大的改进可能会有多个目标（当然也带来了多个指标），而且目标之间还有可能会产生冲突。这时，需要对目标排序，揣摩出老大首要关心的目标。

例如，一个给地产经纪计算佣金的系统，老大要求在尽可能短的时间内计算出佣金，同时计算要准确，每一步的操作过程事后可以追究。这几个目标是有冲突的，要“准确”，要“每一步可以追究”，“快”就要受到影响。经过揣摩，发现老大最看重的是“准确”。在计算规则不断变化的情况下，也不能出任何计算错误，否则导致分配不公，影响到经纪的工作积极性。了解了这一点，就会意识到最开始设想的解决方案是有偏差的，这个系统的实现不需要精美的图形界面，甚至用脚本都可以，但是规则的调整要灵活，而且不能出错。

扫码或访问http://www.umlchina.com/book/quiz2_2.htm完成在线测试，做到全对以获得答案。

1. 1999年11月的《财富》杂志题为“20世纪企业家”的文章，评选出了最能代表20世纪企业家精神的企业家─福特汽车的Henry Ford。另外三位候选人是通用汽车的Alfred Pritchard Sloan Jr.、,IBM的Thomas John Watson Jr.和微软的William H. Gates Sr.

请问，按照本书对愿景的定义，Henry Ford以下哪句话最像福特汽车公司的愿景？

A) 让每个家庭都拥有一辆汽车。

B) 让普通大众更经常和家人去兜风。

C) 尽可能提高质量, 尽可能降低成本, 尽可能提高薪水。

2. 某年某月的某一天，祁同伟厅长给赵东来局长下了指示“东来啊，我们要加强对扫黄工作的管理”。作为一名需求人员，想要用本章知识剖析祁同伟厅长的指示，最应该做的是：

A) 针对“强”揣摩祁同伟的度量指标。

B) 置之不理，祁同伟不是老大。

C) 针对“黄”揣摩祁同伟的度量指标。

D) 仔细查阅扫黄的有关法规，严格执行。

3. 做一个研发部内部使用的“统一开发平台”，以下长得像愿景的是：

 A) 建立一个统一开发平台

 B) 为公司赚取更多的利润