标签归档:团队管理

management

技术管理者的 4 个基本思考点

技术团队管理者在日常工作中可能经常会遇到如下一些状况:

  1. 自测质量差
  2. 转测 BUG 多
  3. 项目延期
  4. 加班赶工
  5. 高强度加班后,小伙伴状态不好,导致更多的问题出现

从第 1 点状况演变成第 5 种状况,第 5 点状况继续推动第 1 种状态的持续加强,从而导致整个团队的状态极差,陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期 的死循环。

除了上面的死循环,可能还会有一些非功能性的问题,如性能、扩展性问题等等。

当团队大时,还可能遇到有小团队,各小团队各行其事,各为其主,心不往一处,力不出一孔。 这些问题让技术团队的管理者焦头烂额。

那么如何解决这些问题呢?个人认为可以从以下 4 个方面来逐一思考和优化,从而在一定程度上解决这些问题。

1. 把正确的人放到合适的岗位

所有的执行最终都是落到人身上,有了正确的人,事情会事半功倍。 说到人,我们往往会提起人的「选用育留」,这是一个很大的题目,我们不做详细的讲述,只关注选和用的一小部分。

管理上有一个在大部分场景适用的套路:选拔优先于培养。 这个套路背后有两层逻辑:

  1. 改变一个人太难,比如有些人就是懒,抽一鞭子动一下;又或者家境优渥,态度佛系,无欲无求,根本就是油盐不进;又或者玻璃心,安全感差,都很难搞;
  2. 成本太高,即使这个人具备可培养性,但从 0 到 1 把一个人培养起来,时间成本太高,而管理者的时间很贵,公司等不起。

所以我们这里是选人,从现有的人中找到合适的,从人才市场找到合适的,能直接用的。

本小节主要是回答两个问题:

  1. 正确的人是怎样的?
  2. 如何把正确的人放到合适的岗位上?

1.1 选人

在人的层面,主要包括两个部分,执行者和管理者,这里管理者包括整个团队负责人自己。 不同的部分,要求不同,选人的标准也不同。去掉专业技能部分,去掉历史经验部分,我们希望我们的伙伴是这样的:

  • 喜欢和投入:对于技术热爱,对工作有投入度,能够专注于自己手上的工作,找到成就感;
  • 知道自己想要什么:有一定长远的规划,知道自己走在什么样的路上,不限于一时一城之得失;
  • 一路人:认同企业的价值观,价值观认同其本质上是「人以群分」;
  • 宁缺毋滥:如果实在没有人,宁缺毋滥吗?这是一个好问题,严格来说是这样的,但实际中往往我们会妥协一部分。

我们选人一个常见的问题是注重人当下的表现和历史的成绩,然而我们选人是要解决未来的问题,更要关注其潜力。 那么如何看一个人的潜力呢?如果具备以下的特性,大概率是一个有潜力的人:

  1. 有意愿,什么叫有意愿,就是指一个人想变好,有内在的动机去追求更高的目标;这里扩大一些,还包含积极的态度、好奇心和进取心;
  2. 有静气,特别是遇大事时有静气,临危不乱;遇到繁琐的事情能一步一步慢慢做好;
  3. 有度,做事有度,知道做事的边界在哪,进展有度,但是并不是事事划边界,事事划边界显得格局太小,多数事情还是从大局着眼;
  4. 能扛事,遇到事情找方法,不找借口,执行力强;
  5. 有所为,天赋决定了能达到的上限,努力程度决定了能达到的下限。努力去做,有所为,并且 以现在绝大多数人的努力程度之低,还远远没有达到比拼天赋的程度。 这里的有所为不仅仅是做事,更多的是学习,不停地学习,提升自己。

1.2 用人

1.2.2 人才梯队

人才梯队从时间上看分为现在和将来。 现在是指盘点现有人才情况,梳理人才结构,对团队中的人进行分层,形成「梯状」。

当前状态的人才梯队分为两个层面,一个是分层,另一个是分层后的职责。 当团队大一些后,需要明确团队的组织分层,这里可能是正式认命的 Leader,也可能是虚拟的负责人,不管是实的还是虚的,最终都会有一个层存在。

分层本质上是一个分饼的行为,什么样的人拥有什么样的资源,承担什么样的责任,行使什么样的权利。

作为一个研发团队的负责人,需要梳理这些层,确定是否有合适的人,这些层的负责人形成了我们所说的「人才梯队」。

德鲁克曾说:「一个组织应该使每个人,特别是每个管理人员和每个专业人员(但也包括每个管理单位)都理解自身的任务」。 在我们做分层的过程中,需要关注每一层的职责和其解决的问题,如我们在软件架构设计的时候一样,每一个分层都有其作用,无用的分层只会增加性能的损耗。

对于将来,未雨绸缪。

当现在的人才正在发挥作用时,培养接班人,我们经常称之为 B 角。当有人才变动时可以快速补位上去。常用的方法有内部培养,跨团队轮岗,外部招聘等。

这块特别狠的可能要算宇宙厂了,在现有人员已经能满足工作需要的同时,会继续招聘,如果更优,可能会换人。

1.2.2 艰难的决定

在我们构建人才梯队的时候,想要做到知人善任是一件很难的事情,并且让每个人的表现都达到预期水平更难。当有些人并不能胜任他当前的工作时,我们应该怎么做?这里可能有以下两种常见的方式:

  1. 调岗,一般这种情况可能只是人岗不匹配,或者有些变化跟不上,但是对于人的部分能力还是比较认可。此时我们在公司内给他找一个匹配的岗位,更好地发挥其潜力。在技术团队最常见的例子是有些高 P 的技术同学,被推到管理岗,过了一段时间,发现适应不了,此时我们可以将其调到更能发挥其能力的岗位上来。又或者一些管理者因为团队扩大或者一些其它原因,管理的范围一下子增加了很多,一段时间后发现无法搞定这样的团队,此时可能将其调整到稍微低一级的职位上更合适一些。
  2. 离开,尽量让对方体面的离开,公司和个人都体面的分手,该赔偿的赔偿,该理解的理解,如果在外面有合适的机会,顺手推一把,也是个不错的善缘,不枉同事一场。这里经常出现的问题是犹豫不决,最终导致大家都不开心,不欢而散。管理上常说:「心要慈,刀要快」,就是要规避这种犹豫。

1.3 管理者自己

在用人中还包括管理者自己,一个技术管理者,不仅仅要注重技术,不仅仅要设定明确的目标并排出优先顺序,跟进过程发现问题解决问题,拿到结果,还要注意另一个重要的点:业务参与者。

一个优秀的管理者和一个不那么优秀的管理者的主要差别就是他们对业务的参与程度。事实证明,对所负责业务参与的程度越深,你就越能做出更加明智的决策。

什么叫业务参与度?

我认为它不是事无巨细地了解进展,应该到一线去,怎么到一线去,去写代码,去做代码评审?

到一线去,有两个层次,一个是业务的一线,用户或产品,看用户的反馈,产品的实现,二是工作的一线,看工作流程的卡点,系统化的情况,可视化的情况。不要自己去做这些事情,主要是收集信息,决策或者发现问题解决问题,这里确定做什么的原则是: 你做的事情的价值大小,而价值大小可以从时间杠杆,团队杠杆上来指数级扩大,如果做一件事只有短期的一件事的价值,那这些事情就不是你应该做的,应该停下来去思考要做的事情。

2. 组织

