业务建模--愿景 | 产品壹佰

业务建模--愿景

定位目标组织和老大，找到愿景，明确系统的用力方向

愿景定义

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

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

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

爆炸法：如果投资人在你身上绑了炸弹，命令你几分钟时间内把当前研究的系统推销出去，而且只能找一个人推销。假设这个炸弹还能感应脑电波，推销完毕后,如果炸弹感应到被推销的人对这个系统不感兴趣，炸弹就会爆炸。这种情况下，你会选择向谁推销，推销时选择说什么话，保住自己性命的可能性最大？这个问题的答案就是老大和愿景。（很多人可能会第一时间想到向自己的父亲或母亲推销，但是，父母会买单是对你的性命感兴趣，未必对你推销的系统感兴趣，炸弹依然会爆炸！）如果上面的场景还不足以刺激你思考，可以用加强版：如果投资人在你和你的情敌身上绑了炸弹，命令你们几分钟时间内把当前研究的系统推销出去，谁得到的感兴趣的脑电波强，谁就活下来。

目标组织和老大

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

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

定位目标人群和老大

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

常见错误：

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

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

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

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

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

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

定位机构范围和老大

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

定位机构范围

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

一般有两个方法：

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

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

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

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

定位目标机构

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

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

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

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

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

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

开发团队领导，不是老大人群和机构，谁是战场。以新浪微博为例，社交媒体平台，那么核心还是媒体属性。研究的应该是大V等产生核心内容的人群，而不是新浪这个机构。人群和人群，更为稀缺的优先选为战场。例如在线问诊平台，老大应该是医生。当然，现在好多都是拆分为医生端和患者端，这样体验会更好。根据阶段不同，老大也可以变化。说需求有变化，那是从一个静止的时间点来看。

提炼改进目标

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

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

不是系统功能需求

改进目标和系统功能是多对多的：一个改进目标可能会带来系统的多个功能，一个系统功能可能覆盖多个改进目标

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

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

•针对形容词来思考符合这个形容词和不符合这个形容词的情况。

•从初步设想的解决方案倒推。思考如果没有这个解决方案，涉众要付出什么代价。

•借鉴机构的KPI*（关键绩效指标）：

不是系统质量需求

改进目标针对的是组织某个行为的指标，而不是系统行为的指标。

改进是系统带来的

某医院护士系统开始的愿景如下所示：

这个目标太大了，叫做正确的废话

通过如下类图，进行分析：

类图定位改进目标

护士的主要工作是输液、抽血等，以输液为例。系统能解决的，主要是操作层面的问题，所以恰当的目标应该是：

多个目标之间的权衡

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

软件行业有个著名的不可能铁三角， 范围S、进度T、成本C ， 当然也可以说是项目的四要素：范围、进度、成本和质量。

理论上，是没有又实时访问、速度又快的多维统计报表提供给高层决策的。以大屏BI举个例子：

市场面上大屏BI常见方案，也就是销量数据时刻前端自增更新，后端服务器ETL调度执行，定期同步数据。

这种方案，是由于老大更看中“准确”，但对数据的时效性又有一定的要求。但哪怕硬件条件很好，也就是1分钟上下刷新一次。部分复杂的统计逻辑，1分钟内可能ETL都跑不完。

博客原文链接: https://bakerhancockchen.github.io/2019/04/29/ye-wu-jian-mo-yuan-jing/
本文章著作权归作者所有，任何形式的转载都请注明出处。