研发管理

什么是研发管理?

研发管理就是在研发体系结构设计的基础之上,借助信息平台对研发进行的团队建设、流程设计、绩效管理、风险管理、成本管理、项目管理和知识管理等活动。

研发管理首先要确定研发体系结构,然后按照体系结构组建高水平研发团队,设计合理高效的研发流程,借助合适的研发信息平台支持研发团队高效工作,用绩效管理调动研发团队的积极性,用风险管理控制研发风险,用成本管理使研发在成本预算范围内完成研发工作,用项目管理确保研发项目的顺利进行,而知识管理让研发团队的智慧联网和知识沉淀。

如何进行高效研发管理

第一步:立项——定方向

在豌豆荚的整个研发过程中,立项称为Product Brief或者Project Brief。团队的产品经理会撰写一个1-2页的文档,然后和执行团队进行评审,如果评审通过,立项就成功了。文档一般包含会包含以下内容:

1. 愿景:一句话表达清楚要做什么;

2. 分析市场机会和趋势,决定当前策略;

3. 确定目标用户的特征和核心需求;

4. 现存的解决方案和各自的优劣势;

5. 该项目对豌豆荚的利益点;如果不做该项目,哪些竞争对手会做,对竞争对手的利益点;

6. 需要哪些技术的支持和驱动,哪些技术是豌豆荚的弱项;

7. 人力需求;

8. 项目的紧急程度,是否需要快速推进;

9. 发布策略;

10. 核心衡量指标,用来衡量成功的指标。

第二步,OKR 体系——定目标

对一个项目来说,设定目标是非常重要的,因为这决定了如何去做,以及能做到何种程度。豌豆荚采纳的目标管理是从 Google 引进的 OKR 体系(Objectives & Key Results,目标与关键成果),这跟传统的 KPI(Key Performance Indicator,关键绩效考核)稍微有些区别:

1. OKR 首先是沟通工具:豌豆荚共有 300 多人,每个人都要写 OKR。为了便于沟通,所有这些OKR都会放在一个文档里。任何员工都可以看到 CEO 的这个季度最重要的目标是什么,HR 团队这个季度的目标是什么。

2. OKR是努力的方向和目标:OKR代表你到底要去哪里,而不是你要去的地方具体在哪里。

3. OKR必须可量化。比如健身时设定锻炼目标,如果只是定义成「我们要努力提高身体素质」,肯定不是一个好的 OKR,因为无法衡量,好的OKR是「今年的跑步时间较去年增加一倍」。

4. 目标必须一致:制定者和执行者目标一致、团队和个人的目标一致。首先,制定公司的OKR;其次,每个团队定自己的 OKR;第三,每个工程师或设计师写各自的OKR。这三步各自独立完成,然后对照协调这三者的OKR。在豌豆荚,OKR跟个人绩效没有关系,因为OKR 系统的结果和每个人并不直接挂钩。

5. 通过月度会议Review ,时时跟进OKR: 在月度会议上需要确定如何去达到目标,是一个帮助达到目标的过程。

6. 通过季度会议 Review ,及时调整OKR:互联网的变化非常快,所以豌豆荚每季度有一个OKR 的 review,调整的原则是目标(Objectives)不变,只允许调整关键成果(Key Results)。

为了更好的理解如何制定OKR体系,豌豆荚提供了以下实例:

● 目标(Objectives):发布有影响力的新功能,将 XXX 产品做成用户可以每日使用的产品。

● 关键成果(Key Results):

○ 日活跃用户量为XX;

○ 使用XX方式,提高XXX核心指标;

第三步,项目管理——控进度:

目标设定以后,非常重要的就是执行,一般的项目管理实际上就是控制进度。

1. 任务/进度勤同步。整个公司所有人的 calender,包括会议、要做的事情、项目的时间节点都需要及时同步。在整个战略布局上,如果某个项目工期非常紧,就必须进行更多的沟通,确保每一个环节都没有问题。

2. 站立会议 (Daily Sync):每天进行站立会议,一般控制在十分钟之内,每个人说明自己今天要做的工作,需要什么帮助,有谁可以帮忙,可以更有效的调节资源和攻关。

