深度长文:技术管理者究竟应该管些什么?

阅读数:1580 2019 年 10 月 8 日 08:00

深度长文:技术管理者究竟应该管些什么?

本文由 dbaplus 社群授权转载

在讲清楚技术管理者需要做哪些工作之前,我们通过一个驾马车的比喻类比描述下。

  • 在驾驶马车之前,我们首先要看看马车的定位是什么(拉人?运货?等);其次,要看看目的地在哪里,该走哪条路,朝哪个方向行进;再次是当前马匹的情况怎么样(满员?伤病?等)。这些对应到管理中,就是得弄清楚团队的基本职能、工作目标、团队情况及可选路径,它们代表这方向性的东西,可简称为“管理规划”。
  • 当我们开始驾驶马车时,至少需要做两件事:一边抓住马缰,关照好马的状态和组织分工;一边挥舞马鞭,协调好整个马队的前进方向和节奏,让马匹一起用力把车拉到一个个里程碑和目的地,完成一段一段的旅程。前者对应到管理中,很像是在做人和组织相关的工作,我们称为“带人”,或者“团队建设”;后者对应到管理中,很像是在完成一个个项目或一项项任务,我们称为“做事”,或者叫“任务管理”。

深度长文:技术管理者究竟应该管些什么?

综合上面的比喻示例,可抽象概括下技术管理者需完成的工作如下,下面将展开说明。

(以下内容主体来自果见管理 - 刘建国极客时间专栏:技术管理实战 36 讲)。

深度长文:技术管理者究竟应该管些什么?

一、管理规划:“敢问路在何方?”

管理规划对于技术管理者来说,非常之重要。在日常工作中,技术管理者往往需面对大量纷繁复杂的事情,特别是有很多救火类的工作。但在忙乱之余,是不是有一个“全盘规划”的指引,清不清楚把团队带往何方,这才是不同 leader 领导水平的差距所在。出现问题就解决问题,是一种“问题驱动型思维”。而今天我们所谈论的 " 管理规划 ",就是要回答 " 把团队带往何方 " 的这个方向性问题。通过理清未来的发展来理顺当前问题的带团队思路,称之为“规划驱动型思维”。

1、职能

在我们开始管理规划之初,首先要弄清楚就是“这是一支背负着什么样职责和使命的团队”。在明确之后,才能决定了你需要设定什么样的工作目标,并通过哪些要素来衡量你的目标;决定了你需要什么样的人加入你的团队,以及需要多少;还决定了你选择什么样手段,投入什么样的资源来完成工作。这个问题是如此重要,可将其作为管理规划的第一个要素,称之为团队“职能”;这是管理工作的起点。

1)职能层次

团队职能可分为两个层次:基本的职责和升华的使命。前者解决的是团队生存问题,后者解决的是团队发展问题。

  • 职责。是团队职能的下限,即至少要完成的工作。如果这些职责都搞不定,意味着团队的基本价值都不能体现。一般来说,团队的基本职责,是由上级给定的,上级在把这个团队交给你负责的时候,已经给你提了期待,只不过有的上级会明确交代,而有的上级默认你很清楚。所以,你无论如何都需要弄清楚团队的基本职责,否则肯定会失职。
  • 使命。是团队职能的上限,即,如果我们团队做得好,就能承担更大的职责,体现出更大的价值。使命达成后的愿景,常常是令人期待和憧憬的。使命愿景常常是团队 leader 自己的规划和设想。上级一般不会作出这样的要求,最多就是提一下期待,团队做不到也不会认为是团队失职。

2)设定职能方法

①收集信息。可从多角度收集方方面面的信息,包括上级、同级和下级。对上级而言,需关注上级对团队的期待和要求,特别是用什么维度来衡量团队工作。团队的初始定位和基本职责,一般都是上级直接给定的。同级,则需关注与兄弟部门的职能边界,做好无缝衔接、共同发展。下级则可与大家讨论对团队工作的看法,以及对未来发展的期待。这也可为后续的沟通做好铺垫。当然最为重要的是管理者本身对工作的理解、期许。

