如何做好研发管理

关于如何做好研发管理的思考,以下部分内容摘自网络。

一、研发管理的目标

如果说研发管理的目标是提高效能,那么首先同步研发团队朝着统一的目标,就是效能管理最重要的第一步。

二、研发管理的常见问题

如何做好研发管理_第1张图片

1、难以KPI化和考核

任正非有句名言:钱分好了,管理的大部分问题就解决了。我对此深表同意,可问题是,怎么能分好钱确实非常考验能力、经验和智力的。研发之难,恰恰难在无法KPI化工作本身,所有那些试图KPI化工程师和码农的做法,最终结果都啼笑皆非、面目可憎、吃力不讨好。在我过去经历,还有客户实际的研发管理里,试图KPI化研发工作一直是不同团队努力的尝试,包括和不限于以下方式:

  • 解决Bug数
  • SLA
  • 功能完成度
  • 加班,007就比996牛逼,996就比955更值得奖励
  • 营收捆绑
  • NPS

这些看起来可以数字化的指标,除了证明研发管理者通过偷懒的方式做绩效考核外,可以说毫无价值,也无法给公司和组织带来正向的激励。

2、离代码很近,离用户很远

另外一个现实且无奈的问题是,工程师和产品经理好像是在象牙塔里做产品和研发,和用户往往离得太远太远。这种问题带来的伤害可能远比其他事情来得更加彻底,但本质上这是研发规则上没有解决好的问题,导致工程师本身并没有任何的目标和动力去贴近用户和客户场景。

我们常常说要做用户喜欢的产品,但那些反人类智商的产品,往往是产品经理和工程师合谋的结果。如果说研发管理的目标是提高效能,那么首先同步研发团队朝着统一的目标,就是效能管理最重要的第一步。

因此,以什么样的制度去驱动研发抬起头来看客户场景,是一切研发管理的核心工作之一。

3、跨部门战争频发

因为低头干活,所以往往研发团队的目标和业务团队的目标并不是一致的,研发体系和业务体系的跨部门战争,简直罄竹难书:

  • 业务认为,怎么这么多bug,一个小问题需要花这么久的时间才能修复
  • 而研发认为业务的智商不够用,这么好的产品就是无法准确传达给客户
  • 业务面对客户点头哈腰;而研发觉得客户是业务的客户,不是研发的客户
  • 业务对需求排期是12345;而研发对需求排期往往是54321
  • 业务给客户承诺就像谈恋爱,把星星摘下来也敢接着;研发认为你承诺的,你去写代码实现吧
  • 业务认为研发高工资吹着冷气,自己天天跑在外面晒太阳;研发认为,业务提成那么高,这产品是我做的,我咋没提成呢

这种剪不断、理还乱的关系,是很多公司的普遍现象。因为跨部门的不理解,必然带来团队之间的内耗,信息的折扣和效率低下自然产生。而更重要的影响是跨部门战争造成对客户服务与理解的偏差与推诿,没有任何公司或者团队能在一个不流畅的环境下成就对客户的100%满意度。

解决方案其实很简单,核心是构建一个开放、自学习、自驱动的组织文化和仪式感,这是打造高效研发团队最内核的基础。如下图:
如何做好研发管理_第2张图片

  • 左边是工具和方法,主要包括:以OKR驱动的目标管理,基于Scrum的敏捷,和逐步完善的DevOps。
  • 右边是制度和规则,核心包含:研发团队的绩效和考核、跨部门合作、其他仪式感驱动的各种规则,尤其是构建自学习的环境与分享机制。

三、我们当前存在的问题

  • 管理无规无矩:基本没有成文的规矩可言,比如代码仓库的管理、需求的管理、任务的管理、沟通机制等
    造成的影响:

  • 缺乏团队建设,无团队氛围可言
    造成的影响:互相之间比较生疏,一定程度上影响沟通协作

  • 沟通壁垒较深
    造成的影响:团队之间缺乏沟通交流,每个项目都只有各自的项目组了解项目做出了什么成果,是否可以在下一个项目中使用,当其他项目团队遇到类似问题时,就会产生重复造轮子问题。

  • 缺乏目标导向机制
    特别是在项目式的环境下,大家每日都沉浸在各种琐碎问题的处理当中,而不会抽离出去从全局视角去思考一些系统化的问题解决方案,导致大家虽然每天都很忙,但是实际产生的长期价值并不高,不利于公司的长远利益,也不利于个人的长远发展。

四、研发管理的方法论

绩效技术:为你解读神秘而时髦的OKR

首先,画一下我们通常讲研发项目管理的范畴:确定如何立项,如何确定产品目标,如何把控项目进度,如何驱动产品一代代完善以及如何调动团队积极性等。

在时间周期上来说,我们归纳为 5 个关键步骤:选方向、定目标、控进度、带团队和排干扰。相配套的,则是在这五个关键步骤的一些流程和工具的使用。

一、高效研发的5个关键步骤

第一步:立项——定方向

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

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

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

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

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

该项目对公司的利益点;如果不做该项目,哪些竞争对手会做,对竞争对手的利益点;

需要哪些技术的支持和驱动,哪些技术是公司的弱项;

人力需求;

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

发布策略;

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

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

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

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

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

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

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

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

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

为了更好的理解如何制定OKR体系,我们看个例子:

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

● 关键成果(Key Results):

