购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

2.4 系统性研发管理体系各要素的关系

2.4.1 产品开发流程

公司的产品开发流程类似一个城市的高速公路网,从客户的需求产生到产品开发成功并上市营销的全过程,要通过一套流程体系把各种角色和活动贯穿起来,并且流程的设计一定要按照角色来设计,这样公司的组织结构不管怎么变化,都不会影响流程的执行。流程可按照阶段、步骤、任务与活动的方式来设计,如图2.3所示。

图2.3 产品开发流程体系

不管什么行业,产品开发流程大概都分为以下6个阶段:

● 概念阶段

● 计划阶段

● 开发阶段

● 验证阶段

● 发布阶段

● 生命周期管理阶段

产品开发流程示例如图2.4所示。

图2.4 产品开发流程示例

1.概念阶段

概念阶段从商业层面确定产品开发的策略。产品开发不仅是技术开发,产品的制造策略、测试策略、知识产权策略、受控销售策略都是要考虑的,就看你公司所处的行业。

举一个例子,产品还没有上市,甚至样机刚出来,就有客户要买了,这个时候就很麻烦,你到底卖还是不卖?

如果卖,产品质量不能保证。有的公司说质量是我们的生命,看来公司的生命就不能保证了。

如果不卖,竞争对手就会卖,最后跟客户成交了。这时你再想把这个客户抢回来就非常困难了。

这种情况怎么办呢?我也不知道怎么办。但有一点可以肯定,你不能此时再想怎么办,已经晚了。在开始立项前就要想好,将来在哪个阶段客户要买怎么办,这就是新产品的受控销售策略。

在技术层面,这个阶段要确定产品需求。市场管理流程确定市场需求(客户需求加用户需求就是市场需求),市场需求加老板需求(如标准、法律、法规、可靠性、可制造性、可服务性、可测试性、可安装性等)就等于产品需求。

2.计划阶段

计划阶段就是把策略变成计划,即考虑规格和方案并建立基线。概念阶段和计划阶段是最重要的。这两个阶段是做正确的事,后面四个阶段是把事做正确,所以前面两个阶段需要高水平的人投入更多的时间和精力。

3.开发阶段

开发阶段是研发人员最熟悉的,也是投入资源最多的阶段。

4.验证阶段

验证并不是测试,验证要拿到客户那里去做。验证完了才是发布。

5.发布阶段

有的行业发布费用很高,如请明星做代言。

6.生命周期管理阶段

在生命周期管理阶段,要考虑3个方面:停止销售、停止制造、停止服务。

这是端到端的流程,这就是产品开发。如果做产品开发,项目经理就应该从头负责到尾,而不是到样机就不管了,所以项目团队应该端到端负责。

7.评审

评审流程示例如图2.5所示。

图2.5 评审流程示例

这6个阶段中间有评审,如第一个评审点叫概念决策评审点,不少公司从这里开始进行项目管理,我们觉得有点晚了。为什么?好比小孩已经生下来了,但只有一条腿,把他培养成才的难度不是很大吗?所以怀孕期间(概念阶段)也要做正规的过程管理。

举个例子,人们平常什么时候去医院?病了。其实是这时的病你有感觉了,因为有很多病初期你不知道。我们感觉有病后,到医院一检查,可能结果就是癌症晚期。

英语“看病”怎么翻译?see the doctor,直译是看医生。我说美国人没病看什么医生呀,后来才知道这才是最牛的。没病就看医生,所以以后就不会有病了。而我们平常不看医生,感觉病了才去医院,一看就是晚期,连治疗的机会都没有。

我们想早期发现病灶,找个治疗的机会怎么办呢?

体检。

评审就好比体检,很多公司有评审,也有的公司评审的目的是提前把关。我特别讨厌“把关”这个词,为什么呢?因为我有非常不愉快的被把关的经历。我理解的把关是一个人站在关口拿棍子把着,从这儿过的不合格的就打回去,于是经常有人被打得鼻青脸肿的。

评审也是一样的,不少公司设了一些部门,如质量部或总工办做所谓的提前把关,这很不受项目经理和项目团队成员的欢迎:他们为什么把我打得鼻青脸肿?为什么不提前告诉我到底该干什么事情呢?