②提炼和升华。团队的职责和使命,不能只停留在 leader 的脑海中,为了方便记忆和传播,则必须从上述信息中进行提炼和升华。提炼和升华有三个要点:

  • 职责的提炼。基于上级的期待和要求,以及你对业务核心价值的理解,最好用上级和团队成员、兄弟部门都易于理解的语言,对职责进行简短化提炼,并尽可能长时间稳定下来。
  • 使命的升华。基于基本职责,寻找团队对于部门和公司的独特价值,并和行业发展趋势结合,设定自己的期待。要注意使用基于“结果”的描述,而非基于“过程”的描述,基于结果的描述会更有使命感。
  • 确定衡量维度。一般来说,团队的职责和使命决定了衡量的维度,但是如果有明确的关于衡量维度的说法,会让员工对职责和使命有更深刻的理解。需要根据自己团队的职能,向员工明确传递,什么指标维度对团队是最重要的。

③确认和主张。提炼完成之后,接下来就是确认和主张。确认主要是和自己的上级确认,得到上级的认同和支持后,就可以向团队内外进行主张了。主张的过程,就是一个长期宣贯的过程,不可能一蹴而就。这也是团队的文化建设的重要组成部分。

2、目标

在明确了团队职能后,下一步就是确定目标。类别前面的比喻,就是需要明确要去的目的地在哪里,才能评估需要什么样的马、多少匹,以及有哪些路线可以选择。这个关于 " 目的地在哪里 " 的问题,是管理规划的第二个要素,称为“目标”。

1)设定目标意义

问题明确的目标,对于技术团队管理非常具有意义。

  • 目标设定,可以实现资源的有效配置。明确的目标可以让你把资源投注在有效的方向上,从“该做什么”去调配资源,而不是“能干什么”。
  • 清晰明确的目标可以凝聚团队成员的力量,让大家劲往一处使,提升团队凝聚力。大家因为相同的目标而并肩作战,在一起取得成就的过程中建立起深厚的“革命友情”,这对凝聚力有莫大帮助。
  • 清晰的目标,还是执行力的必要要素。回想一下,有多少工作是因为目标不够清晰,而最终有始无终。
  • 清晰的目标还能提升判断力。当面对某个突发状况快速决策,你非常清晰想要的是什么。
  • 清晰的目标本身就是激励,当员工很清楚自己的工作目标,方向感很清晰的时候,他们更容易进入一种投入度非常高,沉浸其中、物我两忘的工作状态。

2)目标设定原则

目标的设定,可遵从 SMART 原则。

  • Specific - 明确性。把目标设定到可以衡量的程度,就叫做明确了。常见的误区是,只做过程化描述,而没有结果。因此,面对这类问题和挑战的钥匙叫做“结果导向的描述”。
  • Measurable - 可衡量性。跟明确性紧密相关。在具体实施上,可参考有量化指标的 KPI,或者目标导向的 OKR 形式。
  • Attainable - 可达性。标准上,不能定一个完全实现不了的很高的目标,也不能定一个不需要努力就能实现的很低的目标。定义一个有挑战且努力能达到的目标,才是恰当的。
  • Relevant - 相关性。对于技术团队来说很难跑偏,因为技术这个角色决定了其工作内容必定是和上、下游及上级目标相关联的。
  • Time-bound - 时限性。所有的目标都是基于一定时限的,缺少时间限制的目标没有意义。

误区:以资源定目标

常见的一类问题是基于现有资源做目标,而不是基于远方的目标往前推。常见的说法就是,“我们团队只能做到个程度”、“这些项目能做完就不错了”等。其实,更为合理的做法是,从上级的角度来讲,你的团队需要保证哪几项重要的结果,然后再看看如何调配和补充资源。简言之,破解之道就是“以终为始”。

误区:目标变来变去

