标签归档:技术管理

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

decision

技术管理必备技能之决策

前一篇我们聊了优先级,以有限应对无限,今天再聊一聊经常会用到优先级的决策。

记得我刚开始带团队的时候,有位前辈和我说过,管理就是收集信息,做出决策。 这里的决策就是我们今天要聊的内容。

一个组织最有限且不可再生的资源是什么,就是成员的工作时间。 对于一个互联网企业或软件企业来说,人力成本是最大的成本。 而作为一个技术团队的管理者,其最大的作用是如何让研发同学的时间能产生最大的价值,也就是如何让这些成本的 ROI 最高。 为了提高 ROI 的时,我们经常要做出决策。那么什么是决策?

在说决策之前,我们先说一下决定,决策和决定是不同的。 在各种会上,或者平常的工作中,我们会做各种各样的决定,用哪种架构,做哪个流程或者用哪种方案等等。 只有这些决定产生了资源的分配,才是真正的决定,否则就只能算是一个「伪决定」,或者说根本没有改变什么,也就没有真正的决定什么。 上面所说的资源不仅仅是实体的资源,还有组织中最有限且不可再生的资源:组织成员的工作时间。

一个决定通常具备三个特征:

  1. 有要达到的目标 —— 没有目标,任何决定都无所谓
  2. 有选择或者说有不同的可选方案 —— 没有选择就没有决定可做;
  3. 资源是有限的 —— 资源如果是无限的,我们就可以做任何我们想做的事,而不需要做选择。

综上所述,决定就是选择最好(最合适)的方案,以有限的资源达成目的,其本质是资源的分配。

那么决策是什么,决策和决定是什么关系?

决策是关乎未来的,决策是一组具有长远影响的决定,是一系列的资源分配。

如何决策?

为回答这个问题,我们按结构化思维,把整个决策分为决策前期,决策中期和决策后期。

1. 决策前期

「功夫在诗外」,收集信息,决策是面向未来的连续决定,每个决定都是有着资源的分配,技术管理者作为分配环节主导人之一,如何高效的决策是一个值得探讨的命题。

1.1 收集信息

我们的决策大多是基于已有的信息做的,为了让决策更优,需要持续地收集信息。 虽然在我们需要做出决策时会了解一些信息,但更多的是平常的工作中主动去收集信息,支撑后续可能遇到的决策。

1.1.1 我们需要收集什么样的信息

收集信息,其实也是一个决策的过程。 确认要收集什么样的信息是确认收集的目标,我们收集信息是为了辅助做下一个决定,基于这个决定再来看要收集什么信息。

1.1.2 如何收集信息

平常工作中我们信息的收集渠道主要有如下一些:

  1. 从周报中收集;
  2. 从 IM 等沟通工具中,关注各种群的信息;
  3. 从文档中,历史的文档,团队的文档,此时要求有哪些文档;
  4. 从会议中收集,如需求规划会、技术方案评审会,晨会,例会等;
  5. 从平常的聊天中收集,正式的沟通或者非正式的聊天;
  6. 外部用户、内部员工投诉或反馈的问题;
  7. 从自建的一些质量监控报告,自动化测试报告,自动构建的结果和系统的告警、线上的事故;
  8. 从服务于整个公司或部门的业务支撑系统,大数据系统等;

通过这些渠道我们将收集到很多信息,在收集的过程中要注意信息的适当性、正确性和全面性。可以考量如下一些方面:

  1. 信息是否全面,是否包含了时间维的信息,如过来的信息和未来的假设;
  2. 信息收集的范围是否全面,是否包含了不同角色的观点;
  3. 信息是否是片面的,因为片面的信息可能会导致错误的推导,从而影响下一步的决定;
  4. 信息中是否包含错误或有些偏误的部分,有没有和权威机构做一些对比。

1.1.3 如何使用这些信息

  1. 通过收集到的信息评估我们过去对未来的假设是否正确;
  2. 通过收集到的信息评估我们有没有往目标靠近,如果能达成目标,或者能向目标靠近就是好的决定,可以继续,否则就需要调整。