产品开发流程分成6个阶段,每个阶段有若干步骤,每个步骤有若干任务,每个任务有若干活动,这一个又一个活动构成产品开发流程。所以为什么不把这些活动都按照规定做好?这些活动做好,这些评审不就成走形式了吗?

所以我们说:“要想评审不走形式,就把评审会变成形式!”

很多公司把产品开发流程搞出来也不执行,特别是研发人员不想做,表现出来是有流程文件但不执行。为什么呢?这需要被强制!

所以凡是公司形成流程和规定的就是要强制执行的。

要明确:做不做是态度问题,做得好不好是能力问题。

为什么需要强制呢?流程里的活动是前人的经验教训,根据我们的经验:大部分人对前人的教训是熟视无睹的!

假设老王的老家在北京,过年计划开车回家,从深圳出发,走京港澳高速到北京。老王开车上了京港澳高速,就在深圳关高速入口处撞车了,右腿没有了。

老王纳闷:“这个深圳关怎么这么容易撞腿,而且特别容易撞右腿。”但是他这辈子没有机会再开车了,因为他的右腿已经没有了,所以他把希望寄托在儿子身上。

老王把儿子叫过来说:“儿子,深圳关这个地方特别容易撞右腿,你一定要注意。”他会听老王的吗?他才不听老王的!

但是老王也可以想办法让他听自己的,怎么办呢?例如,在老王弥留之际打电话给儿子:

“儿子,你在哪里?”

“在外地。”

“我估计我活不过今天晚上了,但是有个重要的事要跟你交代,电话里说不清楚,你必须赶回来,面对面跟你说。”

于是他儿子飞快地赶回家,他以为老王告诉他存折在哪里!然后他说:

“爹,你有什么重要的快告诉我呀!”

“儿子,你终于回来了,太好了,我告诉你深圳关那个地方特别容易撞右腿,你一定要注意!”

这个时候儿子才会听老王的。同样的一句话、同样的一个人,说的时间不一样、环境不一样,效果就是不一样的。

然后儿子跟老王说:“爹,你放心去吧,我一定记住深圳关这个地方特别容易撞右腿。”

老王放心地走了。

第二年,老王的儿子也开车回家,经过深圳关时,他小心了,就没撞腿。但到长沙时,他撞车了,右腿没有了。他就想:“我爹没来过这里,时代在进步、在变化,真正容易撞腿的是长沙。”

老王的儿子因为右腿没有了,所以也没法再开车了,只好把老王的孙子,也就是他儿子叫过来,也是在弥留之际跟他说:“你爷爷错了,你爹我是对的,其实容易撞右腿的是长沙这个地方,记住了没有?”

老王的孙子说:“记住了。”

后来老王的孙子就开车回家,经过深圳关没事,到长沙也没事,但到郑州把右腿撞没了……

通过这个故事,我想说的是什么呢?老王的儿子里面、老王的孙子(后代)里面,有没有可能在当年老王撞腿的深圳关撞腿呢?

完全有可能!

因为他不知道前人有过什么经验教训,即使知道也不在乎,所以说富不过三代!根本就不用三代,两代就会熟视无睹。

综上所述,前人经验教训形成的流程、规范和制度一定要强制执行!

8.开发指南

这个活动具体怎么操作?例如,开职工会议是一个活动,开职工会议怎么操作呢?我发现可能张三会开5分钟,李四会开2小时,你说谁开得好、谁开得不好?张三说5分钟已经够了,李四说2小时还没过瘾,你又没说到底开多久!同样是开职工会议这个活动,每个人的理解会不一样。

评审怎么操作呢?要有操作指导书。

有人问:“部门经理要不要参加技术评审会?”

我说:“你说女人要不要参加技术评审会呢?”

他又反问我:“女人跟技术评审会有什么关系呢?”

我就反问他:“你说部门经理跟评审会又有什么关系呢?”

部门经理跟技术评审会一点关系都没有,部门经理不仅跟技术评审会没关系,跟我们产品开发都没关系,跟我们产品开发中任何一个活动都没关系,因为他是养兵练兵的,根本不是带兵打仗的。

部门经理为什么会参加技术评审会呢?因为他碰巧是技术专家,他是以技术专家的角色参加的。有的部门经理根本不懂技术,参加技术评审会干什么呢?

所以,流程中要有角色分工。

还有评审最后能不能通过谁说了算等,这些都需要操作指导书来说明,否则会导致每个评审过程都不一样。