3. 多方位沟通(Google Docs / Gmail / Hangouts):对非紧急的事情,两个团队或者是两个人一起讨论所有的设计。Hangouts用于做快速响应。

4. 周会(Weekly Report):每周总结。豌豆荚的团队产品经理要做周报,汇报这周的工作、发布、取得效果以及数据。

5. 数据系统:MUCE 是豌豆荚的数据系统,上面有全公司所有的产品数据和运营数据。MUCE 的数据能够用来验证产品的假设、方向等。

第四步,人员管理——带团队

项目是由一个个具体的人来执行的,所以带团队非常重要,在人员管理上,豌豆荚有三个基本原则:

1、Re-Organization & 换组:公司鼓励员工换组,每个人都有机会到喜爱的团队做更有趣的事情。只要在原团队的绩效合格,每季度都可申请换团队或换工作内容。员工的绩效不与 OKR挂钩,公司鼓励员工挑战难度、超越优秀,低 Level 的事情做不到优秀会被惩罚,做事不及格也会被惩罚。

2、One on One:在带人方面, One on One 非常重要。One on One 指的是每个团队的manager 需要定期(最佳间隔是每周一次)与自己团队中的每个成员进行一对一讨论或者对话。在豌豆荚,manager 首先是一个教练,应该帮助自己团队的成员成长。通过 One on One,manager 需要了解每个团队成员现阶段的状态和遭遇的困扰,分享职业规划,帮助他们正确地处理问题,更好地实现个人成长。

3、个人 OKR 和 Performance 体系:每个员工在每个季度初需要确定自己本季度的 OKR,在一个季度结束后需要根据自己这个季度的工作完成情况给 OKR 打分。每半年公司会进行一次Performance Review,主要是 review 员工过去半年的绩效,并根据 Performance Review 的结果变更 Job Ladder(业务职级)和薪酬。值得一提的是,在豌豆荚,所有的个人Performance Review 的成就内容及级别都是全公司共享公开的,如下图所示。这个对于很多公司来说是不可想象的,豌豆荚为什么要这么做?因为一方面对于豌豆荚来说可以做到更为公平和透明,另一方面也给每位豌豆提供了更好学习和成长自己的样本,激励大家在产品研发中更高质量的挑战和要求自己。

第五步,兴趣管理——排干扰

1、激发兴趣:Hack Day,是豌豆荚一个特殊的节日,开始于2010年,类似黑客马拉松。通常在春节假期回来的那一周,产品设计师和工程师们 3-5 人组成一队,在连续48小时的时间里,充分展现工程团队的创意和想像力,完成一些比日常开发更 geek、更有趣的东西。

豌豆荚为了鼓励大家更好的完成挑战,也会设计一些特别有特色的奖品,历史上 2012 年提供的是苹果刚出 Macbook Retina,2013 年是 Google Glass,2014 年则是程序员最爱的Herman Miller 顶级座椅。

在历史的 Hackday 中,有不少作品最终都成了重要产品对外发布,比如 MUCE、豌豆洗白白和 IAS(应用内搜索),都成为了豌豆荚极具特色的产品。

2、控制兴趣:Polish Week,让公司慢下来,对已有产品的细节进行精细化的过程。在大量开发和新产品上线的过程中,我们会担心因为走得太快而对产品的细节关注不够。在连续3个工作周后,第4周通常是 Polish Week。在 Polish Week 的这一周,豌豆荚内部不会进行新产品或新功能的开发,而主要是对现有的产品和服务进行打磨,解决一些细节问题和小 bug,譬如产品内一些字体的统一等等。平均每个 Polish Week 会解决产品中各种 Bug 大约 200 个。

研发管理误区

研发管理是研发部门的事情

现象:认为单纯从字面上理解研发管理只是单独涉及研发部门的组织运作与流程改进的问题,与其他部门无关,因此应由研发部门自行组织讨论与改善研发管理问题。

对策:研发管理的变革是企业战略的问题,而涉及战略问题的改善方法一般采取“自上而下”法,因为研发部门不同于企业的其他职能部门,它的走向与企业的发展战略紧密相关,是企业的战略核心组织。转变战略核心组织一定会经历企业文化的巨变。所以稳定的领导层以及领导层的积极参与、支持是非常重要的。可以说,没有领导层的支持与鼓励,研发管理变革是不可能取得成功的!