1.2 确认目标

做开始决策时,先思考自己的目标,我们经常说「以终为始」,用想要的结果来反推现在的工作,用目标来标注现在的方向。

一个好的目标包括三个部分:

  1. 明确的目的 — 我们最终要的是什么,方向在哪里,目的地在哪里,「以终为始」;
  2. 明确的范围和边界 — 包括什么,不包括什么,没有范围和边界的目标不是目标;
  3. 明确的视角 — 我们从谁的角度/观点看事情,做决定,视角决定了方向。

对于目标我们一定要思考我们目标是否和组织的目标一致,是否和公司的战略一致。

技术管理者的责任是要用有限的资源去达到组织的目标,即使在处理眼前问题的时候,也必须以目标为思维的起点去思考,做决定,以终为始,这样才可能达到目标。

确定目标后才开始做决策。

2.决策中期

因为资源是有限的,而我们要面对的是一个无限的世界,以有限应对无限,就需要有优先级。

2.1 确认优先级

在确认优先级之前我们需要先明确未来的目标和现状有多大的差距,这个差距需要做哪些事情才能达成,哪些事情是最重要的,如果是最后一博,应该做哪件事?

把所有的事情拉通了来看,是否现在做的是最重要的,有没有更重要的事情要做,有没有重要不紧急的事情要做,如果有,那么就先做重要的,尽量做重要的事情不做紧急的事情,。

如果几件事的重要程度相当,从它们可能造成的影响或风险的角度来区分轻重,先做正面影响大、风险小的事情。

需要有所取舍,不要只看到短期的收益,对于长线的收益也不能忽视。

2.2 可选方案

在明确了目标,确认了优先级,下一步的核心的思考是有没有更好的方案。 更好的方案就意味着有多个方案,往往最终的方案不是某一个方案,而是多个方案综合起来后的方案。

我们在做决策时,常常落入只有一个方案的陷阱中,然后去思考这个方案有没有问题,或者如何让方案更优。 此时我们更应该做的是按「 MECE 原则」,尽可能的穷举行业内的,公司内的所有可能的方案,评估这些方案的优劣,成本收益,再确认方案是什么。

在评估方案时,列一个表格,设定必要项,可选项及其权重,对可选项进行评分,加权汇总,最终可量化的得出一个方案。 然后在这个得出的方案基础上再去完善。

2.3 影响决策的心理学

2.3.1 锚定效应

锚定,是指人们倾向于把对将来的估计和已采用过的估计联系起来。

我们在做决策的时候,当评估好坏时,经常会和一些锚定的东西对比,或者和一些先入为主的信息作对比,因为本来也不存在绝对意义上的好和坏,一切都是相对的,关键看我们如何定下基点。 基点定位就像一只锚一样,它定了,评价体系也就定了,好坏也就评定出来了。

2.3.2 惯性思维

先看一个关于惯性思维的小故事,这个小故事里的逻辑在我们在给人出脑筋急转弯的时候也会经常用到,故事是这样的:

心算家阿伯特·卡米洛从来没有失算过。有一天他做表演时,有人上台给他出了道题:“一辆载着283名旅客的火车驶进车站,有87人下车,65人上车;下一站又下去49人,上来112人;再下一站又下去37人,上来96人;再再下站又下去74人,上来69人;再再再下一站又下去17人,上来23人……”

那人刚说完,伯特·卡米洛便不屑地答道:“小意思!告诉你,火车上一共还有……”。
“不,”那人拦住他说,“我是请您算出火车一共停了多少站口。”
阿伯特·卡米洛呆住了,这组简单的加减法竟成了他的“滑铁卢”。
阿伯特·卡米洛是心算家,不论是算车上还有多少人,或火车一共停了多少站口,都是难不住他的。

惯性思维也称为思维定势,也就是我们常说的手里拿了一个锤子,看到什么都是钉子,总想敲一敲。 在环境不变的条件下,思维定势使人能够应用已掌握的方法迅速解决问题。