要不要制作一个需求列表?不少公司的评审就是几个人开会对需求做评审,最后发现环保需求漏掉了。为什么不做个需求列表呢?所有的产品需求评审全部打钩,环保需求、可服务需求、可安装性、可达性、可靠性等都罗列出来,每项评审要素建立ABC类基线,这样就不会漏掉了。

活动说明、操作指导书、活动清单、模板、表单等统称开发指南。

这个开发指南是谁搞出来的?

我们先来看看扁鹊的故事。

大家都知道扁鹊是个神医。

有一次扁鹊的领导跟他沟通,领导问他:“三啊”,为什么叫他“三”呢?因为他在家里排行老三。

“听说你大哥、二哥都是医生,你们三个谁的医术最高?”

“大哥医术最高,二哥次之,其实我医术是最臭的。”

“那你大哥、二哥不怎么出名,我们都知道你是神医。”

“因为我大哥医术太高了,他一般在病人病情没发作之前就把病治好了,所以我大哥医术最高,但只有我家里人知道。我二哥水平要差一点,在病情初起之时把病治好了,所以只有我们村里人知道。我不行,50公里以外有个人快要死了把我叫过去,我一看真的快死了,怎么办?搞工程呀!接骨头、放血,场面搞得无比宏大,其实治死了好多人,但有一次把一个人救活了,他们说我能起死回生,于是我就成了天下闻名的神医了。”

为什么讲这个故事呢?我想问读者你们公司有没有扁鹊?我们看一下什么叫扁鹊、什么叫扁大?

能在产品开发流程的第一个阶段把缺陷、问题、故障搞定的叫扁大;第二个阶段搞定的叫扁二;发货之后统称扁鹊;产品召回之后叫扁六。像看病一样,病症越早去看,花钱越少、治起来越容易,自己也好过,越拖自己越亏、越难受,病也越难治。

扁鹊治的是别人的病,研发治的是自己的病。为什么?

很多公司没有深度理解研发体系,就去拍脑袋搞绩效管理,最后把扁大考走了,有没有可能?

完全有可能。

真正水平高的人做的东西不坏。如果我们做的产品都像都江堰一样两千年都不用修多好呀!

在很多公司,真有这样的人,但是被公司忘记了。因为没有深度理解研发管理体系的人拍脑袋制定的绩效管理体系可能就提拔了制造事端并平息事端的人!

而且救火很有成就感,导致很多开发人员会陶醉在忙碌的救火状态中,喜欢挽起袖子解决问题(其实是自己水平低弄出的问题),更打击了真正在前期把方案、计划做好的人,他们一次把工作做好,最后被遗忘,甚至被抛弃,黯然神伤地离职了,甚至跑到竞争对手那里了!

2.4.2 研发项目管理体系

研发项目管理体系类似于高速公路上的收费站、服务区、加油站和测速监控装置,是为了保证我们的产品能够在高速公路(产品开发流程)上平稳行驶,安全到达终点,所以公司每个项目开发的时候均有项目的启动、计划的制订、执行、监控及项目的收尾,同时需要把项目的质量管理、风险管理、沟通管理、成本管理等贯穿项目始终。研发项目管理体系包括核心过程和支撑过程,如图2.6所示。

图2.6 研发项目管理体系

因为有太多项目管理的书籍可以供我们参考,所以研发项目的特点在这里只做简单介绍。

1)项目管理是通过计划来驱动开发流程的。做计划,业界用得比较多的有两种方法:PERT图和GANTT图。PERT图直观但很难懂,不少项目经理花很多时间来研究如何使用PERT图。实际上这是没有必要的,因为PERT图适合物理流项目,如工程项目。研发项目是信息流项目,不适合用PERT图,我们调研过至少5000家科研机构和高科技企业,用PERT图做开发计划的还不到10家,而且效果不好。因此GANTT图是适合的、实用的。

2)单项目管理并不复杂,甚至多项目管理也不复杂,项目之间有关联的多项目管理才是麻烦!有关研发多项目管理的书籍和参考资料并不多,市面上有一些书籍和课程,基本都是基于没有太多关联的多个项目来讲的。但研发多项目管理都是有关联的。关联主要体现在事和人的关联。

事的关联,如A项目中某个任务必须依赖于B项目的某个任务的完成。这种关联越多,管理越复杂。项目之间是否有事的关联,各行业差异很大。