IPD是研发管理的唯一选择

现象:IPD-IntegratedProductDevelopment(集成产品开发)作为一套先进的研发思想和研发管理体系,正日渐被国内企业所接受。

然而,不少企业由于受到国内成功企业的研发管理变革历程的影响,将提升研发管理效用等同于研发流程改进,IPD于是成了唯一的解决途径。实践证明,这种误导将会在不同程度上将企业研发管理变革引入他途,仅仅聚焦于流程改进的IPD体系使相当多的企业没有达到预期的效果。对于众多的中国企业来说,研发管理中存在的许多问题都不是IPD流程体系所能解决的。

对策:在决策过程中,首先应是改善有关研发战略规划和研发战略具体化的过程;而在实际操作过程中,更多的重复工作不是由于缺少一个流程,而是在快速多变的环境中,管理层和操作层缺少必要的指导性规范,以至出现了大量的重复劳动。因此,只着眼流程改善无法达到提升整体效用的目的。

再者,企业选择什么研发体系完全取决于企业处于什么发展阶段和内外环境,一般从原始的粗狂作坊式到基本的PM管理,有了PM管理的基础实施多项目管理的IPM集成项目管理,在多项目管理基础上实施《产品生命周期的优PACE》则是平衡产品管理为市场化的流程体系打好基础,有了这些基础才能考虑全面基于市场化的IPD研发管理模式(IPD不仅仅是一个流程体系,它是集市场管理、流程和产品重整三大功能为一体的体系),有了IPD的实践与优化的基础则可上升到SGS阶段门的研发管理体系(注重过程与关键点决策评审的质量方法),有了以上各大体系的积累和修炼过程,则可上升到PVM价值工程的研发体系,它要求我们做的任何研发管理相关内容都要站在价值提供的高度来要求我们的各项管理活动。如果企业没有根据我归纳的研发体系引入前提,则将使我们打造企业长久核心竞争力的愿望要么拉长周期要么中途死亡,要么不上不下研发体系成“鸡肋爱情”。

另外,我上面提及的研发“过程阶段论”还需要配合研发创新“变革阶段论”方可实行“无缝对接”,既充分考虑企业研发创新的体现形式要做提炼,比如企业是处在“OEM、ODM、OBM、OSM”哪个研发创新“变革阶段论”。

我们是传统行业不需要研发管理

现象:以知识经济时代为特征的高科技企业,技术创新被视为创造策略性竞争优势的重要手段,研发管理也被纳入企业整体组织的策略构架中。面对技术环境快速变化的科技企业,也在苦苦探索获得具有持久竞争优势的研发管理途径。高科技行业是这样,但不少传统行业的管理者们认为高科技的研发体系对传统行业没有用处,行业不同难以借鉴。在中国企业探索研发管理改善的渴望面前,不少管理者认为传统企业不需要研发管理咨询,这其实是在不同程度上将企业管理改善的良好动机引入歧途。

对策:作者肖伟亚做过一个“行业对比研究”。根据研发管理特征将整个行业环境划分为高科技、工业品行和传统三大行业,经分析不管是什么行业,围绕如何获得企业核心竞争优势这个目标则是共同的,不管哪种企业优势都需要以产品设计研发为落地(否则就像再好的品牌策划都是空洞无物,笔者亲眼所见一朋友企业花了150万做完品牌策划却发现没有产品来落地,结果不出几月就倒闭了)。三大行业的本质区别是高科技以技术创新为核心,传统行业以设计创新为核心,工业品兼顾设计创新和技术创新(如果工业品涉足智能化产品的),在企业处于行业发展成熟期竞争激烈之时,不同行业的“它山之石可以攻玉”之方法则是企业获得突破“从优秀到卓越”之良机。

 

研发管理变革应立竿见影

现象:随着我国市场的进一步开放,许多企业日益认识到核心技术对企业生存的重要性,研发部门受到前所未有的重视。加强研发管理,提高研发团队效率也成为企业的工作重点之一。然而,许多企业在进行研发管理变革的过程中存在急燥冒进的问题。他们认为,只要实行了先进的研发管理措施,就应该使企业的研发水平达到一个新的高度。如果在短期内看不到明显成效,他们就认为是研发管理变革本身的错误。

