技术管理经验谈丨你与优秀管理者之间只差这一个图谱

简介:

背景

 

最近我花了很多时间把这几年在团队管理方面的各种实践、学习和思考做了一次汇总。知识来源包括:带团队的实际经验与感悟;在IGT、腾讯和新美大工作期间经历的各种培训和大佬分享;以及二十多本团队管理有关的书籍。

 

在收集汇总的过程中我并没有找到一个现成的体系将所学到的管理经验很好地归纳到一起,于是决定采用一个自底向上的过程,先是将所有知识打碎,然后重新归类汇总。

 

我先是列举出了六十多种实践或方法,然后将它们划分成不同模块,并且思考这些模块之间的关系,最终建立一个相对完整且自洽的体系。有了这个体系,我们就能够以更高的视角来看待团队管理中的各种事务,并且有针对性地加以改善。

 

团队管理图谱

 

可以将团队管理的整个体系分为两个维度,十个模块。每个模块在两个维度之间有自己的定位,模块之间相互独立且互斥。

 

这种划分不是绝对的,也可以有三维四维或者更多的模块。目前的图谱是综合了全面性、合理性和易用性之后的结果。

 

整体图谱如下:

 

 

两个维度

 

从管事到管人:

 

 

 

 

从定方向到拿结果:

 

 

 

十个模块

 

下面对十个模块逐个进行描述,每个模块列举出部分关键点,起提示作用。每个团队都会有适合自己的模块内容,关键是要与团队的业务特点和技术架构相匹配。

 

1时间管理

 

时间管理重个人,项目管理重协作。时间管理是团队中每个人每天具体做什么事的管理,这是团队效率的基础。团队中每个人都要提升时间管理能力,Leader要起到教练的作用。

 

要点:

  • 脑外化

  • 番茄工作法

  • 时间日志

  • GTD

  • 团队工具集

 

2项目管理

 

有些敏捷方法比如XP会包含大量技术管理方面的内容,但我倾向于将两者分开来看。项目管理要根据业务发展的情况动态变化,光敏捷开发常用的队形就有看板、SCRUM、XP三种,而技术管理倾向于依靠规范来实现,更加稳定。

 

要点:

  • 需求评审方法

  • 估时方法

  • 敏捷方法

  • 任务管理

 

3技术管理

 

要点:

  • 技术评审规范

  • 代码风格规范

  • 代码管理规范

  • CodeReview规范

  • 技术债务管理

 

4流程改进

 

技术团队管理者的工作是要做到团队管理、业务需求、技术架构三者之间的相互协同。由于多数互联网团队所做的业务都远谈不上成熟,所以支持它的技术团队在管理上也就不会有稳定的状态,持续改进是常态。

 

要点:

  • Lean & Kaizen

  • PDCA

  • 定量分析

  • 方案收集

 

5制度建设

 

按强制程度排列:制度 > 规范 > 方法。制度建设的完善程度体现着团队的严谨性与纪律性。

 

互联网公司的工作氛围相对自由,但不代表没有规矩。尤其是与产品质量和安全相关的关键环节,必须严加把控。制度要保持最小化且持续有效。

 

要点:

  • 上线管理

  • 故障响应

  • 值班制度

  • 加班管理

  • 考勤休假

     

6目标管理

 

目前主流的管理体系中通常会把目标管理和绩效管理分开来看,OKR偏向目标管理,KPI偏向绩效管理。

 

要点:

  • 战略制定

  • 维度分解

  • 目标收集

  • OKR

  • 行动循环

 

现在为大家介绍一下技术团队如何做中长期的目标管理。在OKR、KPI、SMART等常见理论基础之上,结合实践经验谈一些自己的看法。

 

三个要点:

  • 团队共享 - 目标制定要讲究上下通透,内部信息透明

  • 划分维度 - 业务、技术、团队管理各方面要整体考虑,平衡发展

  • 循环执行 - 目标拆解成具体行动,形成习惯,持续反馈

 

 

团队共享
 
 

 

这里的团队共享有两层含义,一方面要做到上下通透,另一方面要做到信息全明。

 

上下通透:目标制定的过程不只是简单的自上而下或者自下而上的过程,而是两者要交替进行,最终实现目标与整个团队的深度整合。

 

 

 