日活跃用户量为XX;

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

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

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

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

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

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

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

数据系统:数据系统上面有全公司所有的产品数据和运营数据。数据能够用来验证产品的假设、方向等。

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

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

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

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

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

二、高效研发的流程和工具

过去几年做 Windows 版的时候,尝试过一个月、两个月、一个星期、两个星期的发布节奏,整个模式跟 Chrome 比较像,有功能发布就希望尽早的发。我们在服务端上每天都有更新,客户端会慢一点,现在大概是两周一个版本。

在开发节奏上,前两周的时间用于开发,然后截取分支准备发布,接下来两周进行测试,同时进行另一个开发,每一个迭代都控制在两周之内。相对而言,服务端的发布比较好操作,可以做很多的回归测试和自动化测试,不太需要手工的测试来做发布,但是 Windows 和 Android 都会有一些 Beta 的发布,在内部很难模拟用户的使用场景和用户的环境,所以在 release 之后的过程中一般会抽样 1%、5%、10% 这样一个节奏来做验证,主要是看某些指标是否达标。

这个流程刚开始执行的时候问题特别多。比如在这周开发完成以后,测试发现根本测试不了,有很多很多的 Bug,工程师只好利用第二个研发周期去修 Bug,然后又会影响第二周期的开发,这样问题越来越多,就会导致流程很难进行,然后进入恶性循环。为了解决这个问题,首先在操作层面上一开始先用一个月的迭代来让大家适应,同时要求 Master 分支必须是可用的(比如某人提交了代码跑不起来,或者没有经过测试,给其他同事带来了阻碍,就会被要求请全团队喝咖啡)。其次加强单元测试和回归测试,确保每个迭代的研发质量是可控的,后面的测试主要是回归和校验,减轻相互重叠的压力问题。一个月的迭代跑顺了之后,再跑到两周、一周的节奏,整体来看,差不多用了半年的时间,就完全跑顺了这个流程,想快可以快,想慢也可以慢。

工欲善其事必先利其器,为了提升产品研发效率,可开发一款项目管理工具。作为内部的沟通工具,它主要用来做跨团队沟通,全公司所有员工都会使用。重要的 roadmaps 必须在这里登记,登记了以后,一个项目需要多少设计师、需要多少marketing、每个阶段是什么样以及工程师的发布状态都可以在这里看得到。

对于重要的发布,有三个最基本的要求:

第一要获得 Product/Design Review 的批准。一个功能开发以后,无论是界面还是整个 UI,如果会影响到用户的操作,或者影响到商户的收入,比如广告系统或者和合作伙伴的一些策略调整,这就需要做 Design Review。Design Review 大概是每周的周一、周三和周六,每次持续 1-2 个小时,包括Product(Review)、Design(Review)或Business(Review)。Product Design指的就是 PD,主要的视觉设计师或产品设计师必须全员参加。

第二要获得 EngineeringTech Review 的批准。这更接近于传统上的技术设计,主要是看某个功能在工程设计上是怎么做的。做这个设计的团队和所有工程师必须全员参加,也会有一个人来 host,还需要几个指标的 review。这个过程是帮助相关的工程师把设计考虑更全面,包括流量、游戏的带宽压力的需求等等。

第三要获得 MarketingReview 的批准。主要是看产品上需要如何引入 marketing 团队的配合,需不需要做一些传播,需不需要注意公关策略等等。

同时对于更小的一些 Beta 测试则不强制要求。这些 Review 实际上是帮助整个团队、整个公司去理解当前最重要是什么,其实也是建立一个高标准的过程。

五、如何解决我们当前的研发管理问题

  • 【计划】完善并坚定执行计划跟踪表,让参与的人明确知道自己任务的截止日期,以及整体时间安排。(坚定执行不代表计划不允许调整)
    当成员对一个项目信息有较高的可见性,并且也清楚自己以及其他成员在项目中所扮演的角色时,一方面可以培养成员的责任感,另一方面也有利于成员间相互“监督”任务进展。同时,团队内的所有人也都清楚大家都在忙什么,遇到问题的时候也知道应该向谁寻求帮助、汇报。

  • 【检查】每日晨会坚定执行,晨会能快速发现和解决问题,如果一个项目参与人数超过5人,建议一定要坚持晨会。

  • 【分享】举行定期或不定期的项目交流会,让每个项目团队能够了解其他项目团队的动态,遇到的困难,创造的成果等

  • 【沉淀】建立知识库,将各个项目的业务、技术、问题都沉淀到知识库中。

  • 【培训】坚持培训与分享机制,培训可以让大家快速的掌握新的技术,分享可以让有能力的人有更多机会表达与展示自我。

  • 【提升】对于牛人给于一定的任务之外时间,技术牛人可以在这些额外的时间里进行系统优化、重构、代码审查等。




参考:
[1]. 研发管理和项目管理有哪些痛点?,https://www.zhihu.com/question/324062879
[2]. 一百人研发团队的难题:研发管理、绩效考核、组织文化和OKR,https://36kr.com/p/1724012593153
[3]. 百人研发团队的难题:研发管理、绩效考核、组织文化和OKR,https://blog.worktile.com/evo-dev-management/?utm_source=zhihu&utm_medium=answer&utm_term=324062879&utm_content=devmanagement&utm_campaign=meiyang

你可能感兴趣的:(管理,程序人生)