说到组织,你是想要一个「令行禁止,使命必达」的组织,还是一个「简单可依赖」的组织?

组织是为实现共同目标而采取的一种分工协作体系,是人与人之间的关系,组织结构往往会随着组织的重大战略调整而调整。

而企业在商场中求生,随着外部环境的变化,行业的变化,内部环境的演进而会不断进行迭代,不断调整组织结构,因此我们经常需要重新设计组织结构。

2.1 设计组织结构

我们在设计组织结构的时候通常要思考以下五个问题:

  1. 组织的目标是什么?因为组织是为了共同目标而存在的人与人的关系,目标不清楚,组织结构肯定也是不清楚的。
  2. 组织由哪些层,哪些单位组成?组织是一个体系,由不同的单元组成,需要明确各层或单元分别是什么,职责是什么,其作为一个子结构需要有自己的目标和使命。
  3. 组织各部分的规模和形式应该是怎样的?根据现实的情况,在设计组织结构时需要着重考虑规模和形式,多少层级?流程型?考虑管理者的有效管理幅度。
  4. 组织的哪些部分应该结合在一起,哪些部分应该分开?
  5. 组织内各单元之间的关系和协同应该是怎样的?

设计组织结构最难的问题可能是分和合的问题,这里有一个原则: 凡是做出同样的贡献的活动可以结合在一个部门中统一管理,不论它们的技术专业是什么。那些不是做出同样贡献的活动则一般不应合在一起。

在考虑组织结构,特别是研发团队的组织结构的时候,千万不可忽略了康威定律,甚至我们有时需要「逆康威定律」,通过适配康威定律,在明确技术架构方向的基础上,以组织结构的调整来推动技术架构的演进。

2.2 组织的形态

每家企业都有自己的文化和组织形式,抽象出来大致可以分为权力型,流程型和交易型,落到研发团队内部,一般只有前两种。

现在许多人强调去中心化、去科层化、去权力化,实际上,在大多数情形下,权力连接还是最直接、最简单、最有效的机制。权力组织讲究的是执行。

组织中的权力主要有四种。除了决策权,还有建议权、审核权和知情权。

  • 决策权,对一个事情决定资源投在哪里,是不是可以做的权力;
  • 建议权是提出方案、预案的权力。注意,这是一种权力:建议权拥有者如果未提出建议,上级决策者不能替代或强压;
  • 审核权是对有关事项程序性、合规性的审查与核准。注意,这种权力不是对事项进行决策;只要有关事项符合程序、合乎标准和规范就予以通过放行。我们经常会看到一些企业的职能管理部门把审核权误当成了批准决定权,导致审批流程变长、决策效率降低,这是需要反思改进的。
  • 知情权是信息共享权,即获取信息的权力。

以上 4 个权限很容易让我们想到项目管理里面的 RACI 矩阵:

  • 谁负责:(R = Responsible),即负责执行任务的角色,他/她具体负责操控项目、解决问题。
  • 谁批准:(A = Accountable,决策权),即对任务负全责的角色,只有经他/她同意或签署之后,项目才能得以进行,是整个事情的决策者;
  • 咨询谁:(C = Consulted,建议权),拥有完成项目所需的信息或能力的人员,多提出建议。
  • 通知谁: (I =Informed,知情权),即应及时被通知结果的人员,却不必向他/她咨询、征求意见。

以上四种权力,决策权和建议权是权力主线,审核权和知情权是权力副线。主线是上下级逻辑,副线是平级或流程型逻辑,而我们往往理解的权力是主线权力。

在强权力主线的基础上,权力型组织的有以下 3 个缺点:

  1. 唯上,组织内的成员对决定其资源或发展的上级负责;
  2. 组织的发展由上级决定,当上级缺位、能力不足或脱离实际时可能会出现瞎指挥,乱指挥的情况;
  3. 层级过多,导致执行和决策的效率低下。

为规避这些缺点我们需要减少层级,增加连接和协同。

如果把管理层只分为三级,我们一般称之为高层、中级和基层。这三个层要解决的问题不同。高层解决长期发展的问题,中层解决系统效率的问题,基层解决的是事情本身的问题。

比如技术管理者常规上可以分为三个大层:

  • 高层管理:解决长期发展的问题,使企业/团队有前途,关注的是未来,不管是技术发展的未来,还是业务发展的未来;
  • 中层管理:解决系统效率的问题,使系统更有效率,要不断强化研发流程的统一性和适应性,确定并执行好标准和规范,提升协同的效率,标准化和系统化,同时为上层的选择和决策提供依据和保障;
  • 基层管理:解决事情本身的问题,而事情往往会落到一线的开发同学身上,于是经常我们基层管理者的主要工作是使一线开发同学工作有成就,培养一线开发同学,提高他们承担工作的能力和意愿,帮助他们解决问题。

我们期望是每个层能做好自己的事情,但是实际上往往是高层在做中层的事情,中层在做基层的事,基层在做一线的事情,错位了。于是,我们需要将管理层归位,各行其职,更专业的做事情。

在明确职责的基础上,尽量减少管理的层级,尽量不要出现 「副XX」 的岗位。

在协同方面我们用流程来解决协同合作的问题。流程本身的逻辑是对事情负责,对自身的任务及向下事项/环节负责。其驱动力是责任感和依赖。百度文化里面的「简单可依赖」能较好地说明流程的底层逻辑。当我们使用流程来解决协同的问题时,要经常迭代流程以优化协同的效率:

  • 注意流程是为了解决过程中的问题,不是为了设置卡点,每个人都有扩大自己权力的欲望,这是我们在流程建设中要特别注意的;
  • 尽量减少流程环节,聚合责任主体,我们经常遇到一个事情在某职能部门还需要经过两三道审核的情况,这种损耗可以通过聚合责任主体的方式来解决;
  • 控制流程时长,这里控制流程时长还包括流程环节的前置准备,就和我们开会一样,如果开会前准备充分,会议本身的时长就有极大可能减少。

用权力解决「力出一孔」的问题,用流程解决协同合作的问题。

简单来说,在权力体系的基础上,用流程连接各环节和负责主体,现在比较常见的矩阵式组织结构基本符合这个逻辑。当然这里有一个以流程为主还是以权力为主的问题,具体是哪种,还得看公司当前组织结构的逻辑。

2.3 分工的粗和细

Adam Smith 在 1776 年的《国富论》中提出了分工,分工对于手工业生产效率有较大的提高,其总结了三个优点:

  • 熟练程度的增加,当一个人专注于一块工作,不停的练习极大的增加了熟练度,熟练度的增加将导致质量和产量的增加;
  • 当熟练后,人们对于重复的操作进行机械化或自动化,从而更大的提高质量和产量;
  • 分工明确了输入和输出,在明确的分工下,从一个工序转为另一个工序的时长减少了。

自从分工提出来了,产生了大量的争论,有人提出了以下的一些缺点:

  • 一叶障目,不见泰山,分工越细,所关注的东西都小,当人陷于某个事情越来越小的部分时,其大局观往往受限,可能会导致局部提升而全局受损的情况;
  • 分工越细意味着沟通协作成本的增加,当分工获得的收益小于沟通协作的收益时,将产生极大的成本浪费;
  • 分工一定关系到组织结构的分块,当沟通不畅或没有沟通时,有可能出现组织上的「孤岛」

分工落到一个研发团队,我们通常按编程语言分为 Java、PHP、C++、Javascript,或按端分为安卓端、iOS 端、前端、后端、算法、数据等,又或者大一点分为开发、测试、运维,架构师。

