最近中生代技术群发起北京闭门会议，主要的讨论议题就是如何做团队管理，本人有幸参加这个闭门会议并且做了一些粗浅的分享，这里给做一个总结和回顾。
从3年前离开亚马逊到现在，也在不同的公司混了一圈，虽然本人自诩为程序员老司机，但是由于工作的需要，从2014年开始就开始从事管理工作，虽然之前也带团队，但是一直不是管理的title。做管理两年以来，有很多的心得和体会，经常反思之前作为团队成员的一些想法和做法，发现，其实管理是一门很深的学问，以前没做管理，不太理解的一些事情，现在也能慢慢理解了。
言归正传，我们还是谈回这篇文章的主题——管理。
首先，我们来谈谈什么是管理。
国内大多数公司的中层乃至高层的技术管理，一般都是技术出身，基本是程序写的好就去带团队，但是，想想管理的本质是什么?个人愚见，管理就是管人，带人就是带人心。右军大神曾经有一篇谈论软件质量的文章，其中提到一个理念，就是“团队的leader不重视质量，你的团队就不会重视质量”，这个道理其实也适用于管理团队——“你希望你的团队是什么样子，你的团队就是什么样子”，正所谓“兵怂怂一个，将怂怂一窝”。那么，各位看官可能就会问了，我当然希望我的团队是富有战斗力的强大的团队，你说的这些我也都懂，但是到底应该如何做呢?
我们在带团队尤其是技术团队的过程中，都会遇到各种各样的问题，比如说缺乏组织，缺少沟通，角色和职责划分不明确等等，也有些人会抱怨说团队里面没有一流的人才，没有能独挡一面的人，但是，我认为这都不是团队效率低下的根本原因，与其他原因比较，最大的原因是团队缺少正能量，缺少领导力。那么我们来看看什么是领导力。
培养团队成员的领导力
领导力有很多方面，根据十几年的混迹于大公司和创业公司的经验，我把领导力总结为如下几个方面：
- 责任感、主人翁意识
- 执行力、崇尚行动
- 创新力、化繁为简
- 勤回顾、自我批评
- 多付出、赢得信任
- 肯钻研、刨根问底
- 有气量、选贤育能
- 重交付、达成业绩
下面，我们就这几个方面来做一一的解读：
责任感、主人翁意识
所谓主人翁意识，就是他们会从长远考虑，不会为了短期业绩而牺牲长期价值，他们不仅仅代表自己的团队，而是代表整个公司行事;他们从不说“那不是我的工作”。他们往往以一腔热忱维护自己的主张，为他们认为有益于业务发展的理念而努力。公司的成功需要领导者长期倾注大量心血，是他们责无旁贷的利益所在。
有些人可能会说，我非常符合上面所描述的情形，我做事亲力亲为事无巨细，我为团队和公司呕心沥血，但是，团队还是没有起色，大家好像都无所事事，或者小心翼翼。其实，这是对主人翁意识的过度运用，他们在工作中投入了大量的心血，以至于剥夺了他人的发展机会，事无巨细，一管到底，往往会在团队合作的过程中起到相反的作用。而没有责任心和主人翁意识的人，对有些事，“事不关己，高高挂起”。完全就是上班挣钱;如果看到有任务需要完成或者有不足之处可以改进，他们就想当然地认为会有其他人来管。
因此，团队管理就是要努力地培养大家的责任感，主人翁意识，想做到这一点，就需要增强团队成员的参与感，让他们知晓并理解所做事情的价值、来龙去脉，不断地强化使命感。具体的做法有一下几点：
构建全栈小团队
现在很多公司和团队强调全栈工程师，这固然好，但是对于初创团队或者说非知名的公司，这一点很难做到，公司的背景和经济能力都不足以支撑招聘全栈工程师的成本(全栈工程师大家的理解不同，这里不做纠结，因为笔者曾经服务于亚马逊，因此心中的全栈工程师还是非常牛X的)，这就需要我们退而求其次，没有全栈工程师，就打造全栈团队，进而努力培养自己团队的全栈工程师。
全栈小团队
根据“康威定律”，软件架构是由组织的架构决定的，因此按照贝索斯“two-pizza”团队的理论和敏捷方法，构建小的团队有利于团队的自治，我们通过让一个小的团队有比较全面的建制，Leader(往往是团队的架构，熟悉业务和技术)+ 前端工程师 + 后端工程师，往往可以能够比较独立地承接一个或者几个业务silo的工作，这样，团队成员整体负责一个或者几个业务模块，可以极大地提高团队成员的参与感、使命感和责任感，团队成员相互帮助，高度自治，形成一个具有共同利益的小团体，大家要么一起成功，要么一起失败，正如下图所示，我们团队的划分，是按照业务线划分的。
按业务划分团队
当然，随着业务的复杂度的增加，可以按照业务/子业务线的方式来划分团队，我们并不是绝对的扁平化，而是严格遵循two-pizza原则。
大团队的拆分方式
崇尚行动，执行力
执行力和行动力是一个团队是否能够获得成功的必要条件，因此，必须在团队中树立行动的意识，所谓“停止空谈，马上行动”。
执行力
我们的团队没有大多数公司的所谓架构师、测试、和运维的角色，通过为团队提供自动化运维和自动化测试的平台和工具，让开发人员负责软件开发生命全周期;事实上，只有研发才真正知道系统如何部署、如何调试、如何监控;我们的架构师也是开发人员，大部分都assign到了各个业务团队，我们更加崇尚“开发参与架构设计，而不是架构师参与开发”的理念。“吃自己的狗粮”也是我们比较推崇的文化，全团队构建运维的意识，避免开发完功能就万事大吉的思想;另外，引入了Amazon的”臭名昭著“的On-Call制度，从而让团队所有人能够比较全面的了解系统的各个部分，能够做到相互补位，避免”这不是我的事情“的情形发生。
回顾、自我批评
做的越多，可能错的也越多，回顾不是找责任，复盘的目的是为了找到切实可行的解决方案，避免再犯。
赢得信任
团队成员彼此信任是非常重要的，尤其是团队中比较资深的人。由于按照业务和two-pizza原则切分团队之后，随着系统复杂度的增加，跨团队的沟通越来越多，因此，成员对于事情的推动力就显得非常重要;另外，一旦涉及到系统间、服务间以及团队间的合作，问题就会复杂起来，因此，将复杂的问题分解，简化，用简单直接的方法解决复杂问题的能力，也就变得尤为重要，我们要帮助大家建立这种能力，避免过度设计或者过度承诺。团队的领导者要作为团队的标杆，鼓励团队知识分享，建立学习型团队
交付、达成业绩
对于团队来讲，对于目标的强烈关注，可以让成员更加的专注结果，通过过程的可视化，让研发过程对于团队成员整体可见，有利于控制项目风险，通过可量化的指标对过程和结果进行有效地评估，可以有效地降低产品和项目交付的风险，再辅以进度的合理追踪和结果的定期回顾，让团队意识到自己的问题，在未来的过程中持续改进。
选贤育能
领导力准则不光要在团队中塑造，也需要应用到日常的招聘当中，在招聘新人的过程中，不能够只盯着候选人有什么经验，会什么框架，也需要着重考量他们的综合素质，一个领导力好的候选人，能够非常快速地融入团队，也能够非常快的学习一些知识。我们鼓励团队中资深的成员带新人，这样有利于知识的分享以及风险的降低，我们还逐步建立导师制度，而导师制度是团队中资深人员进一步晋升的重要量化考核指标。
任职资格
任职资格的理论我就不讲了，也不是这块的专家，当时，我们还是在逐步建立自己的任职资格体系，一方面，帮助HR和用人部门在招聘以及晋升的工作中建立一个明确的标准，另一方面，也希望团队成员明确自己在团队中的位置，明确如果希望晋升，团队对个人的要求以及个人需要对团队做出怎样的贡献。
下面这个模型参考了《技术管理之巅》这本书中的内容。
任职资格模型
总体来说，任职分为专业序列和管理序列，这里我只列出了技术序列的职级列表和能力级别。根据不同的职级范围，我们总结了每个职级的具体要求以及如何做，才能晋升到下一个级别，这里主要都是软实力和交付的体现，因为我们认为，必要的架构能力、设计能力以及编程能力，是每个级别的成员都应该具备的，这里，我列举一下SDEIII(P7)的职级要求以及晋升标准。
任职资格要求
人才盘点
随着团队的规模的扩大，团队中的成员一定需要区分梯度，下面引用业界比较流行的"人才九宫格“并根据自己的实际情况，总结了我们自己的人才九宫格：
人才九宫格
图中，按照潜力和业绩两个维度，将人才进行了不同维度的区分，其目的是找到团队中绩效好，有潜力的成员，着重培养，也就是所谓的核心人才;对于潜力和业绩低于预期的成员，加以督促改进甚至淘汰并维护好稳定性人才，保持团队稳定性，而对于明星人才，需要加以晋升。
对应策略
员工激励
最后，我们来谈谈人员激励。对于激励，其实有很多的讨论，那么到底如何激励员工呢?靠薪酬和股票?不然，对于公司尤其是创业公司来讲，不可能为人才付出绝对数值的薪水，至于期权，我只能呵呵了。
那么，到底如何做呢?也就是在资源有限的情况下，如何激励团队成员呢?我认为建立具有正能量的团队氛围尤为重要。
建立团队文化
建立团队文化
一般而言，企业需要盈利，一定是业务导向的，很少有工程师决定一切的企业文化，因此建立所谓的工程师文化太过理想化，但是，建立”尊重工程师文化“的团队确实是切实可行的。
首先，我们鼓励团队的Leader和领导跟下属定期进行一对一的沟通，称之为1:1 talk，从而确保团队成员尤其是核心成员的想法和诉求得到一定程度的满足;
其次，给每个成员充分的授权，也就是管理者要充分地相信自己的团队，如果大方向没有问题，即使有一点绕路，也不要过分的干预，防止”微观管理“，事无巨细(还记得主人翁意识的过度运用么?)
第三，团队成员要尽可能地分享自己的知识和想法，大家互相学习，也通过分享能够总结自己学习过程中零散的知识点。
第四，团队的管理者在遇到问题的时候，要聚焦答案，就是论事，不要过分诘责，要与团队一起找到问题的解决方案，不要过分的纠结事情是如何发生的。
第五，也是最重要的，要传递正能量，有效地解决团队成员以及团队之间的分歧，而不是制造矛盾，可以参考关系阶梯法。
绩效考核
赏罚分明，避免大锅饭，非常有必要。绩效考核有多种方法，可以是KPI也可以是OKR，但是不要太过追求形式，主要的目的还是帮助团队成员成长。下图为我们简化过的团队KPI的考核方式，明年随着团队业务逐渐稳定，我们会逐步用OKR的考核方式替换KPI。
KPI列表
末位淘汰
对于绩效不好的员工，而且无法有效改进的，需要进行末位淘汰，防止带来团队负能量。
总结
【本文为51CTO专栏作者“王东”的原创稿件，转载可通过作者简书(krisdwang)获取联系】
