您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 其他 > 正文

程序员老司机:如何让技术团队的战斗力提高300%?

发表于:2017-11-27 作者:王东 来源:中生代技术
对于公司尤其是技术型公司来说,人才是公司最根本的竞争力元素,因此,如何管理团队,将团队打造成有战斗力的单元,就是各个管理者不得不面对的问题。

管理就是带人,带人心。本文通过介绍如何提升领导力、如何通过建立合理的职级体系和绩效评价体系、如何进行人才盘点以及如何构建团队文化几个方面,阐述如何成为合格的团队领导者,如何提升团队的战斗力。

技术管理的本质


从 3 年前离开亚马逊到现在,我也在不同的公司混了一圈,虽然本人自诩为程序员老司机,但是由于工作的需要,从 2014 年开始从事管理工作,虽然之前也带团队,但是一直不是管理的 title。

做管理两年来,我有很多的心得和体会,我经常反思之前作为团队成员的一些想法和做法。我发现管理是一门很深的学问,以前没做管理,不太理解的一些事情,现在也能慢慢理解了。

国内大多数公司的中层乃至高层的技术管理,一般都是技术出身,基本是程序写的好就去带团队,但是,想想管理的本质是什么?

个人愚见:管理就是管人,带人就是带人心。右军大神曾经有一篇谈论软件质量的文章,提到一个理念:“团队的 Leader 不重视质量,你的团队就不会重视质量”,这个道理也适用于管理团队。

“你希望你的团队是什么样子,你的团队就是什么样子”,正所谓“兵怂怂一个,将怂怂一窝”。

那么,大家可能就会问了,我当然希望我的团队是富有战斗力的强大的团队,你说的这些我也都懂,但是到底应该如何做呢?

成为合格的团队领导者


如何管理团队?我主要想谈一谈一些软技能方面,如何成为一个合格的团队管理者,主要有以下几个方面需要注意。

成为聚焦答案的管理者


作为团队的 Leader,首先要学会倾听,努力创造与团队成员沟通的宽松环境。

遇到问题,要就事论事,不要纠结后者苛责问题是如何开始和进一步发展的(这个不是说不要关心问题的产生原因,而是可以通过解决问题之后的复盘,找到问题发生的根本原因,形成改进项),尽量要采用“聚焦答案”的方法,关注问题是如何被解决的。

也就是说更多地专注于如何找到解决问题的方案,可以通过提问的方式帮助员工找到问题的答案,而不是直接告诉他们怎么做。

另外,作为团队的领导者,需要转变思路,从命令的发出者转化为团队的服务者,团队领导者的任务是帮助员工找到解决问题的方案并且利用自己的资源优势帮助团队成功。

要对团队成员进行关怀,通过 1:1 talk 等方式与团队成员建立良好的沟通渠道和反馈渠道,了解他们的诉求、困惑甚至抱怨,找到帮助他们的方法。

例如,可以每天用 10 分钟时间,跟从未向你求助或者反馈过问题的人进行沟通。

帮助团队成员提升领导力


我们在带团队尤其是技术团队的过程中,都会遇到各种各样的问题,比如说缺乏组织,缺少沟通,角色和职责划分不明确等等。

也有些人会抱怨说团队里面没有一流的人才,没有能独挡一面的人。但是,我认为这都不是团队效率低下的根本原因,与其他原因比较,最大的原因是团队缺少正能量,缺少领导力。

那么我们来看看什么是领导力:

  • 责任感、主人翁意识
  • 执行力、崇尚行动
  • 创新力、化繁为简
  • 勤回顾、自我批评
  • 多付出、赢得信任
  • 肯钻研、刨根问底
  • 重交付、达成业绩
  • 有气量、选贤育能

下面,我们就这几个方面来做一一的解读:

责任感、主人翁意识


所谓主人翁意识,就是他们会从长远考虑,不会为了短期业绩而牺牲长期价值,他们不仅仅代表自己的团队,而是代表整个公司行事,他们从不说“那不是我的工作”。

他们往往以一腔热忱维护自己的主张,为他们认为有益于业务发展的理念而努力。公司的成功需要领导者长期倾注大量心血,是他们责无旁贷的利益所在。

有些人可能会说,我非常符合上面所描述的情形,我做事亲力亲为事无巨细,我为团队和公司呕心沥血,但是,团队还是没有起色,大家好像都无所事事,或者小心翼翼。

这是对主人翁意识的过度运用,他们在工作中投入了大量的心血,以至于剥夺了他人的发展机会,事无巨细,一管到底,往往会在团队合作的过程中起到相反的作用。

而没有责任心和主人翁意识的人,对有些事,“事不关己,高高挂起”。完全就是上班挣钱;如果看到有任务需要完成或者有不足之处可以改进,他们就想当然地认为会有其他人来管。