虽然「术业有专攻」,但多跨一步会让分工后的协同更高效一些,这里最常见的可能是测试左移和测试右移。

  • 测试左移是指在研发流程中,把测试的覆盖范围从传统的测试节点中释放出来,将其向左扩展,介入代码提测之前的部分,如开发阶段阶段,需求评审阶段,让研发人员在架构设计时就考虑产品的可测试性,并尽量进行开发自测,同时评估需求的质量,比如分析需求的合理性以及完整性等。
  • 测试右移是指把测试的覆盖范围从传统的测试环节中切出来,将其向右扩展,更多地融入代码部署、发布,甚至上线之后的步骤中。

更极端一些,走全栈路线,一个人从头到尾完成需求的所有工序。但是这种方式,对于人员素质的要求,对于团队组织的要求和常规不一样,且人的精力是有限的,能在每个方面都做到精通的,少之又少,除非所做的事情只需要略懂即可。

思考一下,你所在团队应该如何来做?

成本和效率?组织大小?技术发展?架构演进?

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

DRI 是 Directly Responsible Individual 的简称,中文翻译为「直接负责人」。最开始是从苹果流传出来的内部管理概念。

DRI 不是流程、过程,也不是框架,而是一个负责人,对某部分的整体负责,小到 BUG,大到技术方向。 DRI 是为了解决责任主体的问题,其有助于避免责任分散。责任分散这个概念也被称为「旁观者效应」,也就是人们身处团队中时无法对某事负起责任,责任分散到了团队中的每个成员身上,而不是集中在真正有责任的人身上,因为每个人认为那个责任应该由其他人承担,表现得像一个旁观者。

3.1.2 DRI 的职责

  • 聚焦目标;
  • 督促、监督团队成员完成自己的任务;
  • 清楚团队中发生的一切;
  • 统筹策划,搞定所有的干系人,从头到尾负责到底,说简单点就是团队成员专注的做好手上的事儿, DRI 排除干扰,解决各种烦人的问题来,发现问题,解决问题;
  • 有一定的领导责任。

简单来说,当你是某个事情的 DRI 后,这个事情就是你自己的事情。特别是当职责不清或者突发问题时,DRI 就需要发挥主人翁的精神,拉起团队成员去分析问题,解决问题。

3.1.3 什么人适合做 DRI

DRI 和工作年限无关,和是否资深无关,和技术工种无关,你想你就是。

但是在操作过程中,我们会根据实际的场景做一些偏重。如果是一个后台的活儿居多的项目,其 DRI 大概率是后台的开发同学,如果是一个质量问题较多的项目,其 DRI 大概率是一个 QA 同学。

这里我们会充分考虑同学的主观意愿,有些同学想,有些同学不愿意,只想做好手上的工作,那么他做好他手上工作的 DRI 就可以了。

DRI 无关项目大小,无关职位高低,无关所在层级,每一件大事,小事都需要有一个 DRI,且只有一个 DRI

这玩意儿换成中文其实就是我们在标语里面经常看到的「责任到人」差不多,但是更强调责任主体的唯一性。

3.2 构建良好的协同机制

公元前 221 年,秦始皇用了十年的时间,先后灭了韩、赵、魏、楚、燕、齐六国,完成了统一中国的大业。在以后,他陆续颁布了多条律法,以稳固国家的统治,包括「书同文」、「车同轨」、「度同制」等。

一个国家,一个组织,要想成为一个高效执行的团队,一定要有标准,一定要有人告诉大家怎样做是对的。 落到我们团队管理,标准,流程是必须要做的,特别是当你的团队是由若干个团队整合或融合的时候。

3.2.1 统一标准规范

当你的团队是由原来多个业务的团队融合而成,大家原来都有做一些标准,现在我们需要按统一的标准达成共识并推行下去。又或者本来标准不完善,需要系统梳理标准来达到标准的统一。

行业标准一般是为了互联互通,而对于研发团队的研发过程来说,标准主要是为了减少过程中的认知成本,提升研发的效率,比如数据库规范,大家按统一的规范来设计数据库,当有其它同学接手你负责模块的时候,能减少在基本结构的认知成本,以及在一些模块间整合或数据迁移时,对于工作会比较友好一些。

标准是什么,标准是一件行为准则,其关注的是结果。

标准和规范一般是为了告诉人们什么是好的,关注的结果,而统一标准是为了让大家互联互通。

标准不是为了成功,而是为了让整个事情不至于太坏,尽量不出现重大的问题。 具体到研发团队,我们一般需要统一如下一些标准:

  • 研发过程
    • 代码风格规范
    • 数据库设计规范
    • 代码分干管理规范
    • 代码提交规范
    • 错误码规范
    • Code Review 标准
    • 代码权限管理规范
  • 沟通协同
    • 架构规范
    • 技术方案规范
    • 文档规范
    • 接口规范
  • 质量标准
    • 代码质量标准
    • 自动化测试标准
    • 测试质量标准
    • 线上质量标准
  • 性能标准
    • 服务端性能标准
    • 客户端性能标准
    • 前端性能标准
  • 安全标准
    • 信息安全标准
    • 代码安全标准
    • 数据安全标准
    • 线上安全标准

3.2.2 统一流程

流程是什么?

流程是基于时间线,有一定先后序列规则的完成一件事的过程。流程是线性的、连续的。

统一流程是什么?

统一流程就是把一些验证过的好的做事方式,好的经验通过流程的方式固化下来,防止大家重蹈覆辙,在一个坑里踩多次,并且为不熟悉的同学做好指导。

我们做任何一件事都是有流程的,有些是设计过的,有些是自然而然的,设计过的流程可能是别人的经验。并且流程需要持续迭代。

在研发管理中我们常常会构建的流程如下:

  • 敏捷流程
    • 需求迭代流程
    • 紧急需求流程
    • 值班需求流程
  • 研发流程
    • 代码审核流程
    • 代码发布流程
    • 紧急发布流程
  • 协同
    • 对接流程
    • 资源申请流程
    • 线上问题/告警处理流程
    • 事故处理流程
    • 安全问题处理流程

3.2.3 统一工具

以上说了要统一标准,统一流程,这些第一步是要把这些标准和流程做出来,形成文档,落到知识库中。 如果只做到这一步,这些标准和流程可能就真的只是一个文档,情况好一点,有人来推进重视,可能会落实一些,但一旦这个推进人不在了,或者不再关注了,很多形式就不了了之。

要解决这个问题只能通过工具或系统,以工具或系统的形式固化标准和流程,把这此好的经验和方式以更物理的方式沉淀下来。再以这些工具或系统为杠杆,提升整体研发的效率,创造增量的价值。

4. 系统

这里的系统不仅仅是指使用某个系统,在使用系统的基础上整合,实现我们高效执行的目的。 前面我们有了机制,但是事情太多,不能让所有的事情用人来去解决,需要用系统来解决。

机制解决规模化的问题,系统解决规模固化的问题。 系统解决的问题有两个层面,一个是过程跟进,一个是结果度量。

4.1 工作流和过程跟进系统

一个研发部门可以看作一个系统,需求从一端进入,经历各种正确的工序,才能变成产品,如期从另一边离开。 当系统内部存在冲突,或者不和,或者互相针对,那么就会发生各种想象不到的问题,从而让整个系统的产出变少,甚至没有。