定义的目标,有时不得不面临一些调整。有些是因为业务的原因,有些是因为上级领导变更的缘故等等。应对此类问题的方法就是“设定专业目标”,用专业目标来增强团队的内在定力。简言之,就是“做正确的事”。

误区:事情太多忙不过来

这是一个优先级的问题,可遵循“重要 / 紧急象限法”进行分析。具体可参考下图,原则就是将“重要紧急”转换为“重要不紧急”,尽量减少“不重要紧急”类工作;以上措施就可以减少上述问题。

深度长文:技术管理者究竟应该管些什么?

3、团队

针对团队,可以从多个视角来看待。

1)根据团队目标去梳理团队

作为管理规划的一部分,团队规划是管理者必须重点考量问题。这里需要去设定”团队目标”,即在某个时间点,团队发展成什么状态。有如下衡量指标:

  • 团队的规模。也就是你团队有多少人,这其中要理清楚有多少人是现有的,有多少人是接下来要新增的,即实际人数和预算人数,加起来就是你规划的团队总规模。
  • 团队的分工。即,你的团队都负责哪些业务,每个业务配置了多少人力,以及这些人员都如何分工,人力分布和业务目标是否匹配等。
  • 团队的梯队。一个团队的梯队情况代表了团队的成熟度和复原力。梯队成熟的团队,不会因为一些偶然的因素(例如核心人员离职)就随便垮掉。复原力强的团队只是短暂影响部分业务进展,但是不会伤筋动骨、元气大伤,很快就会恢复正常。

2)从资源角度来审视团队

在很多互联网公司里,技术团队往往是最昂贵的资源和成本。作为一个管理者,在盘点自己当前人力和预算人力的时候,需要有成本意识,要考虑投入这么多资源和成本是否值得,是否合理。其实,即便你不考虑这个问题,你的上级也会考虑,所以,你预算人力的时候,最好能给出十分充分的理由。

3)从人才培养角度看梯队规划

对团队的盘点,还需要从人才培养角度来看。即,到下一个时间节点,你需要重点培养出哪些人,给他们什么样的平台和空间,以及你有能力提供给他们什么指导和支持,期待他们能够胜任什么职能和角色。

4、路径

在选择路径之前,需先考虑一个重要因素 - 资源。脱离资源评估的路径选择是没有意义的。

1)资源评估

这里所提到的资源,不仅仅包括通常意义上的“人、才、物”,还包括其他一些容易忽略的因素。

  • 。最为常见的资源,为参与到项目的人员。
  • 财 / 物。一般也是围绕着团队的人员来说的。
  • 时间。最容易忽视的一类资源,时间长短直接影响人的投入。这里需要参考上级的预期,及你个人的客观分析,需要综合你对紧急重要程度的理解做出判断。
  • 信息。是另外一个常被忽视的资源。有的时候,你需要更多的公司内外的信息,你的工作如果需要特殊的信息和数据,需要提前和上级沟通,寻求必要的支持。
  • 权限。是否需要获得某些权限,作为资源投入。比如获得绩效评估的权限,以此来掌握人员激励的手段等。

2)路径评估

站在管理者视角上,就需要评估一段时间内的产出效率。完成一项工作,原来还有很多的手段可以选择。对于你来说,不同的方案意味着着多大程度的成本呢,可以尝试使用如下评估表。把你认为的“大”“中”“小”填入下表中。这个表格最大的意义不在于让你去评估每一种方案的成本大小,而在于扩展你的管理思路,看到解决问题手段的多样性,避免思路过于单一,就达到目的了。在不同的公司、不同的期待之下,不同的管理者会做出不同的选择。这不同的选择会带来不同的效果,同时也意味着不同的成本。

