数据北京研发中心CTO王东：如何打造有战斗力的团队

讲师简介

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

内容简介

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

王东：大家晚上好，我叫王东，来自融数数据，我今天分享的主题是：打造有战斗力的团队；

前言

对于公司尤其是技术型公司来说，人才是公司最根本的竞争力元素，因此，如何管理团队，将团队打造成有战斗力的单元，就是各个管理者所不得不面对的问题。

从3年前离开亚马逊到现在，也在不同的公司混了一圈，虽然本人自诩为程序员老司机，但是由于工作的需要，从2014年开始就开始从事管理工作，虽然之前也带团队，但是一直不是管理的title。做管理两年以来，有很多的心得和体会，经常反思之前作为团队成员的一些想法和做法，发现，其实管理是一门很深的学问，以前没做管理，不太理解的一些事情，现在也能慢慢理解了。

国内大多数公司的中层乃至高层的技术管理，一般都是技术出身，基本是程序写的好就去带团队，但是，想想管理的本质是什么？个人愚见，管理就是管人，带人就是带人心。“你希望你的团队是什么样子，你的团队就是什么样子”，正所谓“兵怂怂一个，将怂怂一窝”。那么，大家可能就会问了，我当然希望我的团队是富有战斗力的强大的团队，你说的这些我也都懂，但是到底应该如何做呢?

成为合格的团队领导者

如何管理团队？目前市面上有很多的相关理论和实操的资料，讲的都非常好。这里，我就不再赘述这些方法了，我主要想谈一谈一些软技能方面，如何成为一个合格的团队管理者。主要有一下几个方面需要注意：

成为聚焦答案的管理者

作为团队的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）的职级要求以及晋升标准。