着眼于整个工作流,确认瓶颈点在哪,尽可能的运用各种技术和流程来确保工作在计划内有效的执行。因为我们知道:在代码投产之前,实际上并未产生任何价值,因为那只是困在系统里的半成品。

在实际中我们如何让大家更好的协同,更好的让这个工作流运转起来呢?以前可能是 Excel、Word 或者 todolist,再加上邮件或 IM 传来传去,现在更进一步有在线的表格协同,还有更完整的项目管理系统,如 Jira 、Trello、腾讯的 TAPD、阿里的 Teambition、禅道等。工具不同,但是目标是相同的,都是希望做到对项目执行的管控、对团队事务(问题)的跟踪,对需要多人协作任务的快速流转和处理。

除此之外,还需要文档管理,即过程中的物料也需要跟进起来,关联起来。至于是一个系统,还是多个系统,都是可以的。

系统虽有,但用得怎么样不好说,一个好的系统用不起来也是白搭,这里作为管理者需要推动起来的。

4.2 工作可视化

项目管理的系统用起来后,我们的工作流转就会落到系统里面,此时根据系统的数据,我们可以让工作可视化,透明化,能够清晰的观察工作流动的情况,从而发现瓶颈。发现问题是最难的,很多时候我们不知道有什么问题,包括自己。发现问题,才能解决问题,方法总是有的。 在资源有限的情况下,对非约束点的改进看起来很正确,但实质上毫无帮助,甚至会消耗宝贵资源拖累真正需要解决的问题。

我们可以构建一些看板,看一个产品从产品到设计、到研发实现,到测试完成,上线发布,再到线上问题跟进等等的情况。看效率,看一个需求从出现想法到用户看到需要多少时间,每个环节需要多少时间,哪些需求在哪些环节停留太久?不同的需求,不同的人,不同的产品做多个层次的对比,从而发现问题解决问题,让一切都在阳光下进行。

同时,我们可以让系统和数据告诉我们,整体团队的投入如何,有多少同学的工作是可以追溯的,有多少人力是隐藏在不为人知的地方的,能看到我们的时间都去哪了。

基于这样的看板,我们从两个角度优化整个系统:

  • 从左到右的流动,看从产品、设计、研发到运维的工作情况。为了最大程度地优化工作流,需要将工作可视化,减小每批次大小和等待间隔,通过内建质量杜绝向下游传递缺陷,并持续地优化全局目标;
  • 从右向左的反馈,每个阶段中,应用持续、快速的工作反馈机制。通过放大反馈环防止问题复发,并缩短问题发现时间,实现快速修复。通过这种方式,我们能从源头控制质量,并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统,还可以在灾难性事故发生前就检测到并解决它。

总体来说,先透明出来,再优化,打开黑盒,问题会简单很多

4.3 其它

以上的两个是从任务跟进和结果度量的角度,或者说从项目管理的角度来看整个团队的运转。 换一个角度,从研发同学工作本身,有没有需要系统化的地方?

代码管理是否系统化,Code Review、接口文档、接口自动化测试、Mock 数据、测试数据集管理、用户数据自动脱敏重放,代码从写完提交到代码库之后到上线,线上巡查等等这些是否有系统化?

这并不是今天我们要讲的话题,但是就系统化来说,这些都是必不可少的关键点。不管是哪方面,我们的原则是尽量减少人工介入,把人的经验变成代码和系统。

5. 后记

这篇文章务虚居多,也比较散,但是确实是技术管理者日常工作中要不停思考的点。 思考这些是用来帮助厘清思路,并不具备实操性,也就是不能实际的解决问题。 不同的公司,不同团队,问题不同,解决的方法也不同,欢迎一起探讨。

打开「黑盒」,问题会简单很多。常思考人、组织、机制和系统,这 4 个方面,发现其中的问题,并厘清解决问题的思路,一步一步,有节奏的去解决。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com

communication

技术管理必备之沟通机制

在《汉语词典》中,沟通有如下定义:

沟通本指开沟以使两水相通。后用以泛指使两方相通连,也指疏通彼此的意见。

沟通是通过一定的载体将思想、信息和情感在人与人之间进行传递或交换的过程,群体间的沟通最终也会落到人身上。 著名组织管理学家巴纳德认为「沟通是把一个组织中的成员联系在一起,以实现共同目标的手段」,没有沟通,就没有管理。

沟通不良几乎是每个企业都存在的问题,企业的机构越是复杂,层级越多,其沟通就越发困难。 一线的许多意见在上传过程中,被层层过滤掉了;高层的决策传达,在落到一线同学时可能表述完全不一样了。 沟通在组织中的主要作用是上传下达,相互协调,以维系组织存在,保持和加强组织纽带,创造和维护组织文化,提高组织效率。

1 沟通的基本组成

沟通由四个要素组成:沟通目的、沟通对象、沟通内容和沟通方式。这四个要素是相辅相成的关系,缺一不可。这四个要素回答了四个问题,为什么要沟通;和谁沟通;沟通什么;怎么沟通。

  • 沟通目的:是指沟通开始前需要弄清楚沟通的目标是什么,任何沟通都需要有一个目标,如果没有目标,也就不需要沟通了。
  • 沟通对象:明确需要沟通的对象是谁,背景,身份,角色等等,在《官场现形记》第 38 回:“第二要嘴巴会说,见人说人话,见鬼说鬼话,见了官场说官场上的话,见了生意人说生意场中的话。”,这也是明确沟通对象,根据沟通对象确认后续的沟通方式。
  • 沟通内容:是指在沟通中出现的内容,包括思想、信息和情感,在沟通之前沟通的内容需要做充分的准备,如果沟通内容准备不足,可能会导致沟通的失败。
  • 沟通方式:沟通方式是指我们沟通内容的传递方式或者说渠道,常见的有当面聊天、邮件、会议、刊物、报告、演讲等等。

沟通从种类上来分,可以分为语言沟通或非语言沟通、口头沟通和书面沟通、正式沟通和非正式沟通,向上沟通、向下沟通和平级沟通等。

  • 语言沟通或非语言沟通是从沟通的载体来区分,语言沟通包括书面沟通和口头沟通,非语言沟通包括面部表情,身体语言等;
  • 口头沟通和书面沟通是从语言的载体来区分,口头沟通有会议、面谈、演讲、电话等,书面沟通有电子邮件、信函、刊物(电子和非电子)、报表、通讯录等传递书面文字的手段。口头沟通的特点是快速传递和反馈,但是可能传递过程中会失真,书面沟通更偏向于单向沟通、一般会缺少反馈且耗时较多。
  • 正式沟通和非正式沟通更多的是在组织层面,通过是否具有系统性和结构性来区分。正式沟通是从组织所规定的路线和程序进行信息的传递和交流,如组织间的信函、内部的文件、汇报、会议等等;非正式沟通一般是线下的一些闲聊、喝酒时的吹牛以及一些小道消息等。
  • 向上沟通、向下沟通和平级沟通,这里主要是以组织层级间沟通的对象为区分,以方向表述对象群体。向上沟通一般是指向你的老板沟通,即所谓的下情上达;向下沟通是指向你的下属沟通,即所谓的上情下达;平级沟通是指横向的沟通,如一些平级的部门负责人之间的沟通,以交接意见,互助互赢为主。

2 沟通的步骤

2.1 沟通准备

在管理上执行一个动作或者做某个事情需要有目的,不要做无效的管理。就沟通而言,第一是要明确沟通的目标。 结合团队战略目标,将沟通目标融入战略目标中,基于此开展沟通内容和沟通目标的准备,以减少不必要的沟通事项,降低沟通时间成本和人力成本,毕竟任何动作都会有成本。