深度长文:技术管理者究竟应该管些什么?

  • 对于自研来说,由于靠自己团队的力量,资金开销比较低,维护成本也可控;而由于需要边学边做,时间成本会比较高。
  • 对于招聘来说,不确定性比较高,招聘顺利固然好,但招聘不顺则时间完全不可预期,整体上时间成本比较高。
  • 对于借调来说,如果能借调到合适的人,各方面的成本是最低的,但是需要这个事情足够重要才能获得支持。
  • 对于跨部门合作来说,项目推进的可控性取决于合作情况,这里最大的风险就是合作成本能否控制住。
  • 对于外包来说,时间和资金成本一般都可控,用来做尝试性项目或者 demo 是比较合理的。但如果是长期的任务,你会发现外包的解决方案可维护性比较差,迁移和替换的成本会比较高。
  • 采购云服务,对于中小公司来说,其实是很好的解决方案,对人才成本、维护成本、时间成本,都可以降得很低,特别适合初创公司,所以你看业内的云服务层出不穷,确实有价值。
  • 商业方案,是时间成本很低,资金成本略高的一种方案。在应急的情况下,或者是公司非核心业务的场景下,这倒不失为一种好的解决方案。

二、团队建设:“众人拾柴火焰高”

团队建设的核心,在于提高“效率”。参照之前的”工作目标达成分解图”,可将其划分为个体、个体间和团队三个层次。

深度长文:技术管理者究竟应该管些什么?

  • 针对个体而言,重点在于提升能力和个人意愿。
  • 针对个体间而言,在于加强分工和协作。
  • 针对团队,在于构建梯队和文化认同。

1、能力

1)能力分层

员工的工作能力是由三个方面共同决定的,下图可见。

深度长文:技术管理者究竟应该管些什么?

  • 人格力量。通常是指一个人在面对某一情形时稳定的态度和表现,比如迎难而上、坚持不懈、积极正向、主动担当等等。这些人格力量对于个人能否搞定一件事情有时至关重要,但是培养起来却不是一朝一夕的,关键在于平时。
  • 通用能力。没有一个统一的标准,比如我会把沟通表达能力、团队协作能力、快速学习能力等作为重要的通用能力,并和我的团队达成共识。这些能力是可以迁移的,会伴随员工受益终身。
  • 专业能力。对于技术人来说,一般是指技术能力。很多公司都有技术能力衡量标准和体系,用于评估工程师的技术水平。所以,工程师专业能力的评价维度和标准相对于通用能力更加有据可循。

2)鼓励学习

可以组织多种形式,鼓励员工学习。

  • 第一类:帮助员工自学。可组织内外部培训、购买书籍等形式。
  • 第二类:相互交流讨论。可通过定期复盘、技术交流、代码审核等手段进行。
  • 第三类:工作实践。给员工独立负责重要工作的机会,并给予辅导和反馈。

对于提升员工个人能力来说,最关键的往往不是学习的方法,而是学习的意愿。对于很多团队来说,并不缺少学习的机制,而是没有能够有效激发员工的学习动力。主动学习的员工总会是少数派,不只是公司的员工如此,社会生活中的人们亦是如此,所以有人说,“学习是反人性的事情!”。可通过下面多种手段,激发很多员工的学习动力了,你甚至可以把学习和成长放入团队文化建设当中。当然,如果你要把学习作为团队文化的一部分,那就需要你自己首先有学习的“基因”。

  • 推 - 给予压力,推动他们学。比如提出明确的学习机制、工作要求,必要时与绩效、晋升机会、调薪挂钩。
  • 拉 - 指明方向,引导他们学。通过树立榜样、配备导师、辅导方式,引导大家学习。
  • 放 - 给予空间,让他们自主学。在可控情况下,给予员工空间、机会及耐心,让员工充分施展。

2、激励

1)理论 - 马斯洛的需求层次模型

深度长文:技术管理者究竟应该管些什么?

  • 最原始的驱动力主要来源于对生存和安全的渴望,需求层次处于“马斯洛需求模型”的最底层。这类驱动力是人们为了寻求生存下去的基本要素而努力。
  • 第二类驱动,就是“奖励好的行为、惩罚坏的行为”,也就是人们经常念叨的“胡萝卜加大棒”。这是被广泛认同的激励方式,也是当前大部分管理者最常用的激励手段。
  • 第三类驱动,更加强调自驱力。随着中国经济和文化发展,物质奖惩和别人的评价变得不如从前那么令人关注。很多 90 后职场人有着自己笃定的价值观。此外,在这样一个信息时代,员工的创造力更能为公司创造价值,而创造力需要更多的自主和差异。