因此,团队管理就是要努力地培养大家的责任感,主人翁意识,想做到这一点,就需要增强团队成员的参与感,让他们知晓并理解所做事情的价值、来龙去脉,不断地强化使命感。具体的做法有以下几点:

构建全栈小团队

现在很多公司和团队强调全栈工程师,这固然好,但是对于初创团队或者说非知名的公司,这一点很难做到。

公司的背景和经济能力都不足以支撑招聘全栈工程师的成本,大家对全栈工程师的理解不同,这里不做纠结,因为笔者曾经服务于亚马逊,因此心中的全栈工程师还是非常牛 X 的。

这就需要我们退而求其次,没有全栈工程师,就打造全栈团队,进而努力培养自己团队的全栈工程师。

根据“康威定律”,软件架构是由组织的架构决定的,因此按照贝索斯“two-pizza”团队的理论和敏捷方法,构建小的团队,可以有效减少沟通成本,有利于团队的自治。

我们通过让一个小的团队有比较全面的建制,Leader(往往是团队的架构师,熟悉业务和技术)+ 前端工程师 + 后端工程师,往往可以能够比较独立地承接一个或者几个业务 silo 的工作。

这样团队成员整体负责一个或者几个业务模块,可以极大地提高团队成员的参与感、使命感和责任感,团队成员相互帮助,高度自治,形成一个具有共同利益的小团体。

大家要么一起成功,要么一起失败,正如下图所示,我们团队的划分,是按照业务线划分的:

当然,随着业务的复杂度的增加,可以按照业务/子业务线的方式来划分团队,我们并不是绝对的扁平化,而是严格遵循 two-pizza 原则。

业务的汇总一般发生在 VP,有时会在 Director 级别,业务线的划分常常按业务细分,技术团队要负责支持全部业务线。

因此技术团队的划分通常按系统或者是业务,Two pizza 团队的原则在组织层级的任何部分都适用,当人数过多时,必须继续拆分。

崇尚行动,执行力


执行力和行动力是一个团队是否能够获得成功的必要条件。因此必须在团队中树立行动的意识,所谓“停止空谈,马上行动”。

我们的团队没有大多数公司的所谓架构师、测试和运维的角色,通过为团队提供自动化运维和自动化测试的平台和工具,让开发人员负责软件开发生命全周期。

事实上,只有研发才真正知道系统如何部署、如何调试、如何监控。我们的架构师也是开发人员,大部分都 assign 到了各个业务团队,我们更加崇尚“开发参与架构设计,而不是架构师参与开发”的理念。

“吃自己的狗粮”也是我们比较推崇的文化,全团队构建运维的意识,避免开发完功能就万事大吉的思想。

另外,引入了 Amazon 的”臭名昭著“的 On-Call 制度,从而让团队所有人能够比较全面的了解系统的各个部分,能够做到相互补位,避免”这不是我的事情“的情形发生。

勤回顾、自我批评


做的越多,可能错的也越多,回顾不是找责任,复盘的目的是为了找到切实可行的解决方案,避免再犯。

通过建立智能报障系统,围绕智能报障建立起自动的问题反馈机制,将严重的问题记录到 COE 系统,逐步形成改进项,形成开发、运维和运营的闭环,团队整体自改进。

多付出、赢得信任


团队成员彼此信任是非常重要的,尤其是团队中比较资深的人。由于按照业务和 two-pizza 原则切分团队之后,随着系统复杂度的增加,跨团队的沟通越来越多。因此,成员对于事情的推动力就显得非常重要。

另外,一旦涉及到系统间、服务间以及团队间的合作,问题就会复杂起来,因此,将复杂的问题分解、简化,用简单直接的方法解决复杂问题的能力,也就变得尤为重要。

我们要帮助大家建立这种能力,避免过度设计或者过度承诺。团队的领导者要作为团队的标杆,鼓励团队知识分享,建立学习型团队。

交付、达成业绩


对于团队来讲,对于目标的强烈关注,可以让成员更加的专注结果,通过过程的可视化,让研发过程对于团队成员整体可见,有利于控制项目风险。

通过可量化的指标对过程和结果进行有效地评估,可以有效地降低产品和项目交付的风险,再辅以进度的合理追踪和结果的定期回顾,让团队意识到自己的问题,在未来的过程中持续改进。

有气量、选贤育能


领导力准则不光要在团队中塑造,也需要应用到日常的招聘当中,在招聘新人的过程中,不能够只盯着候选人有什么经验,会什么框架,也需要着重考量他们的综合素质。

一个领导力好的候选人,能够非常快速地融入团队,也能够非常快的学习一些知识。

建立合理的职级体系和绩效评价体系