很多时候,沟通的当事人并没有非常清晰的目标,只有一个大概的逻辑,目标很模糊。在这样的情况下进行沟通,比较容易造成混乱和无效沟通。所以,技术管理者作为沟通的主体,就必须先帮助当事人确立清晰的目标

在确定目标的基础上,我们需要正式就具体的沟通做好准备,一般包括:

  • 沟通对象,了解沟通对象的个人资料,如身份,工种、学历、工作经历、所负责项目,以及一些简单的家庭情况等;
  • 沟通内容,沟通的信息,需要确认这些信息的正确性和充分性,如一些好的问题,一些支撑的数据;
  • 沟通渠道,根据沟通的目的和内容,确定沟通的渠道,比如一些宣导的沟通,可能群发邮件就可以了,或者一些需要及时反馈,需要看到人非语言表述的沟通则需要当面聊天等。

沟通内容和沟通对象强关联,比如一线开发可能准备的沟通内容是具体的工作计划,具体的目标,对老板的沟通可能是技术方向的规划,阶段性成果以及一些管理思路等等。

准备好沟通后下一步是执行沟通。

2.2 沟通过程

沟通过程本质上是一个信息传输的过程,信息传输的模型如下所示:

沟通过程中主体是发送者、接收者和渠道,主要操作是编码、传输和解码。

发送者:沟通的发起者,本次信息传输的主导者; 编码:整理信息,以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程; 渠道:信息传输的载体,常见的渠道包括:语言、电话、文档、传真、电子邮件、各种 IM 工具等; 解码:接收者对所获取的信息的理解过程; 接收者:信息接收者、信息达到的客体,可能是一个人也可能是一群人,也可能没有人。

如我们想给比较多人的讲一个事情,一种性价比比较高的方式就是写文档或电子邮件发给这些人看,这个写文档/邮件,发给接收者阅读并理解整个文档的过程就是一次信息传输的过程,也就是一次沟通的过程。

在信息传输过程中,有较多的噪声会影响整个传输的效果,比如我们刚才说的写文档,编码的过程就是我们将想法、思想和逻辑转化成文档的过程,而每个人写文档的能力,对于问题的理解不一样,从而写出来的文档参差不齐,这里的差异就是我们编码中的一种噪声。

在语言沟通过程中,除了讲,还要听,做彼此的倾听者,沟通过程中随时调整沟通的方式和方向,以求达到沟而相通的目的。 从信息传输的模型来看,这里的倾听其实就是为了更好的解码,更好的接收传递过来的信息,而调整沟通的方式和方向是为了优化编码的方式,以适配对方的解码逻辑。 汉字其实很形象地表述了听的逻辑,听的繁体字写法是「聴」,拆开来看,它要求我们听的时候要用耳朵、眼睛和心来聆听,这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」,这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」, 而且是根据对方的「斤」两来决定到底听还是不听。

特别说一点,技术管理者在与下属沟通过程中,需要不断地增加沟通的可能性,引导下属的想法和目标,以平等的态度,梳理逻辑,让沟通状态从混乱变为清晰,从而达到沟通的目的。

2.3 沟通回顾

沟通完成后,需要对沟通做一些回顾,以检验和巩固沟通的效果。沟通回顾包括两部分,沟通中问题和待办的跟进和沟通效果的检验

在一次沟通过程中,可能会有一些事项需要沟通后再来确认或完成,针对这些事项需要明确具体的执行人和完成时间。 对于一个组织而言,应该要有一个统一的地方或一个系统来跟进这些任务,看是否完成或达到预期。如常见的项目管理工具或者在一些文档系统中以任务列表的方式集中起来,不定时查看。

沟通回顾在整个沟通中是非常重要的一个环节,无论沟通前的准备有多么的充足,沟通中的交流有多么顺畅和精彩,没有跟进和效果的沟通就等于没有沟通。

2.4 常见问题

在整个沟通过程中有一些问题我们可能会遇到比较多:

  • 没有目标,为了沟通而沟通,如一些会议,大家都在开会,但是不知道为什么要开,只是有人叫我开会了,就去了;
  • 沟通准备不足,前期只是准备了一些模棱两可的资料,这就造成了在沟通的过程中无法正确地运用资料,也无法让资料帮助沟通,比如一次会议中,会议前没有准备好会议相关的资料,会上可能大家就漫无目的的在聊了,最终也没有结论;
  • 没有章法,沟通中的信息过于繁杂,沟通目标确定之后,在沟通过程中对用到的信息进行收集、筛选,与沟通主题无关的信息要尽量屏蔽;
  • 不说人话,没有从接收者的角度来沟通,当沟通的主题涉及专业领域,先注意弄清楚对方的实际水平以及专业情况,不要盲目地运用太多的专业术语,以免造成沟通过程中的歧义;
  • 沟通态度消极,沟通是双方的事情,如果有一方的态度不积极,很容易造成沟通不畅,甚至是无效沟通。除此之外,不倾听、不提问,以及一味执着于自己的观念也是另一种消极状态。

3 构建正式的内部沟通机制

在一个组织的内部沟通中,沟通双方存在着共同利益,以及一致的目标,所以只要沟通机制没有问题,就很容易达成共识。

构建正式沟通机制是为了保证内部沟通在正式环境中,能够顺畅而有效地沟通。例如,内部的周会、月会、年会,以及各种内部的正规会议和讨论中,规范内部的目标、工作方案,以及合理化建议的渠道,并且有非常明确的奖罚制度。一个完善的正式沟通机制有如下好处:

  • 建立起很好的下情上达,上情下达的沟通渠道,让内部的每一个人都知道,该如何有效地将自己的合理化建议落地;
  • 让每一个人都能够在内部正式的沟通中,发挥出自己的特长和优势,从而提升个人的归属感和工作热情;
  • 避免管理者无法决策,或者决策失误的产生。

3.1 构建会议机制

在企业内,会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。 无论是大会还是小会,开会的目的都是为了通过讨论解决某个问题或做出某项决议。一个高效有序的会议,不仅能够提升工作效率,还能增强员工的参与感和创造力。

开会的最佳意义在于讨论和互动。只有在你真正需要参会人员之间的互动,需要大家分享彼此的意见和知识,并最终形成一项决议的时候,才有开会的必要。

以下是我们常见的几种会议类型。

3.1.1 管理例会

所谓例会,都应有相对明确的主题,相对固定的参会人员,相对结构化的会议流程。 管理例会是管理者组织的由管理者及其下一级参加的会议,其主要有如下目的:

  1. 固化管理正式沟通机制;
  2. 上情下达,同步公司级或上级最近方向、信息和决策;
  3. 增加组织成员之间的沟通交流,知道大家都在做什么;
  4. 拉齐大家的认知,确定共同的目标和行动方向,达到团队的一致性;
  5. 协调资源,看看有没有什么需要相互支援和相互协作的;
  6. 群策群力,决策当前级别组织的大型事项;
  7. 增加组织成员的归属感和角色感。

管理例会可以在各级组织召开,尽量管理者和其直接下属来开,跨多级可能会出现跨级管理的问题。

明确了会议目的,下一步我们需要明确会议内容。会议内容由于企业的不同,组织层级的不同,团队规模的不同,沟通的内容差异较大,这里我们抽象一下,以问题的形式,列出一些常规的沟通内容。

  • 组织的方向是什么?
  • 公司有什么消息?
  • 最近都干了些什么?
  • 组织内有什么问题?有什么需要协调、沟通解决的?
  • 我们想改变什么?如何改变?