信息全明:每一位团队成员都要了解自身目标与同事的目标、组织的目标之间的关系是什么。

 

在项目管理中我们通常强调团队内部对于工作内容的共享。同样地,团队目标也要充分交流,及时同步,这样才能更好地相互配合,形成合力。

 

 

 

忌:

  • 目标制定只体现出领导层的意志,团队基层没有想法,只重执行;

  • 每个人只关注自己的KPI,对组织整体目标和同事的目标不关心。

 

划分维度
 
 

 

组织与个人一样是有机体,维持有机体的健康要讲究多元化。团队目标管理与个人目标管理一样要划分多个维度平衡发展。

 

从某种程度上来说,团队目标要比个人目标更讲究平衡性,这也是团队作为集体的优势所在。

 

对于技术团队,目标维度划分举例如下:

 

  • 业务支撑

    • 重点项目

    • 质量与流程

    • 知识沉淀

       

  • 技术建设

    • 核心架构

    • 支撑系统

    • 优化改进

       

  • 团队建设

    • 工作方法

    • 内外沟通

    • 人才培养

    • 招聘面试

 

忌:

 

  • 只重视业务支撑,忽略技术进步与团队建设;

  • 某个维度的目标主导了绩效考核标准。

 

循环执行
 
 

 

从中长期的视角来看,达到目标的过程一定是循环式的,而非线性式的。循环执行也分两方面,一方面是习惯化,另一方面是多重反馈。

 

习惯化:将中长期目标转化为日常习惯。比如CodeReview,简历推荐,技术分享等长期活动。我们不单是要在绩效考核上看最终结果,还要设定好循环任务,形成节奏,保持惯性。

 

如果我们要求团队了解公司发展动态,那么就要在任务管理系统中设置每周任务,包括阅读新闻,组织分享等具体行动,将对公司发展的认知融入日常工作中,而不是停留在一个口号上。

 

多重反馈:

  • 即时反馈 - 目标拆解的子任务在任务管理系统中被完成

  • 短期反馈 - 日报,周报,组会

  • 长期反馈 - OneOnOne,绩效考核

 

忌:

  • 目标口号化,没有具体行动;

  • 长期目标只看最终结果,没有行动循环;

  • 只在绩效考核的时候给反馈。

 

所以目标的制定要上下结合、信息透明,目标的构成要讲究多维度平衡,目标执行的过程要讲究习惯化和多重反馈。希望我提到的团队共享、划分维度、循环执行这三个要点对你有所启发。

 

7绩效管理

 

要点:

  • 徽章管理

  • 绩效评定

  • 绩效反馈

 

对于技术管理者,一个很纠结的问题就是如何给团队排绩效。评价队友的工作,决定他们的奖励甚至去留并非易事。下面我和大家介绍一下技术团队的绩效排名方法。

 

承认困难
 
 

 

我们首先要承认,脑力工作者的绩效考核本身是非常困难的,甚至绩效排名这件事情本身的存废与否在业内也是备受争议的。

 

绩效评估中并不存在一套完美的数据模型,能够精确衡量每个人的产出并且根据算法排序。评估中必然含有大量的主观判断和标准不一致带来的异议。我们能做的事情,就是尽量优化评估的过程,让结果得到最大限度的认可。

 

绩效排名的指导原则
 
 

 

  • 团队内提前对齐标准,形成正确预期,不能有惊喜;

  • 信息收集要全面,要体现多元价值观,避免单一标准;

  • 定性与定量结合,任何数据都只是参考,警惕虚假的精确性。

 

流程建设
 
 

 

如果绩效排名有困难,那么通常是评价标准不明确,信息收集不全面所导致的。我们可以通过更加严谨的评估流程来加以改善。

 

绩效排名是一个过程,不能一蹴而就,答案会在过程中逐步成型:

 

 

 

标准同步
 
 

 

绩效考核是团队全体的事情,相关的规则、流程、评价的标准要向团队内部宣讲并且达成一致。其中的要点和注意事项要对成员进行培训,以专业和严谨的态度看待考核流程。

 

公平决策的前提是信息互通。考核标准的同步是后续所有步骤有效性的基础。只有标准统一了,团队成员之间才能给出更有效的反馈,每个人才能建立正确预期,减少后续的争议。

 