对策:实际上,研发管理变革受多种因素的影响,如企业原有的组织结构、相关部门的配合程度等。因此,研发管理变革成效的显现应该有一个过程(有个滞后期),该过程的长短与企业的内外部环境相关。希望在短期内改善所有问题的想法是不切实际的,如果在项目团队组建之时不将相关职能人员纳入项目组利益范围,极有可能导致变革的失败。

效率要高才有意义

现象:对中国企业而言,最难的是急功近利,恨不得今天投入,明天就要看到成效,这样的心态对技术管理而言是最致命的,不了解任何管理方案的效果都有一个滞后期。

(1)现实情况是IPD正日渐被国内企业所排斥;

(2)IPD等研发管理模式本身没有错,主要是推行的人如咨询公司“经济导向”误导的缘故;

(3)产品研发很多也是模仿、抄袭的,不愿花成本去创新;

(4)研发流程包括研发战略、组织和人力资源等,也是项目管理的执行依据,研发流程不是“流程图”或流程文件,是多维体系;

(5)研发是公司范围的,简单说前端接市场营销后端接供应链体系,中间需要靠资源来实现。

对策:任何体系都是一个根据环境和发展需求所完善的,特别是不同的企业有不同企业的国情,IPD本身就是从IBM引入到华为后形成的中国特色的研发体系,可以说它就是根据中国的国情量身定制的一点都不为过,主要看我们的企业如果引入还是要看我提到到“体系引入阶段论”。

 

IPD是CMMI的组成部分

现象:许多企业的研发人员常常混淆IPD与CMMI,认为由于CMMI是在CMM(软件成熟度模型)的基础上增加了集成的产品和过程开发等专业领域,不再局限于软件,因此CMMI比IPD范围更大,是包括IPD的。其实,由于起源和出发点的不同,这两者具有很大的区别。具体而言,首先是两者的对象不同。IPD是一种流程管理的模式。CMMI是面向研发的,而且更多是面向软件开发的;其次,核心思想不同。IPD的核心思想集中体现为6个方面,即产品开发是一项投资、基于市场的创新、跨部门的协同、异步开发、重用(CBB)、结构化。而CMMI主要着眼于通过过程来保证质量;再次,流程的结构不同。IPD建立一个涵盖了流程概览、阶段流程、子流程和模板的分层结构框架,对涉及到的产品开发活动进行合理的结构化。CMMI是相对离散地来定义流程的。最后,人员管理不同。IPD包括了对团队和个人的考评,如对集成组合管理团队和产品开发团队的评估。CMMI则没有人员管理的内容。

对策:IPD可以基于不同类型的整个企业,而CMMI则只能基于软件开发的企业,更偏向于产品开发的质量管理。尽管CMMI其过程标准的思想可以借鉴,具体流程与进行活动管理所依据的原则、方法和实践是相通的和一致的,但企业在优化产品开发体系将两者融合时必须考虑到他们的差异性。

中小企业不需要研发管理

现象:中小企业的管理者常常认为,他们的企业从事研发工作的人员相对较少,没有必要引入IPD模式,进行研发管理。其实,IPD不是一套僵化的方法,它是一组思想、方法和工具的综合体。它对传统研发体系中存在的各种弊端都提出了较好的解决办法,系统性强但不僵化,复杂但不失灵活。IPD不仅适用于大型研发机构,而且可以根据企业规模和企业自身的特点进行灵活的裁剪,使之适合企业自身的需要。

对策:中小企业在引入IPD时只要坚持系统性原则,把握重点、由简入繁、由点到面的循序渐进,同时取得企业高层的支持,一样可以成功实施IPD。

 

认为根本就不需要

现象:认为自己企业不需要“系统研发管理”,感觉“原子弹”太先进不适合我的“拖拉机”,上马成本投入和风险又太大。

对策:在行业和整个国家在向“ODM”转型的环境下你不做你的竞争对手会学会做。很容易失去将来的竞争优势!单一从上述八大认识误区去逐一解决这些问题也不是根本的解决之路,要从“研发系统体系”的思想框架去树立和武装我们的头脑,建立的就是同一频段信息平台。