3.1.2 项目晨会

项目晨会属于进度会议的一种,其主要作用如下:

  1. 同步大的进度;
  2. 暴露风险;
  3. 协调资源;
  4. 团队仪式感,让大家觉得是在一起做事情;

项目晨会和管理例会不同,会议中角色除了组织者和参与者,可能还有模块组织者,特别是一些大的项目团队。各自的职责如下:

  1. 组织者:组织晨会,记录会议的过程和决议;
  2. 模块组织者:准备模块的会议文档,同步进展和风险;
  3. 参与者:负责对齐自己所负责模块的进展并暴露风险,有需要协调的在会上提出来。

由于项目中的事情比较多且杂,不可能一个个细项都在晨会上讲和讨论,我们需要有一些原则来控制会议,让整个沟通更高效。会议原则如下:

  1. 充分的准备;
  2. 沟通进度,快速过,不讨论具体工作;
  3. 发现问题,不解决复杂问题。简单的组内协调问题,立即解决;复杂的问题,如果涉及组外协调,给出简单的原则和建议,会后解决并同步进展;

3.1.3 需求规划/评审会

需求规划会一般存在于有良好的需求迭代节奏的组织,其组织内有计划的对于需求进行规划,评审,然后进入迭代,开发测试并交付。

这里的需求规划是指需求已经在产品内部评审过,马上要进入迭代,研发同学对于产品需求的技术合理性、业务价值进行评审的过程。

需求规划会主要的作用说得直白一点就是卡需求,为什么要卡呢?这并不是为了难为产品同学,而是因为需求一旦进入研发阶段,整个事情的投入成本就会急剧增加,如果不合理的需求,或者价值不大的需求占用了较多的资源,可能会导致其它重要或者价值更大的需求的资源变少。技术管理者为了让整个技术团队的 ROI 更高,为了后续研发效能,在需求规划会上评估需求需要看以下一些项:

  1. 需求文档是否准备好,实际中需求文档没写清楚的大有人在,一个事情没有写清楚,表示还没有想清楚,此时不适合投入资源;
  2. 技术上是否具备可行性,需要评估需求在实现层面的难度,对于一些技术难度高,但是业务价值低的需求建议会后再探讨;
  3. 依赖项是否准备好,如一些外部依赖,前置依赖等;
  4. 是否有较好的业务价值,需要有数据支撑,或者直接说明这就是一个实验性质的。

项目管理过程中除了项目晨会、需求规划会还有迭代回顾会,项目总结会,项目问题解决会等等,这些会议的目的都是为了项目过程去发现问题,解决问题,在项目结束后总结问题,提炼问题为下次项目做准备。

3.2 构建定期当面沟通机制

在会议之外,我们还需要构建定期的当面交流以补充会议机制中缺少的一些内容,如一些人文关怀,一些需要深入了解和聊聊的点。

3.2.1 1v1 沟通

每个技术同学都希望得到指导,希望有人告诉他方向在哪里,有哪些可以提升的地方,希望在和上司的探讨中有所受益。

在 1v1 沟通前我们依据前面的沟通逻辑,要针对沟通目标、沟通对象、沟通内容做好准备,我们可以从 HR 那里拿到关于沟通对象的基本信息,把这个基础上,准备一个沟通记录表,记录表大概结构如下:

姓名 岗位 面谈时间 持续时间 面谈目标和记录 下一步计划
张三 前端 2022/2/10 30 min 1. 关注当前前端技术, 2. 最近正在对跨端架构做深入了解,3. 有一些管理预期 观察,适当给予带小团队机会

面谈目标和记录将目标和记录放一起是由于两者是一个过程,在面谈开始前管理者先把目标和问题记下来,然后在面谈过程中会有一些输入,基于这些输入确认目标是否达成或问题是否解决。

在 1v1 沟通中,管理者更多的站在一个帮助者的角度,平等的沟通,从对方的角度来发现问题,解决问题。关注其日常状态,个人成长,职业发展、家庭状态和身心健康。

在 1v1 沟通中有一个简单的 GROW 教练模型,如下:

  • Goal: 目标,把时间轴拉长了看,你要达到什么样的目标,主要是从职业发展、个人成长等方向;
  • Reality: 现状,基于上面的目标,现况是怎样的;
  • Options: 选择,还是基于上面的目标,现在有哪些方法可以达成,别人是怎么做的;
  • Will: 意愿,你打算怎么做,有没有计划,或者说想做什么样的计划,长线的,短线的。

1v1 沟通在管理工作中是常见的一种沟通方式,当一个技术管理者到一个新的团队,需要和这个团队的每个成员聊聊,如果团队太大,可以考虑往下两到三级,至少要两级。初次的 1v1 交流主要是为了认识一下,熟悉一下。在初次 1v1 沟通后,对于下级或核心的同学需要保持固定频率的 1v1 沟通,固定的 1v1 沟通为工作交流,进展同步,计划跟进沟通为主。

3.2.2 定期组织交流

在个人沟通的基础上,组织层面的当面沟通也是非常重要的一环节。 组织的当面沟通其实也是会议的一种,这里单独拎出来是为了强调这种沟通方式。 和常规的会议不一样,其主要是为了交流,像茶话会,闭门会议、座谈会之类的,其着重突出交流,可以没有结论。

3.3 构建周报机制

从组织的角度来看,周报是组织流程化管理的一部分,是正式沟通地一种手段或方式,其目的是为了更好的向下管理和向上反馈。作为管理者可以通过周报了解一线的情况,如项目的进展,工作的动向;作为普通员工可以通过周报系统性地表述一线的状况。

从个人成长的角度来看,周报是个人反思成长的载体,是自我管理的一种方式,其核心逻辑是:在过去一周你的时间花在了哪里,解决了什么问题,过程中有什么思考,个人有哪些成长。

周报在我之前的文章中有细讲,可以看看:

这里重点提一下,谁来写周报,每个人都要写,特别是管理者,通过写周报了解组织内发生的事情及进展,发现组织内本周的问题。

3.4 构建内部文档沟通机制

周报需要有地方承载,其承载的地方可能是某个 IM 平台的附带插件系统,或者某个文档系统,甚至是邮件。其中文档系统是一个相对系统化的地方,除了周报这种过程性的文档,一些结果类,标准类的文档也可以统一起来。

内部文档沟通机制我们经常称之为知识平台,知识库。一般会有两个主要的作用:

  1. 沉淀知识和历史经验,如标准,流程,规范,业务知识等;
  2. 通过文档来传递书面的信息,让沉淀的知识、标准,规划通过文档让更多的人知道,或者一些过程性的文档统一起来,让大家更系统性的传输书面的信息。

一个较完善的内部文档沟通机制需要回答以下问题:

1. 文档放哪里?

    文档放哪里主要是指文档的载体是什么?各家公司各有不同,有些是用的类似于飞书之类的云上文档,有些用的是开源 WIKI 系统或者在开源系统上优化后的版本,有些是自主研发的系统,最终是要把所有的文档以系统化的方式全部管理起来。当然,也有直接弄个共享盘,大家一起使用的。