顺畅的绩效考核功夫在平时,同步标准不应该只在季度末尾来做。

 

信息收集
 
 

 

信息收集要包括以下三个方面:自我评价、内部评价、外部评价。不同评价角度产出不同的文档,为后续决策提供多方位的依据。

 

 

 

自我评价:

 

团队成员首先要自己收集关于本季度工作情况的总结材料,内容要包括:

 

  • 主要成果 - 从业务、技术、团队三方面阐述;

  • 支撑数据 - 业务收益、开发效率提升、缺陷数等;

  • 支撑案例 - 克服了哪些困难,体现个人能力的事例;

  • OKR/KPI完成情况。

 

团队成员通过自我评价对工作进行反思,并且对绩效结果建立初步的预期。自评材料也是内部评价的依据之一。

 

内部评价:

 

集体Review:集体Review的目的是让大家相互了解工作成果,促进内部信息互通。形式是集中展示自我评价中收集的材料,当面宣讲,并且收集团队成员的意见反馈。

 

定性评价:很多情况下,团队成员的表现很难量化并且横向对比,这个时候定性的评价往往更有参考价值。一个人对另一个人的贡献的判断可能会因为标准不一而产生摇摆,但是人与人之间相互对待的态度则更加明确且稳定。

 

询问每个成员,你的队友当前阶段的工作表现符合以下哪种情况:

 

  • 我以与他一起工作为荣 - 5

  • 他的工作对我有激励作用 - 4

  • 表现中规中矩 - 3

  • 需要更加努力以达到优秀 - 2

  • 长期来看可能会掉队或者对团队不利 - 1

 

经过集体Review之后,团队成员之间相互给出定性的评价。这些评价汇总之后形成表单,作为梯队划分的重要依据。

 

外部评价:

 

外部评价与内部评价关注的方向不同,是内部评价的辅助补充。

 

外部评价容易犯的毛病是流于形式、片面且没有可比性。例如,某PM对研发同学的反馈:“同学A工作认真负责,合作顺畅,开发质量高,期待后续合作中有更好的表现”。这种反馈对于绩效排名来说就没有参考价值,合作顺畅,有多顺畅,跟其它人如何对比,体现不出来。

 

引入外部评价时要注意全面性和可比性,尽量提高其参考价值。

 

选好合作方代表:比如同学A选了三个PM,同学B选了三个QA,他们给出的反馈虽然有价值,但是既不全面,也没有横向可比性,对于绩效排名来说并没有用。

 

最好是从不同角度选合作方代表,比如PM,QA,运营各出一人,他们同时了解同学A和同学B的工作,这样的反馈参考价值就要强很多。

 

 

分维度量化:使用统一的维度划分和评分,提高可比性。可以从以下维度给出反馈:

 

  • 产出质量满意度 1-5

  • 合作顺畅度 1-5

  • 工作投入度 1-5

 

梯队划分
 
 

 

信息收集阶段我们产出的文档:

 

  • 自评材料 - 成果,数据,案例,OKR/KPI

  • 内部互评表单 - 集体Review之后,团队成员的定性互评

  • 外部评价表单 - 分维度量化结果

 

以内部评价为主,外部评价为辅,综合前面流程中得到的信息,将团队成员划分成三个梯队:

 

 

 

排名调整:梯队确定之后,在各个梯队内部排名。由于不同梯队的定位各有侧重,梯队内部排名的价值取向也要各有不同。

 

绩效排名是一个团队价值观的最终体现,每个团队都有适合自己的价值取向,这方面有很强的主观性。我们要把内心中的评价标准摆到台面上,在各个维度对比审视,避免取向漂移。

 

  • 前部:

    • 影响力 - 对内要能激励团队,对外要有好评与认可

    • 整体贡献 - 贡献不能停留在单个项目上,要对团队其它人有帮助,对业务整体发展有帮助

 

  • 中部:

    • 超出期望程度

    • 价值观匹配度

 

  • 后部:

    • 投入度

    • 成长意愿

 

梯队内排名后:

 

 

 

排名完成后,根据团队需要,可以进一步细分:

 

  • 前部中挑影响力最大的,作为头部,形成明星效应;

  • 后部中排名靠后的,挑出稳定性差的,管理风险小的,作为尾部,适当淘汰。

 