2)如何激励

  • 第一,激励要立体。你需要从单一的激励维度,升级为更加立体的激励体系,从而适应新职场环境的要求。
  • 第二,激励在平时。不能指望一些临时性刺激方案来做好激励,激励体系的搭建应在平时。当员工跟你提离职的时候,它就已经不再是一个激励问题了。
  • 第三,激励要设计。由于每个人的业务特点不同、团队性质不同、管理风格不同、员工特征不同、问题挑战不同,所以不要迷信别人给你的激励建议,我更建议你充分考虑自己面临的实际情况,结合自己的特质和激励框架,来设计适用于自己的激励体系。

3、分工

不能简单地认为分工一定是件好事。分工是不是好事取决于协作水平,协作水平又受限于管理者的管理水平。通常分工的目的是为了实现规模化(多人干大事)或实现专业化分工(用人之长、避人之短)。

1)组织结构

从一个业务所涉及的各个角色的分工情况来看,互联网领域最常见的组织结构有两类,一类是矩阵式的,一类是 BU 式的。

  • 矩阵式结构。员工按照角色被划分到不同的团队,每个团队都有自己的负责人。要做项目的时候,会有专门的项目经理来向各个角色的 leader 协调人力,然后把申请到的各个角色的人组织在一起去完成这个特定项目。一旦项目完成之后,人员将回归各自团队去迎接新的项目。人力资源是按照角色“横向”来组织的,而项目执行是按照任务“纵向”来推动的,就形成了一个纵横交错的矩阵式结构,所以叫矩阵式组织结构。这类组织架构的好处是各个角色团队的专业度都会很高,而且角色归属感比较强,资源调配灵活;但不足之处是项目执行起来较为低效,因为每次都要重新申请人力,而且每次的项目团队都需要重新磨合。
  • BU 式结构。就是“业务单元”式,也叫事业部制,是指做某项业务所有的人员和资源都统一调配,无论这个事业部是大是小,都角色齐全。这样做的好处是团队长期合作磨合充分,协作效率高,执行速度快;不足是各种角色自己都要有,资源冗余和浪费比较多。另外,由于某些角色不在业务主干上,团队规模比较小,能力要求也不高,所以其角色专业度很难提升。

4、协作

“就是只要一句话,甚至是一个动作、一个眼神,对方就知道是什么意思。”显然,协作水平很高的团队,就好像一部良好运转的机器一样,既有分工,又彼此紧密连接,形成一个有机整体。其核心在于:

  • 一是建立协作机制,通过机制来约定协作的动作,以此来保证大家“动作协调”;
  • 二是提升团队凝聚力,通过提升团队成员间的信任度、认同度和默契度来降低协作成本,提高协作效率。

可以说,“硬件”靠机制,而“软件”靠凝聚力。