2. 文档怎么放?

    文档存放的规则是什么?如果是一个 WIKi 系统,或者有类似于文档空间概念的系统,可以有如下规则:

  • 过程性文档放所在组织结构空间,当组织结构变化时,过程性文档随着变化,以变化应对变化;
  • 结果性文档或者说沉淀的文档,如标准、规范、历史事故等放各技术通道这种更固化或者说更抽象的表述空间下,以不变就万变。

3. 怎么快速找到需要的文档?

     这个问题从技术的角度马上能想到的两个词语是:索引和搜索,也就是当年的雅虎和现在的谷歌。 关于索引,我们可以人工设定规则,比如哪些类型的文档放什么空间下,如刚才所说的过程性的文档放组织结构空间下。这里可能需要更细化一些,如周报放哪些、规划文档放哪里,技术文档放哪里,这些都用规则明确出来,形成索引,在组织内宣导,形成既定的认知。 关于搜索,我们更多的是依赖于所使用的系统,而现在各家公司内部使用的自己搭建的系统,纯大部分的搜索都是属于「又不是不能用」的状态。与此对应的,如飞书,其搜索能力就好很多。
4. 怎么让有价值的文档让更多的人看到?
     这是一个很难的问题,现在没有人能很好的解决,属于内容运营的范畴,从技术实现的角度来看,就是如何推荐有价值的文档,那么这里需要先定义什么是有价值,更多是多少?我也没有答案,现在能看到的是还是人工介入,形成类似于周刊,月刊之类的机制,以推荐有价值的文档。

3.5 其它

除了以上的 4 种正式沟通机制以外,我们常见的还有汇报机制、公文机制、备忘录机制等等,这里就不详细展开了。

内部正式沟通机制的建设不是一个一蹴而就的过程,需要不断进步和迭代,需要内部所有人员一起努力和不断摸索前进。 在构建过程中,我们可能会遇到沟通不畅的情况,甚至会遇到各种意想不到的反对或者针对,此时我们不能放弃构建,也不能放弃沟通。作为一个管理者必须正视内部正式沟通不良的现象,积极面对,及时地解决构建过程中可能出现的问题。

4 构建非正式沟通机制

在正式沟通机制的基础上,我们还需要一些不那么正式的沟通机制,以补全整个沟通机制。

4.1 IM 群

随着信息化的发展,即时通信工具发展迅猛,像微信、企业微信、钉钉等都成了我们工作中沟通交流的主要手段之一。 虽然 IM 有聊天记录等功能,但是作为一个组织的正式沟通机制却是有所欠缺的。

但是我们可以基于 IM 做一些非正式的沟通机制,如组建群,不同的群体组不同的群,以达到部分沟通的目的。 而作为一个技术管理者应该如何拉这些群呢?有一些常规逻辑:

  • 部门大群,全员大群,主要用于消息通知,周报、请假等信息同步,用作信息同步之用;
  • 管理干部群,主要成员是团队的 Leader,主要是用于管理干部的工作安排和探讨;
  • 核心骨干群,主要成员包括管理干部群和各业务模块的负责人,有两个工作,一个是确立核心骨干同学的核心骨干位置感,另一个是骨干同学的工作安排和信息沟通;
  • 项目群/专项群,具备时效性,某个项目临时拉起的群,项目完结就解散;
  • 问题处理群,更短时效的群,主要是针对一些紧急线上问题等需要快速拉齐信息,快速处理问题的场景;
  • 会议群,短时效的群,主要是针对一些会议的群,包括一些会议的准备,过程中的信息同步,以及会后的沟通等;

养成事事有交代的习惯,比如请假或休假之类不在公司的情况,可以在大群同步一下,让大家知道你休假了,你手上的工作谁来对接,如何联系到你,大概格式如下:

卡神 7.25 ~ 7.27 休假,工作交接给 XXX(或者工作不交接),不定时查看钉钉,急事电联:134XXXXXXXXX

以上这个示例也有同学问了,我可以在钉钉上设置状态,为什么要再在群里发一往遍呢? 这两个操作本质上不同的,一个是主动反馈,告诉大家你的状态,让大家可以快速知道你的状态;另一个是被动查询,只有当需要的时候才来看一下,或者根本就没注意到,没法提前安排或者需要问一圈才知道找谁 来解决问题。

4.2 别独自用餐

有本书叫《别独自用餐》,这是一本讲经营人际关系的书,但是这里我们并不是要讲人际关系,只是想用这个标题。

在非正式沟通机制中,技术管理者可以经常拉一些同学一起去吃个晚饭,或者喝一顿小酒,都是极好的,据说酒能让人看别人顺眼一点,趁酒意正浓之时,说点掏心窝子的话,互相吐吐槽,倒倒苦水。

这里就仁者见仁,智者见智,各路神仙,各显神通。

4.3 其它

非正常沟通机制除了上面的两种,还包括电子邮件、社交活动、小型聚会等等,不仅形式灵活多变,沟通时候的内容和形式也比正式沟通更加自由,更加有利于内部人员分享信息、交流心得、增进感情;也更加有利于达成内部的统一思想和目标,明确共同的利益和方向。

5 写在最后

无论沟通模式或工具发展到什么程度,面对面沟通仍然是不可取代的。 良好的沟通,需要知行合一的价值观:尊重他人,请认真对待每次沟通和反馈。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: phppan.com

efficiency

打造高效能研发团队的 5 个关键步骤

在互联网软件企业,今年是一个大家都在非常努力降本增效的年份,包括且不限于人员优化、人员结构优化、技术成本优化,提高人效,提升研发效能等等。 这篇文章我们从研发效能出发,尝试梳理一下打造高效能研发团队的 5 个关键步骤:目标、流程、团队、个人、度量。

1. 找到正确的目标

技术最终都是通过业务产生价值,就算是技术类的产品,最终产生价值也是业务,只是这个业务是一个强技术属性的业务。

一个高效能的研发团队管理者,其首要任务是为团队找到正确的方向和目标。这里正确的目标可以分为业务目标和技术目标。

业务目标的设定可以分为两步:

  1. 和业务方、上级沟通,弄清楚他们的目标是什么,以及明确他们对于研发团队的预期是什么;
  2. 在业务方目标和上级预期目标的基础上,分解目标,内化为带有一定进取的团队目标。

技术目标的设定可以分为两类:

  1. 解决过去留下来的问题,历史的问题我们通常称之为技术债,技术债分为主动债务和被动任务,主动债务大多数是在业务发展过程中为了追求速度而做的一种技术妥协,而被动债务大多数是团队能力或水平不足、业务的演化或技术的发展导致的代码或架构劣化任务,或者不再适用于当下的环境。技术债不一定是一个坏事,一个产品进化到要偿还技术债时,说明业务应该还不错了,在这个当下,找准时机,有计划的偿还一些技术债务是非常有必要的事情。
  2. 解决将来可能出现的问题,将来的问题我们一般称为技术前瞻性,即对即将出现或已经出现但不是很成熟的技术做一些预研和准备,居安思危,提前布局技术投资。

2. 优化流程,做到极致

所谓流程,是基于时间线做一件事的过程,是指一系列的、连续的、有规律的活动,而这些活动以特定的方式进行,并导致特定的结果的产生。其关注的是过程,我们希望通过优化和设计过程来最终达到一个更好的结果。我们做任何一件事情时,都会有流程,只不过有些流程是自发的,有些是被设计出来的,或者说是优化后的。在团队演化的过程中,流程优化和流程管理经常会提出,这些操作都是为了提炼流程或优化流程,让效率更高,让质量更有保障。