最终结果:

 

 

 

绩效排名是一个过程,每个步骤有不同的侧重和产出,在过程中逐渐接近答案。要通过流程建设来保证标准的一致性和信息的全面性。

 

我们可以使用定性与定量数据收集、梯队划分、排名调整等方法,让绩效排名结果得到最大限度的认可,并对团队整体起到推动作用。

 

8人才招募

 

互联网行业的人才市场是高度自由且开放的市场,各家能提供的薪资待遇在这个有效市场中处于动态平衡状态,很难形成局部优势。最终,团队的形象和声誉才是吸引优秀人才的根本所在。

 

人以类聚。我们在希望招募到高素质的候选人的同时,也要考虑到团队自身如何在候选人面前体现出高素质。

 

要点:

  • 公共形象建设

  • 渠道维护

  • 人才标准

  • 面试官培养

  • 面试流程

 

9人才培养

 

人才培养更关注个体,团队建设更关注集体。团队一方面要做事,另一方面要育人,人才是团队的核心资产。

 

要点:

  • 新人导入

  • 培训体系

  • 技能体系

  • 导师制度

  • 骨干培养

  • 晋升通道

 

10团队建设

 

团队建设功夫在平时,关键是建立好内外沟通机制。沟通充分的话,文化和价值观自然能够协同一致,否则都是喊口号和空谈。

 

要点:

  • 对内沟通

  • 对外沟通

  • 文化与价值观建设

  • 知识沉淀

     

总结

 

团队管理也是一门技术,一样可以建立起一套完整且自洽的体系。本文给出的体系是一种参考。每个团队都可以根据实践经验整理出自己的管理体系,并且随着经验积累不断改进,在这个过程中提高全局意识,更好地指导团队管理工作。

原文发布时间为:2017-02-15

本文来自云栖社区合作伙伴DBAplus

相关文章
|
前端开发 JavaScript
【单子】说白了不过就是【自函子范畴】上的一个【幺半群】而已?请说人话!!
起初本瓜看到【单子】说白了不过就是【自函子范畴】上的一个【幺半群】而已?这句话的时候,还以为自己在看量子力学的量子纠缠相关内容,单子、函子、粒子、玻色子、费米子、绝绝子。。。
|
运维 架构师 前端开发
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(1)
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(1)
140 0
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(1)
|
架构师 程序员 iOS开发
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(2)
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(2)
376 0
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(2)
|
架构师 Cloud Native 程序员
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(3)
架构师眼中的文化:组织不扁平,3天后信息衰减到20%(3)
202 0
|
固态存储 Java 区块链
浅谈技术管理之日式管理的殊途同归
《周易》说,形而上者谓之道,形而下者谓之器;降龙十八掌里有履霜坚冰,夕惕若厉等招数;坤卦爻辞中也有含章可贞,或从王事等管理和做人规则。 看完上面几句,大家可能会想,不是说日式管理嘛,怎么说起中国传统哲学了?其实无论是西方的还是日式的管理方法与经验,其理论来源都是中国的哲学思想,无论是德鲁克的任务、责任、实践的管理理论,波特的差异竞争论,哈默尔的核心竞争力,还是明茨伯格的战略和经理人角色,科特的领导与变革,归根到底这只不过是一些管理的方法和手段而已,这些手段和方法,在浩淼的中国传统哲学中都能找到与它们几乎一致的理论,可以说中国的哲学思想是世界管理学的源头活水。 说到日式管理,很多人也都耳熟能
185 0
|
BI 项目管理
艾伟也谈项目管理,五大绝招 消除项目小组与用户的矛盾
  BI项目实施过程中,会导致用户现有工作量的增加,会对用户现有工作进行重新分配,总之会影响用户的即得利益。在这种情况下,项目小组与用户之间矛盾的增加。虽然说BI系统主要是企业管理者在使用但是这个系统的基石基础数据,则是一线用户所提供的。
980 0
为什么建立自己的交易系统?看明白kinmall归纳的这四点你就懂了
在之前我们的文章提过找时间给大家分享一下,如何构建交易系统。趁这些天行情不错,大家喜笑颜开的环境下,金猫kinmall再送干货给大家,算是锦上添花。
5180 0