如果我们不能清晰自己业务的发展方向,不了解公司所处的赛道,不能有效的搭建适合自己发展的研发体系,我们就很难在这场竞赛中胜出。
一、明确公司所处的赛道
事实上世界没有伟大的企业,有的只是时代的企业。比盈利更重要的是企业对赛道的选择,而赛道就是“战略”。近20年,随着万物互联,企业的发展轨迹出现了颠覆性的改变。我们见证了IBM、诺基亚等巨头企业的衰落,也见证了微软、苹果等企业的成功转型,及BAT等更多巨头的崛起。选错赛道对于在发展过程中的企业而言,轻则前功尽弃,重则迈向深渊。
同时,企业所处的赛道对于研发的要求也是不尽相同,可能研发没有选择赛道的权利,但最起码要清晰的明确公司的赛道是啥,否则企业明明走的是山路,而我们准备的却是快船,就无法起到研发对业务的强大的支撑能力了。
站在对研发体系具有较大影响的赛道分析,需要我们清晰辨别,比如:
企业主体是传统企业还是科技企业;如果是科技公司,是偏软件公司还是更偏互联网公司?产品方向是以TO C产品为主还是以TO B产品为主?业务领域是健康领域还是医疗领域?客户是医院客户还是政府客户?是医疗信息化产品还是互联网医疗产品?应用特点是企业级应用还是智能化应用?甚至企业发展是靠自身利润还是资本市场都对研发体系或多或少都有影响。
老谭过去几年一直从事TO C领域的互联网产品,去年开始进入新的领域做TO B的产品研发,我梳理了两个赛道对于企业能力的差异,从而指导建立的研发体系更适合当前的赛道特点。所以清晰赛道,才能对症下药。
二、明确公司的业务模式
明确了公司的发展赛道,保证了大方向是没问题的,但是同样处于一样赛道的两家企业,可能因为业务模式不同,对于研发的要求也是有差别的。比如华为做手机和小米做手机,他们所搭建的研发体系肯定是不同的。
老谭现在所在的公司的主赛道是TO B方向的互联网医疗,我们简单分析一下TO B领域的几种业务模式的差别:
根据我们自己所处的赛道特点,软件外包模式很难实现融资上市;医院由于数据安全性的苛刻要求,本地化部署是现在难以改变的现状,云服务模式在医疗领域并不是主流;因为无法提供云服务,所以想做成平台模式的企业也是很难。所以产品销售模式是我们的业务模式,基于该模式思考构建合适的研发体系。
刚开始完全基于产品研发团队划分,按照产品规划迭代的方式不停的发布新的产品版本,在产品初期时这个研发节奏还是非常的好,有条不紊的在向前推进。但是随着医疗信息化的产品开始推向市场以后,问题随之而来。
信息化的产品很难通过标准化的功能来满足客户,客户的需求边界也不完全符合产品定义的边界,而实施团队的资源配置也只能做到成熟产品的集成对接和小范围的修改,为了项目的正常推进,产品研发人员就开始时不时的拉到前线。
因为前期销售压力也比较大,前方业务在抓项目机会时,也开始逐步的脱离产品的边界,产品迭代无法正常的维持,导致智能化产品因为市场主导还是有序的进行,而信息化产品这部分就比较混乱了。
对于成熟的产品或者市场驱动的业务,大家通常的做法就是基于产品找项目。基于产品来构建市场策略、产品规划、销售渠道以及客户服务。但对于不成熟的产品或者市场驱动力不足的业务,通过项目带产品的方式估计也是很多公司采取的策略,很多软件外包公司向产品型公司转型过程就是基于这样的策略。
不论是产品找项目还是项目带产品在业务模式设计上没有对错、优劣之分,要根据实际情况合理的选择,但是我要说的是这两种模式对于研发体系的建设是有影响的,一个重产品管理,一个重项目管理,对于人员结构,开发流程,管理模式都有影响。
所以针对这种情况,我粗略的把团队内的产品基于这个角度划分了项目型产品和市场型产品,并配置不一样的研发体系。
三、明确当前的研发阶段
研发体系的建设是一个循序渐进的过程,不要以为我们通过了CMMI3或者CMMI5的认证,就说明我们的研发体系是完整的、成熟的。市场在变化,企业的战略方向、业务模式也不是一成不变的,而我们的软件研发的成熟度也是逐步在提升的,所以明确我们自己所处的研发阶段以及未来的研发需求而不断的进行改进。
这个表是IPD研发体系的产品研发能力的级别定义,根据这个级别的评估标准,自己可以评估自己团队的研发能力在哪个层级上,制定升级打怪的具体举措。老谭在去年负责整体研发时对自己团队进行了能力级别分析,当时我们其实已经有了几个不错的项目在做,但因为之前都各自为战,产品相对独立,算是在级别3的初级水平。
明确了我们在哪和我们要去哪,研发体系建设就是怎么去的过程。
从去年开始我们以中台思想作为指导,加强了公共能力建设及沉淀,技术路线进行明确的定义,同时强化了平台对于产品的支撑能力,产品的集成和复用也在逐步的增多,过去那种分散的产品体系开始逐步整合统一,团队之间的协作以及能力的共享复用也在加强。但过程中依然出现了各种问题,这也是我写这个专栏的目的,通过分享自己研发管理的过程来获取更多反馈的信息,从而时时校验自己,纠正自己。