HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

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

  • 2019-10-08
  • 本文字数:11233 字

    阅读完需:约 37 分钟

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

本文由 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


2019-10-08 08:0010170
用户头像
dbaplus社群 数据连接未来

发布了 175 篇内容, 共 77.0 次阅读, 收获喜欢 614 次。

关注

评论

发布
暂无评论
发现更多内容

推荐算法概述(十五)

Databri_AI

算法 倒排索引 推荐系统

Reactive Spring实战 -- 响应式Kafka交互

binecy

kafka spring

领域驱动设计101 - 领域服务

luojiahu

领域驱动设计 DDD

【21-15】PowerShell条件判断

耳东@Erdong

PowerShell 6月日更

react源码解析18事件系统

全栈潇晨

React

做好项目管理,项目经理需要具备哪些优秀品质?

万事ONES

项目管理 研发管理 研发管理工具 ONES

什么是OneData?阿里数据中台实施方法论解读

云祁

数据中台 数据仓库 OneData 维度建模

简单好用一键恢复丢失办公文档

淋雨

EasyRecovery 文件恢复 免费恢复软件 硬盘数据恢复

十年一剑智能眼镜的中场战事

脑极体

微信小程序开发(七)—— 版本管理的使用

空城机

微信小程序 大前端 6月日更

业务架构训练营第 0 期模块五作业

菠萝吹雪—Code

架构实战营

ARTS - 日常打卡 6

pjw

微服务架构下的静态数据通用缓存机制

xcbeyond

缓存 微服务 6月日更

LinkedHashMap

wzh

Java 集合 LRU 数据结构与算法 LinkedHashMap

软件复杂度

海拉鲁

读书笔记 软件工程 软件设计

Redis:我是如何与客户端进行通信的

码农参上

redis Redis 协议

网络抓包实战01——互联⽹:客户端请求是如何到达服务器的

青春不可负,生活不可欺

Wireshark TCP/IP tcpdump 网络抓包 tcpcopy

JAVA 面向对象 (十)--接口和抽象类

加百利

Java 后端 笔记 6月日更

Kubernetes手记(19)- 容器资源限制

雪雷

k8s 6月日更

HashMap源码总结

wzh

Java map 数据结构与算法 HashMap底层原理 散列表

线性排序

wzh

Java 排序算法 计数排序 基数排序 桶排序

在线HTML标签清除工具

入门小站

工具

软件开发项目中,产品经理和程序员谁更累?

万事ONES

产品经理 研发管理 ONES 项目经理

Redis入门四:数据持久化

打工人!

redis redis持久化 6月日更

迷惘的六月份

卢卡多多

生活状态 6月日更

数组与链表

wzh

Java 数组 链表 ArrayList 数据结构与算法

Elastic Job简单使用

赵镇

Elastic-job

在线PS(PhotoShop),打开PSD文件,图像处理

入门小站

PhotoShop ps

OpenCV-Python+Moviepy结合进行视频特效处理

老猿Python

Python 音视频 Video PPT 引航计划

常见Java容器对比

wzh

Java collection hashmap set map

Linux之rmdir命令

入门小站

Linux

深度长文:技术管理者究竟应该管些什么?_技术管理_dbaplus社群_InfoQ精选文章