但真正给绩效管理带来麻烦的是人的关联:一个人同时参与多个项目。人的关联在任何竞争行业的研发中几乎都是存在的。垄断行业如果不考虑成本,可以一个人只做一个项目,但要考虑人力资源成本,就必须一个人同时参与多个项目,竞争行业更不用说。

举个制药行业的例子,小王参与了一个项目,任务是把几种配方弄好,做个化学反应,这个反应时间有点长,假设需要5天。那么这反应中的5天,小王如果只有这一个项目的话,他就是闲着的。这就是人力资源的浪费。举个电子行业的例子,小王画了个原理图,出去投板了,要10天才回来,那这10天小王也是闲着的。举个机械行业的例子,小王画了个原理图,出去开模了,要10天才回来,那这10天小王也是闲着的。举个芯片行业的例子,小王画了个原理图,出去流片了,要10天才回来,那这10天小王也是闲着的。举个软件行业的例子,小王负责的模块做测试了,要3天才完成,那这3天小王也是闲着的。所以研发的工作量和工期不是线性的。

出于研发人力资源成本的考虑,公司不会让小王闲着,于是小王就做其他项目的事情了,也就是说,小王至少同时做两个项目。这样,兼职就产生了,兼职也是必然的。

你可以通过产品规划把项目错开,但研发业务的性质导致了研发人员兼职多个同时进行的项目是必然的,这给管理带来了麻烦。一个人至少有两个直接领导,考核谁说了算?两个领导意见不一致怎么办?

如果一家公司多个研发项目人和事同时都关联,那就更麻烦了,麻烦到好多公司根本都不去理到底有多少关联了,就乱着吧!所以几乎没几个公司的开发计划是按时完成的。

但要做研发绩效管理就必须面对这个麻烦,并梳理清楚,否则,硬做绩效管理就会把矛盾激化,把原来混乱的事情发展成混乱的人际关系!于是公司政治产生了。可怕的是很多公司并没意识到问题的根源,还以为是绩效管理没做好!更可怕的是很多公司的中基层善于学习,把问题根源搞清楚了,高层却没搞清楚,还以为中基层找借口不想做绩效管理!

研发项目管理一定要实现端到端的全流程管理,如图2.7所示,从项目启动开始,以项目的计划为轴线,将项目的问题、风险、需求、缺陷、评审、设计、审计、变更等贯穿其中,通过加强对研发项目的过程监控,形成公司的过程资产库。

图2.7 端到端全生命周期的研发项目管理

2.4.3 研发绩效管理体系

研发绩效管理体系用来衡量最后我们的车有没有成功地达到终点,是否满足当初规定的项目的进度、质量、成本等绩效指标的要求。达到绩效目标之后需要给研发人员合理的价值回报,以激励研发人员创造更大的价值。

研发绩效管理是一个PDCA循环,如图2.8所示。

图2.8 研发绩效管理的PDCA循环

产品开发流程和研发项目管理的结果的输出是研发绩效管理结果的输入,如果没有这两个基础,研发绩效的很多KPI是没法收集和量化的,没有度量,如何考核?如何评价?所以大量公司的中高层只关心绩效的结果,不关心产品开发流程和研发项目管理这两个基石,是很难解决研发绩效管理问题的。

2.4.4 IT固化

有了良好的产品开发流程、研发项目管理和研发绩效管理体系后,如何保证能够在公司里固化和实施,而不会因为某名员工的离职影响到整体的业务运作,就需要IT系统(信息系统),研发IT系统需要解决的问题如图2.9所示。

图2.9 研发IT系统需要解决的问题

关于研发的 IT 管理在后面的章节中会专门讲解,因为流程、项目和绩效最终还是要靠IT手段落实,没有IT来固化,最终还是浮云,很快就会恢复原状。没有 IT 工具,绩效管理的数据收集不准确,而且成本高,最终会导致绩效管理这项工作不能持续,做一段时间就半途而废了。

不少公司既做产品开发,还做技术开发,甚至还做预研,所以开发流程还要做更细的分类。 DTGvvQXCfGeTwtocODJ02yS1Y1Ie4vqQ1spaezoI4kT8DZypcvv9zFPfqAEuhWXm

点击中间区域
呼出菜单
上一章
目录
下一章
×