1)提升凝聚力

  • 设立共同愿景。想提升团队凝聚力的时候,总是希望大家“心往一处想,劲往一处使。这就要求团队首先要有一个使命和愿景,有一个共同的长远目标,供大家“往一处想”。如果团队有着自己的使命,又能得到团队成员的普遍认同,大家会更容易朝着一个方向共同努力,也更容易肩并肩地一起迎接挑战,即所谓的“志同道合”。
  • 提升员工归属,让员工从心里就认为自己是团队的一份子。你要分给他一份职责,人的内心深处是渴望承担适当的责任的。有当员工清楚自己能为团队做出什么贡献的时候,才会心安,才会感受到自己是团队的一份子。要让员工清楚他肩负的职责对于团队的意义,让他觉得自己做的事有价值,这就是所谓的“事对”。
  • 要营造良好的团队人际关系,让彼此间形成紧密的连接。团队成员间良好的关系,和团队凝聚力的提升是互为因果的,所以不要小看能促进员工间关系的一些小事,恰恰是这些小事,能够促使员工间的合作关系走上正向循环的轨道,员工会因为喜欢和团队的人相处而觉得有归属感。这就是所谓的“人对”。
  • 明确亮出团队的文化价值观。团队的文化和价值观是否是员工认同和欣赏的,决定了他能否长期留在团队。价值观方面的冲突是很难调和的,好的团队文化本身就是一个筛选器,最终留在团队发挥核心作用的都会是认同团队价值观的人。因喜欢一个团队的文化和氛围而产生归属感,这就是所谓的“味对”。
  • 加强相互了解。团队成员间需要不断深入地相互了解和认同。可以通过一些方式增加员工间了解,例如团建活动。这里是需要花点心思去设计的,对增进大家的了解和信任做必要的设计。
  • 共同面对挑战。一起面对挑战的时候,特别能够让大家拧成一股绳。显然一起扛过枪的兄弟,感情是很铁的,毕竟是经历过不离不弃的并肩作战。可以通过攻关项目、紧急故障等,甚至是一些组队的对抗性游戏,都可以得到提升。

5、梯队

一个团队的梯队,就好像一个团队的“骨架子”,这“骨架子”是否健康良好,决定了团队是否健壮。其重点在于梯队的规划和建设方面。规划在前文已谈到,建设就是需要选拨人,并培养成核心骨干的过程。

1)选拔人才

对骨干人员的选择要遵从你团队建设的理念。除了基本的个体能力要强,有成长潜质之外。更重要的是强调其协作能力,因为这些骨干未来不是一个人工作,而是要带领团队的。要强调其行为风格和价值观与团队整体文化相匹配。例如团队强调“勇于创新”,那么一个墨守成规的人员显然不适合成为骨干去培养。

2)培养人才

  • 对齐期待,达成共识。常用方式是 IDP,即个人发展计划。可以将 IDP 与绩效结合起来,就是说培养人才也是要以做出绩效为依托,而不只是为了培养而培养。通过 IDP 可以对齐你和培养对象彼此的期待,让他清楚你关注的是什么,在这个事情上形成共识,从而形成良好的互动和有效的反馈。但在这过程中需要注意,不要以晋升等作为承诺。一方面,晋升等是需要靠员工表现来获得,而不是靠承诺;另一方面也要留有培养失败的退路,避免不必要的人才流失。
  • 提供机会,做好授权。培养的过程是需要在做事上体现的,你需要给培养对象足够的发挥空间,也就不可避免地要做工作授权。

工作授权三段法

深度长文:技术管理者究竟应该管些什么?

授权整个过程可划分为事前、事中、事后三个阶段。其重点在于事前的安排和事后的反馈。因为既然是授权,事中最好不要干涉太多,只做约定好的 check 和支持就好。

  • 事前阶段。管理者首先要明确此次授权的初衷是什么。如果是有多重目标,那么主次关系如何。进而让培养对象明确你的期待是什么。此处可沿用目标管理的 SMART 原则,双方需要明确要求、口径等。在完成授权任务后,需听取其对工作的看法和思路,进而大致判断是否可行,规避风险。最后约定一个沟通机制,为事中做铺垫。
  • 事中阶段。需要管理者定期了解工作进度、评估风险,必要时给予支持,而不是放任自流。在支持方面可遵循“授人以渔”的原则。
  • 事后阶段。对于授权后的工作结果进行评估,并与培养对象充分沟通反馈。注意你的授权目标本身不仅仅只有事情,还有培养目标的。对于培养对象在工作中好的表现,要给予充分肯定,特别是要其优势所在;针对不足之处提供 1~2 条修改建议,以利后续改进。

6、文化

