愿景定义

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

一个系统的愿景就是：这个系统为用户提供了什么好处，让用户愿意为此买单

作者提供了一种“爆炸法”，辅助我们更好的找到愿景：

爆炸法：

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

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

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

目标组织和老大

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

老大：目标组织的代表

在B端，目标组织更多时候被称呼为“客户”。而老大，是系统最优先照顾其利益的那个人（一般是业务部门leader）。一般有以下几种情况：

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

定位目标人群和老大

第二种情况，系统改进的目标组织是改善个人工作，但不清楚是具体的人，还是某类人群，甚至所有人。

常见错误：

从功能加上“人群”二字得到目标人群
吃窝边草，就近找老大
虚构老大

正确思考方法是不断追问，层层细化，直到满意为止。以某虚构的K12教育网站为例，细化其目标客户：

目标客户到底是谁？肯定是中学生，中学生学业压力大，更需要学习方法的提升。小学生大政策上都要减负，家长喜欢素质教育。再小一点，都没学习的压力。
中学生包括初中生、高中生，到底哪个更符合？都可以的。
不能都可以，总要找个更合适的，哪个更合适？初中生吧。
为什么是初中生？初中生往往没掌握系统的学习方法，需要我们网站的帮助。
哪个年级的初中生更合适？当然是初一的学生。他们刚从小学保姆式的教育中脱离，学习方法没有那么系统。课程压力又忽然增大，这时候对学习方法提升很迫切。
哪里的初中生合适？一二线城市的初中生比较合适。一方面用户更习惯互联网，用户教育成本低。另一方面，一二线城市教育竞争激烈，家长学生的需求比较旺盛。最后，网络基础设施好，效果更好。

作者提供了更严格的方法，使用类图：

类图定位目标人群

对类的每个属性以及所关联的每个属性展开比较，找出最“像”的属性值集合

这个方法，其实很像现在互联网中的用户画像。但是很多产品的用户画像是后续运营得到的，前期必须通过用户研究得到，不能虚构得到persona。

定位机构范围和老大

第三种情况，系统改进的目标组织是某个机构。定位目标结构范围和老大的时候，思维还是逐步逼近的。

定位机构范围

首先要解决的是，如何恰当的确定所研究机构的范围。这个可能要尝试多次，范围大了小了都很正常。

一般有两个方法：

根据系统名字推测范围大小
画一个圈，把大多数能被替换责任的系统圈在里面：

定位机构的范围，其实和老大的职权范围有关，老大是营销总监，把整个公司作为研究对象就太大了。

定位老大

定位老大有以下常见的错误：

目标机构的IT主管是老大，这个是常见的错误。一般做项目，甲方项目经理是IT部门的人员，所以可能发言较多。绝大多数情况下，系统的愿景的解决业务部门的问题，适配业务部门的流程。
机构之上的大领导是老大。这个范围扩大了，具体落地的时候需求会不够具体。
谁出现谁就是老大，这个也比较常见。通常一个系统可能涉及多个业务部门，主要费用由某个部门出。例如营销中心下的A渠道出费用，还有B、C两个渠道。实际上，要以营销中心为研究对象，老大应该是营销老总。
把其他涉众当作老大。例如营销管理系统，当然要以营销中心为研究对象。但由于调研安排以及高层间的微妙关系，会出现把市场部当老大的情况。

定位目标机构

系统是为某一类机构服务的，除了上述讲的，还要进行目标机构的定位。

这个还是一样，使用类图，辅助定位：

类图定位目标机构

公司目标是盈利，起码要生存。很可能有了一个想法，找到了第一个客户，就以这个为目标客户，进行分析。这个是完全没有问题的，但是必须承认当前做的是项目（针对该客户的定制系统）。设计的时候可以考虑复用，但是做需求不能首鼠两端。

展开一下，国内好多公司规模变大盈利增速却不匹配，就是项目和产品没理清。甚至乎，太多的“卖人头”公司，组织架构真正有产品部的少。最常规的做法是：

做了一个或几个项目，然后形成解决方案，把最大那个项目的代码照搬，这就是1.0产品了。

这样的产品，不说技术架构扩展差，功能的完整性都很难保证。一般的项目，是不会考虑各种分支异常流程的，一些非功能性需求就更没有了。

其他要点

开发团队领导，不是老大

人群和机构，谁是战场。以新浪微博为例，社交媒体平台，那么核心还是媒体属性。研究的应该是大V等产生核心内容的人群，而不是新浪这个机构。

人群和人群，更为稀缺的优先选为战场。例如在线问诊平台，老大应该是医生。当然，现在好多都是拆分为医生端和患者端，这样体验会更好。

根据阶段不同，老大也可以变化。说需求有变化，那是从一个静止的时间点来看。

提炼改进目标

一份愿景中,改进目标可以是一个，也可以是多个，改进目标应该是可以度量的

作者把愿景相关的概念画成了类图：

愿景相关概念的类图

不是系统功能需求

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