Press "Enter" to skip to content

业务建模–愿景

愿景定义

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

 

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

 

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

 

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

 

目标组织和老大

 

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

 

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

 

 

定位目标人群和老大

 

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

 

常见错误:

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

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

 

 

    1. 目标客户到底是谁?肯定是中学生,中学生学业压力大,更需要学习方法的提升。小学生大政策上都要减负,家长喜欢素质教育。再小一点,都没学习的压力。

 

    1. 中学生包括初中生、高中生,到底哪个更符合?都可以的。

 

    1. 不能都可以,总要找个更合适的,哪个更合适?初中生吧。

 

    1. 为什幺是初中生?初中生往往没掌握系统的学习方法,需要我们网站的帮助。

 

    1. 哪个年级的初中生更合适?当然是初一的学生。他们刚从小学保姆式的教育中脱离,学习方法没有那幺系统。课程压力又忽然增大,这时候对学习方法提升很迫切。

 

    1. 哪里的初中生合适?一二线城市的初中生比较合适。一方面用户更习惯互联网,用户教育成本低。另一方面,一二线城市教育竞争激烈,经济基础好,家长学生的需求比较旺盛。最后,网络基础设施好,效果更好。

 

 

作者提供了更严格的方法,使用类图:

 

 

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

 

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

 

定位机构范围和老大

 

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

 

定位机构范围

 

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

 

一般有两个方法:

 

 

    1. 根据系统名字推测范围大小

 

    1. 画一个圈,把大多数能被替换责任的系统圈在里面:

 

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

 

定位老大

 

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

 

 

    1. 目标机构的IT主管是老大,这个是常见的错误。一般做项目,甲方项目经理是IT部门的人员,所以可能发言较多。绝大多数情况下,系统的愿景的解决业务部门的问题,适配业务部门的流程。

 

    1. 机构之上的大领导是老大。这个范围扩大了,具体落地的时候需求会不够具体。

 

    1. 谁出现谁就是老大,这个也比较常见。通常一个系统可能涉及多个业务部门,主要费用由某个部门出。例如营销中心下的A渠道出费用,还有B、C两个渠道。实际上,要以营销中心为研究对象,老大应该是营销老总。

 

    1. 把其他涉众当作老大。例如营销管理系统,当然要以营销中心为研究对象。但由于调研安排以及高层间的微妙关系,会出现把市场部当老大的情况。

 

 

定位目标机构

 

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

 

这个还是一样,使用类图,辅助定位:

 

 

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

 

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

 

做了一个或几个项目,然后形成解决方案,把最大那个项目的代码照搬,这就是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/

 

本文章着作权归作者所有,任何形式的转载都请注明出处。

Be First to Comment

发表评论

电子邮件地址不会被公开。 必填项已用*标注