团队文化就好像是团队的气质和调性,它会吸引“气味相投”的人持续加入,而把不符合团队气质的人筛选出去,越来越鲜明的团队价值观让大家紧密地聚拢在一起,从而让团队越来越“结实”,越来越“经得起折腾”,不断增强团队的耐力和韧劲。关于团队文化部分,我之前有文章专门说明,这里就不展开了。

三、任务管理:“不以规矩,不成方圆”

我们研究任务管理,就是为了把事情做出来,产出实实在在的业绩和成果。作为结果导向的管理者,这才是管理工作的落脚点。同时,也是验证管理规划是否合理、团队建设是否有效的最重要的标准和依据。对任务执行,可划分为三个阶段:

  • 在做事之前,我们需要回答的问题是:要做哪些事?先做哪件,后做哪件?也就是分清楚轻重缓急,也叫优先级梳理。
  • 在做事过程中,我们要确保事情的进展按照计划推进,尽在掌握之中,也就是有效执行。
  • 在做事之后,我们要复盘做事的整个过程,并从过去的经验之中抽取一些流程机制,以便以后在类似的场景下也可以做得更好、更顺畅。

1、轻重缓急

对于每个团队来说,当下能做的工作是有限的,增加并发并不会让大家的产出更高效,所以,多任务并行问题归根结底还是优先级问题,即,你要优先保证哪项工作的顺利进行。

1)重要紧急四象限

深度长文:技术管理者究竟应该管些什么?

2)判断标准

  • 如果做,收益是否很大?收益越大,这个事情就越重要。
  • 如果不做,损失是否很大?损失越大,这个事情就越紧急。

3)应对策略

  • 对于“计划内的工作”,关注它在一个规划周期内的价值和收益有多大。收益越大就越重要,也就越需要给予相匹配的优先级、资源和关注度;收益相对不大,就放入“To do list”,作为待办任务处理。
  • 对于“计划外的工作”,看损失是否足够大,这里包括自身损失和因中断正常工作带来的损失。损失够大,就按照紧急任务安排,以止损为核心目的;如果损失可控,就放入“计划内工作”列表。

4)持续改进

  • 原则上,管理者的中心应该在那些“重要不紧急”的工作上,这些是对团队长期受益的,应该作为主要目标。
  • “重要且紧急”的工作,要分析其紧急原因,将其流程化、自动化,逐步过渡到不紧急的状态。
  • “不重要紧急”的工作,往往是事务类的,可交由下属处理,长期可通过自动化改进其紧急状态。
  • “不重要不紧急”的工作,要反思其价值,是否仍然作为核心工作之一。

2、有效执行

在项目执行中,是否能有效执行,取决于多个因素。

深度长文:技术管理者究竟应该管些什么?

  • 目标清晰。在执行之初,就需要对目标有明确且具体的定义,具体到可执行层面;而且要确保上下级对其理解是一致,没有偏差。当目标出现变化时,要做到及时同步。如果目标不清晰,必然会引起员工在紧急程度、质量水平和效果取舍上的偏差,最后也就引发了执行上的偏离预期。
  • 责任明确。明确工作的“唯一”负责人,避免出现无人负责、多人负责等情况。负责人要起到对应的责任,有关项目中所有涉及项目执行和协调的问题都要负责。
  • 机制健全。不要沉迷于依靠个人完成项目,需要有完善的流程和机制,让员工做事有依据。同时对应还需要必要的监督机制,不要将“流程机制”束之高阁。
  • 沟通到位。在执行中,强调主动沟通意识,要做到沟通闭环,而不要想当然。

3、流程机制

在任务执行之后,针对任务中可抽象出来的部分,可制订必要的流程机制。在指定过程中,可明确几个原则:明确目标、责任到人、检查复核、降低成本、全员共识。避免出现为了流程而制定流程的情况,要做到尽量简化,能解决具体问题。

观点:人靠谱 OR 机制靠谱?