建立员工个人发展计划





我们鼓励团队中资深的成员带新人,这样有利于知识的分享以及风险的降低,我们还逐步建立导师制度,而导师制度是团队中资深人员进一步晋升的重要量化考核指标。

我们还建立了个人发展计划制度,见下图:

任职资格


我们还是在逐步建立自己的任职资格体系。一方面,帮助 HR 和用人部门在招聘以及晋升的工作中建立一个明确的标准;另一方面,也希望团队成员明确自己在团队中的位置,明确如果希望晋升,团队对个人的要求以及个人需要对团队做出怎样的贡献。

下面这个模型参考了《技术管理之巅》这本书中的内容。

总体来说,任职分为专业序列和管理序列,这里我只列出了技术序列的职级列表和能力级别。

根据不同的职级范围,我们总结了每个职级的具体要求以及如何做,才能晋升到下一个级别,这里主要都是软实力和交付的体现。

因为我们认为,必要的架构能力、设计能力以及编程能力,是每个级别的成员都应该具备的。

我列举一下 SDEIII(P7)的职级要求以及晋升标准,如下图:

之所以建立每个职级的相应标准,一方面是为了配合个人发展计划 IDP;另一方面,也是告诉他们如何正确的做事和做正确的事。

建立人才库,进行必要的人才盘点

人才九宫格 - 人员盘点利器





随着团队规模的扩大,团队中的成员一定需要区分梯度,下面引用业界比较流行的"人才九宫格“并根据自己的实际情况,总结了我们自己的人才九宫格:

图中,按照潜力和业绩两个维度,将人才进行了不同维度的区分,其目的是找到团队中绩效好,有潜力的成员,着重培养,也就是所谓的核心人才。

对于潜力和业绩低于预期的成员,加以督促改进甚至淘汰并维护好稳定性人才,保持团队稳定性,而对于明星人才,需要加以晋升。

员工激励


最后,我们来谈谈人员激励。对于激励,有很多的讨论,那么到底如何激励员工呢?靠薪酬和股票?不然,对于公司尤其是创业公司来讲,不可能为人才付出绝对数值的薪水,至于期权,我只能呵呵了。

那么,到底如何做呢?也就是在资源有限的情况下,如何激励团队成员呢?我认为建立具有正能量的团队氛围尤为重要。

建立团队文化

一般而言,企业需要盈利,一定是业务导向的,很少有工程师决定一切的企业文化。

因此建立所谓的工程师文化太过理想化,但是,建立“尊重工程师文化”的团队确实是切实可行的:

  • 我们鼓励团队的 Leader 和领导跟下属定期进行一对一的沟通,称之为 1:1 talk,从而确保团队成员尤其是核心成员的想法和诉求得到一定程度的满足。
  • 给每个成员充分的授权,也就是管理者要充分地相信自己的团队,如果大方向没有问题,即使有一点绕路,也不要过分的干预,防止”微观管理“,事无巨细,还记得主人翁意识的过度运用么?
  • 团队成员要尽可能地分享自己的知识和想法,大家互相学习,也通过分享能够总结自己学习过程中零散的知识点。
  • 团队的管理者在遇到问题的时候,要聚焦答案,就事论事,不要过分诘责,要与团队一起找到问题的解决方案,不要过分的纠结事情是如何发生的。
  • 要传递正能量,有效地解决团队成员以及团队之间的分歧,而不是制造矛盾,可以参考关系阶梯法。

绩效考核

赏罚分明,避免大锅饭,非常有必要。绩效考核有多种方法,可以是 KPI 也可以是 OKR,但是不要太过追求形式,主要的目的还是帮助团队成员成长。

下图为我们简化过的团队 KPI 的考核方式,明年随着团队业务逐渐稳定,我们会逐步用 OKR 的考核方式替换 KPI。

末位淘汰


对于绩效不好的员工,而且无法有效改进的,需要进行末位淘汰,防止带来团队负能量。

总结


管理就是管理人和人心,管理其实是“脏活、累活”。

帮助团队成员建立领导力,从而提高团队凝聚力和执行力。

建立人才盘点机制,明确核心人员,重点关注,保持团队稳定性。

建立宽松的团队文化,尊重、放权、解决矛盾、有效沟通、合理衡量。

王东,创业公司 CTO,负责公司大数据平台、微服务框架以及 DevOps 平台的研发工作; 毕业于天津大学,毕业后一直从事软件相关研发和架构设计工作,曾在普元软件任资深架构师、IBM GBS 任咨询经理、亚马逊任架构师等,后加入创业公司,从事研发和管理工作; 热爱编程,喜欢钻研新技术,对于微服务、企业架构、大数据以及 DevOps 有浓厚的兴趣。