流程最终目的在于创造价值,也就是增值,这里价值在研发过程中更多的是质量提高、效率提升等。

研发流程要重点关注两个问题:

  1. 流程对于做正确的事的辅助作用,是否能通过「过程正义」得到「结果正义」;
  2. 流程本身的效率,是否整个流程是顺畅且高效的。

在具体实施时我们可以考虑如下一些方式:

  1. 提高流程的自动化水平或者说工程化水平,如快速的本地构建速度、完善的自测环境、自动化测试、持续集成、流程的系统化等等;
  2. 减少流程的沟通成本,比如说 DevOps 减少的是研发和运维的沟通成本,又或者全栈,减少的是前后端的沟通成本;
  3. 流程分层:针对不同的级别将流程描述清楚,高层次流程较为粗略,中层流程和操作级流程会非常详细,以方便项目各级管理者和基层员工按照相应的流程开展工作;
  4. 大处着眼,小处着手:先全局出发找问题,再深入细节解决问题,比如我们希望提升研发流程的交付速度,可以收集产品周期中每一个阶段所占用的时间,包括计划的时间和最后实际花费的时间,然后通过对比寻找问题最严重的环节,再去解决这个环节。在具体落地时可以考虑流程的可视化。

3. 提升团队效能

我们是要打造一个高效能的研发团队,团队是作为一个整体存在,在团队之间有分工,团队成员之间有协同,沟通等等,如何让 1 + 1 > 2 是在团队层面要解决的问题。以下有一些方法可以提升团队的研发效能:

  1. 减少团队认知成本:如统一开发 IDE;提供完善且性能强劲的统一开发环境和联调环境;团队分工以模块负责人为核心,一个小团队一直聚集于一个模块,不经常轮换;
  2. 增加知识流通,促进知识共享:如知识库的建设、好用的文档系统、代码审查、机制化的分享会等;
  3. 团队的技术债会慢慢累积,在尽量减少债务的前提下把业务跑出来后,在适当的时候偿还部分债务,出来混迟早都是要还的,技术债也一样。
  4. 快速开发模式,尝试测试左移或测试右移。
    • 测试左移是指在研发流程中,把测试的覆盖范围从传统的测试节点中释放出来,将其向左扩展,介入代码提测之前的部分,如开发阶段阶段,需求评审阶段,让研发人员在架构设计时就考虑产品的可测试性,并尽量进行开发自测,同时评估需求的质量,比如分析需求的合理性以及完整性等。
    • 测试右移是指把测试的覆盖范围从传统的测试环节中切出来,将其向右扩展,更多地融入代码部署、发布,甚至上线之后的步骤中。
  5. 灰度发布,监控,A/B测试,混沌工程
  6. 专业的项目管理,研发人数达到 30 人以上时,由于缺乏项目过程中的沟通、控制能力,是造成开发项目混乱,需求返工,研发效率低下的重要原因。如果能够在产品规划时提前发现新产品的技术难点,就可以提前进行相关的技术研究和技术开发工作,减少产品开发项目实施过程中的技术风险。在项目过程中,加强沟通、协调,及时发现各种风险因素和意外情况并采取应对措施,有助于项目计划的顺利实施,从而提高研发的效率。

4. 强化单兵能力

研发最终是要落在人身上,强化单兵能力,对于提升整个团队的效能有极大的促进作用,单兵能力的高低能决定团队总体效能的高低。

一个人的单兵能力可以从目标、效率和初心三个方面来分析:

4.1 目标

高效能人士的七个习惯的第 2、3 个习惯分别是以终为始和要事第一,当我们需要做一件事情的时候先明确本质的要解决的问题是什么,规避掉「XY Problem」,寻找到解决方案以及实现方案的过程中聚焦最重要的任务。

在个人的目标中,我们常见的目标包括业务成功、帮助团队、个人成长。这三个目标是有递进关系的。

  • 业务成功是我们工作的最根本目标,也是基础;
  • 在业务成功的基础上,下一步考虑帮助团队成长;
  • 在帮助团队的同时,给自己带来一些直接或间接的成长机会。

4.2 效率/速度

可以仔细评估个人研发过程中哪些部分可以提速,如在开发前、开发中和开发后:

  1. 开发前:完善而友好的开发环境,不要过度设计,在保证一定扩展性的够用就行,鼓励方案的讨论,并将其机制化;
  2. 开发中:熟悉而高效的编辑工具和代码管理工具(如 Vim、Git,需要有一些刻意练习)让你能高效的编码,个人技能的边界扩展(如前端懂一些后端,在沟通交流中障碍就会很多;甚至全栈,沟通交流在自己脑袋里面完成);
  3. 开发后:尽快让代码跑起来,快速的本地构建、完善而快速的联调环境,使用单元测试和持续集成。

4.3 初心

对于业务,对于当下手上的事情能自驱的完成,最好是将目标和兴趣结合起来,主动的提出自己的想法并推动实施。

5. 合理度量但不追逐度量

著名管理大师德鲁克有句名言:“没有度量就没有管理”。

当我们开始想把研发过程的效能管理起来的时候,一定需要明确度量,即哪些指标可以表示效能的高低,并以此来判断是否有改进。 我们可以从三个方面来度量:

  1. 研发效率/速度:开发的速度,构建的速度,需求的吞吐率,需求的周期,代码行数,平均修复时间等;
  2. 研发质量:测试 BUG 数、新旧 BUG 比,缺陷率、缺陷修复率、线上 BUG 数、线上事故数,性能、安全等;
  3. 业务价值:营收、NPS、功能使用用户数、客服反馈数等。

度量的大概过程是从研发过程中获取数据,并用这些数据来评估过程的效率,质量和价值。 通过度量来评估研发团队的表现,发现对研发工作效率有阻碍的地方,了解流程是否有待改进的关键点并寻求改进的方案。

在我们度量的过程中,度量指标尽量不要与绩效挂钩,而是应该作为参考和工具,帮助团队提高效能。 不要过度追逐度量,不要让度量最后变成一个「数字游戏」,避免只关注一些局部指标而导致局部优化和全局优化脱节的情况,对于过度的不顾大局的局部优化说 No,因为这种局部的优化可能导致整体效能的降低。

6. 小结

我们实现一个系统或一个需求,其实就是在生产一个产品,需要若干个「工序」,从产品需求出发,经过开发、测试、发布、运维等环节,从一种工种流转到另一个工种,最后交付给用户。 在整个研发过程中,把每道工序定义清楚,明确输入和输出的标准,保证每个工序产出的质量,提升每个工序的速度,衔接好工序与工序,就能让整个过程更高效能的流转。

从这里可以看出一个高效能的过程包括如下三个方面:

  1. 清晰的「工序」定义、每个工序有标准的输入和输出;
  2. 保证每个「工序」的质量和速度,做到极致;
  3. 保障「工序」之间连接的有序;

转化成研发过程,一个高效能的开发过程包括如下四个方面:

  1. 清晰定义每个环节,明确每个环节的输入和输出的标准,做好自测;
  2. 保证每个环节的质量,产品需求有需求的质量要求,设计有设计的质量要求,研发有研发的质量要求;
  3. 强化每个环节中个体的单兵能力,提升每个环节的速度;
  4. 通过专业的项目管理,保障环节之间的有序进行,不快一步也不慢一步。

那么如何简单评估一个研发团队是否是高效能的呢?

看这个研发团队的一个需求从想法到上线,全流程平均生命周期需要多久,上线后的质量如何。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com