人的靠谱度的方差比机制大,即,人靠谱的时候比机制靠谱,人不靠谱的时候会比机制更加不靠谱。即便是最靠谱的员工,也会由于身体状态、精神状态、情绪状态以及外部干扰变得偶尔不靠谱;而机制的意义就在于,当人不靠谱时,事情也不至于变得很差。所以,机制是为了保证做事的“下限”的。同时,机制有很好的迁移性和传承性,不会随着某个人的缺位而产生大的影响。因此,必要的机制是不可或缺的。

番外篇:“如何做好技术判断?”

作为技术管理者,和普通管理者最大的区别,就是 " 技术 " 二字,这也是技术管理者最鲜明的标签和最大的竞争力。从技术工程师到技术管理者的转型,有很多做事的思路和方法都需要转变,其中一个重要的转变就是你和技术的关系。其核心在于从技术实现者到技术应用者的转变,不断提升的是技术的使用能力,而技术实现能力由于投入的时间越来越少,会逐渐减弱。从技术管理者自身来说,既然你选择了做更大的事情,就不得不适当放弃一些细节,放弃一些技术实现能力,不断提升你的技术判断力,让团队行走在正确的方向上。

1、角色转换

技术管理者,对待技术与技术人员会有所区别,是有个角色的转换。

  • 技术实现者:程序设计能力、编码实现能力、技术攻坚能力和技术评估能力,都是需要具备的,主要关心的是 " 怎么做 ",属于 "how" 的范畴。
  • 技术应用者:技术评估能力变得尤其重要,因为技术管理者主要关心的是 " 要不要做 "、“做什么”,属于 "why" 和 "what" 的范畴,是要在综合评估之后,做出决策和判断的

2、评估维度

1)结果评估

要回答 " 要不要做 ",希望拿到什么结果,你要从哪几个维度去衡量结果,从哪几个技术指标去验收成果。事关每项工作的效果和业绩,对结果的评估能力最为关键。虽然结果验收都是放在项目完成后,但是在事先就要明确如何验收,这样才能让大家有的放矢,以终为始。

2)可行性评估

可行性有两层含义:一是 " 能不能做 ",二是 " 值不值得 "。作为技术管理者需要做好角色转换,更多从 " 值不值得 " 着手,就是成本收益问题。收益,往往是显而易见的;而成本,就有很多方面需要考虑了,这正是体现技术判断力的地方。

  • 资源成本 — “人财物时”。需要投入多少人、多少时间,甚至是多少资金和物资在该项目上,这项成本相对容易评估。
  • 维护成本。这是评估技术方案时要重点考虑的。考虑维护成本是技术管理者和架构师视野宽阔、能力成熟的体现。这里面包括:技术选型成本、升级成本、问题排查成本、代码维护成本等。
  • 协作成本。多人协作所增加的时间精力开销。一个方案的协作方越多,需要沟通协调的成本也就越高,可控度越低。如果可能的话,尽量减少不同团队和人员之间的耦合,这样会大大降低协作成本。
    机会成本。这是技术管理者做决策时要意识到的。即当你把人力、时间花在这件事上,同时就等于放弃了另外一件事,而没有做另外这件事将带来什么样的影响呢?就是你要考虑的机会成本。

3)技术风险评估

也叫技术风险判断力。即,有哪些技术风险需要未雨绸缪,考虑该技术方案带来最大损失的可能性和边界,以及在什么情形下会发生。这项评估工作很考验技术管理者的技术经验和风险意识,而且需要借助全团队的技术力量来做出准确判断。

作者介绍

韩锋,CCIA(中国计算机行业协会)常务理事、Oracle ACE、宜信技术研发中心主任工程师。精通多种关系型数据库,曾任职于当当网、TOM 在线等公司,曾任多家公司首席 DBA、数据库架构师等职,多年一线数据库架构、设计、开发经验。著有《SQL 优化最佳实践》一书。

原文链接

https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650781666&idx=1&sn=f818a2998f6b3b60b32f388ff00ab555&chksm=f3f90277c48e8b616d611cffb2fac191cc954cba0c847ee15d114d107049e8e8c4505302dd4c&scene=27#wechat_redirect

评论

发布