惯性思维是人类进化过程中形成的对人类有帮助的思维定势,能减少日常中很多时候思考问题的繁琐步骤,快速解决问题。 但是它不会一直正确,可能在我们做决策的时候把方向引导到一条偏僻或者不正确的路上,此时我们就需要打破惯性,重新出发。

2.3.3 沉没成本

沉没成本,是指由于过去的决策已经发生了的,而不能由现在或将来的任何决策改变的成本。

从决策的角度看,以往发生的成本只是造成当前状态的某个因素,当前决策所要考虑的是未来可能发生的成本及所带来的收益,而不考虑以往发生的成本。

人们在决定是否去做一件事情的时候,不仅是看这件事对自己有没有好处,而且也要看过去是不是已经在这件事情上有过投入。我们把这些已经发生不可收回的支出,如时间、金钱、精力等称为「沉没成本」。

有一个叫亚克斯的心理学家说过:“一个人生的90%以上的不幸都是因为不甘心造成的”,在生活中我们常常为了逃避损失带来的负面情绪而一味的沉迷于之前的付出当中,我们会选择一种非理性的思考方式。决策时我们需要特别注意。

2.3.4 确认偏误

确认偏误也称为「证实偏差」,它一般指在一大堆证据里面,人更容易注意,记住和相信对自己有利的证据,忽略相反的证据。

中国古代有句老话叫:“情人眼里出西施”,当你喜欢一个人的时候,她的一切都是这样的美好,你会找出她的各种优点在你的朋友面前描述她。

2.3.5 X-Y PROBLEM

X-Y PROBLEM 大概是这样:

  • 某人想要解决 X
  • 他不知道怎么样才能解决 X,但感觉 Y 可以解决
  • 他同样不知道怎么样才能解决 Y
  • 他寻求 Y 的解决办法
  • 其他人想要帮助他解决 Y,但是摸不着头脑为什么要使用 Y
  • 经过漫长的交流,终于明白了原来他是想要解决 X,而 Y 并不是解决 X 的合适的方案

做决策往往是要解决一些问题,而问题可能并不是根本的问题,只是一个表象,需要我们找到问题的根本原因再去做决策,否则就会在一个方向性的错误上浪费资源。

3.决策后期

在方案确认后就进入决策的后期,也就是决策的执行环节。 在执行决策过程中,还要持续地收集信息,对人员进行管理,对风险进行管理

3.1 人员管理

任何决策都是需要有人去执行的,项目管理中经常用到的 RACI 矩阵表能较好地解决人员管理的问题。

项目名称 执行(R) 决策(A) 顾问(C) 通知(I)
订单系统 研发二组 产品组王五 李四 商业化部门

RACI 矩阵表解释如下:

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

有了 RACI 矩阵的表,我们就可以知道资源是谁在分配,谁来拍板,谁能够给我们提供帮助,谁能给我们提供输入,谁来具体执行,出了问题应该找谁,做好了找谁去汇报或通知。

3.2 过程控制

决策不是一个一次性的事件,是一个不断进步或者演变的过程。 决策是面向未来的,而其依据的却是已经发生了的事实和我们对于未来未知的假设。

在执行决策过程中,我们需要持续地收集信息,观察事项发展的态势和环境的变化,主动评估当时的决定对未来所做的假设是否还成立,评估实施后的效果是否达到预期,如果发现假设不成立或不达预期,要及时调整决策。

过程中可以设置如下一些机制以对整个过程进行控制:

  1. 假设实验的机制,因为决策是基于一些过去的事实和对未来的假设做出的,未来是不可知的,因此我们需要基于假设做一些实验,小范围试点,现在流行的数据驱动,A/B 实验是一个比较好的落地方案。这种机制是为了把未知转化为可能的风险,然后通过实验降低、控制、管理风险。
  2. 复盘的机制,每到一个里程碑做一次复盘,确认成果,并检查我们之前的假设是否正确,是否需要调整,复盘之后再重新出发。

4. 后记

技术管理的工作就是在不确定性中寻找平衡,通过不断地收集信息,决策,改变资源从而改变团队、架构,让组织的 ROI 更高。

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