在某一线互联网公司的任职生涯马上就要结束了，回想起来，从 16 年校招加入，到今年年初离职，在这快三年的时间里，公司在飞速地发展和变化，我也从一个刚入职场的初级后台开发成长为带着十来个人团队的小组长。这几年遇到了很多事，认识了很多人，也学会了很多道理，无论是技术水平还是管理能力都得到了很大的锻炼和提升。近来无事，正好总结一下这几年工作，特别是团队管理方面的几点感悟和体会，一来方便日后翻阅，二来要是能够给大家带来一些有意义的参考和借鉴，那也是极好的。
回顾这几年
在公司飞速发展和变化的大环境下，总是充满了机遇和挑战。一个想法从提出到落地，再到发展为一个重点项目，整个过程都是极快的。当然了，前提一定是这个想法要有价值并得到领导的认可和支持。16 年校招加入公司时，我有幸加入了一个业务覆盖范围迅速扩大、领导高度重视并且组员都非常 nice 的高速成长、极具潜力的项目组。
更加幸运的是，我加入时整个项目在经历了几次电商大促的考验后已经日渐趋于稳定，正处于业务覆盖范围迅速扩大、系统承载流量高速增长的关键阶段。在这关键阶段，最为重要的事情除了保证业务需求正常推进外，便是系统架构优化升级、不同业务领域的功能解耦、底层数据优化和独立等一系列自研需求。
为了保证系统在流量迅猛增长的情况下依旧有优秀的性能表现和较高的稳定性，原有的两三个系统从架构优化、关注点、业务覆盖范围及业务性质等多方面进行了拆分、重构与升级，逐步演变为现在由搭建系统、渲染系统、数据系统、国际化等众多子系统共同组成的“大系统”。有幸参与其中，让我对如何搭建亿级流量的电商后台系统有了清晰深刻的认识，也为我后来独立带团队打下了坚实的基础。
在公司的这几年可以清晰地划分为两个阶段。入职的第一年，主要是参与了很多业务需求和系统架构优化等自研需求的开发，在系统架构设计及优化方面收获颇丰。后面才开始慢慢带团队，才有了今天要重点讲的团队管理方面的心得和体会。
团队管理的心得和体会
由于我带的团队负责的项目，在部门里算是一块相对独立的新业务，所以团队内的大部分事情基本上都由我来直接负责。从新人招聘、培训到业务需求跟进，再到电商大促备战等，基本上都亲力亲为。在这个过程中，我深刻地认识到了，在以业务需求为驱动和导向的大环境下，根据组员技术水平、擅长的技术点、以往项目经历等合理分配开发任务，并保证业务需求按时保质保量完成，只是一个合格组长的最基本要求。除此之外，你还需要考虑团队文化建设、团队技术水平提升、团队稳定性、如何做好上通下达等方方面面。一路走来，踩了很多坑，也学到了很多知识，对于管理团队也有了很多自己的心得体会，下面就讲讲我认为比较重要的几点。
团队文化听起来很虚，但是真的很重要
看过一句话：对于一个企业而言，决定短期的是技巧，决定中期的是战略，决定长期的是文化。我想，对于一个团队来说，亦是如此。几乎每个企业都有自己独特的企业文化，对于每个团队来说，也应该有自己的团队文化。
团队文化，一听起来就感觉假大空，其实，我们可以换一个名词——团队氛围。我认为，一个团队的氛围好坏和团队文化有着密切的关系，甚至可以理解为，团队文化是内在本质，而团队氛围是外在表现。 那怎么样的团队文化才算是一种好的文化？
我认为，团队文化是否独特，是否彰显个性，并不重要，重要的主要是两方面。一方面，团队文化要得到团队内大多数人的认可，例如：某个团队宣扬，如果家庭生活和工作无法平衡，你可以选择离婚。我想，这样的团队文化，即使表面上没人反对，但是绝大多数人心里都是不认可的，这就不是一种好的文化。
另一方面，这个文化说起来可以很抽象，但是必须有具体的例子可以参照或者可以具体实施。那些只能意会、言传，不能落实到实际行动的文化，都未免有点假大空的嫌疑，正向效果也不显著。例如：某个团队宣扬，大家要有激情、要奋斗、要勇于为公司未来奉献青春，这些当做口号还行，喊着确实振奋人心。但是，振奋之后呢？冷静下来想一下，怎么做才算有激情？怎么做才算奋斗？怎么做才是为公司未来奉献青春？这种就很虚，除了喊的时候激情澎湃，真正作用却不大。
做好上通下达，拒绝越级上报
作为一个管理者，特别是金字塔最底层的管理者，做好上通下达非常重要。你要让你的组员清晰地知道，一方面，上层领导传达下来的事情，你一定会及时地周知到大家，在你正式周知前，组员间尽量不要讨论道听途说来的消息；另一方面，每个组员的努力、付出、成果与个人诉求等，你都会在评优选先或其它恰当的时机和上层领导如实反馈，绝对不会埋没大家的声音。
让自己成为一个承上启下、上通下达的中间桥梁，让双方都能够及时顺畅地交换信息，当然了，适当地过滤、加工也是非常有必要的。
在这种大前提下，实践中我发现，将上层领导的消息传达给组员相对来说比较容易，你可以采用晨会、周会、一对一私聊等多种方式进行沟通。但是，将组员反馈的信息在恰当的时机同步到领导那里，处理起来就要视时机、视具体内容、视领导处事风格等多种因素综合考量。
一般来说，归属上层领导的最底层的员工数量众多，领导平时也有很多事情要处理，如果你每个组员的每件事都要反馈的话，难免对领导造成骚扰，但是，如果你什么都不反馈的话，又没有做好上通这个点。以如何反馈组员成果为例：如果有很突出的表现或者很强有力的数据佐证，这种可以直接抄送上级领导和组内同学，并加上你对组员成果的认可和激励。
但是，这种事情并不多，大家平时工作内容更多的是普通的业务需求、自研需求，也是我们常常自嘲的“增删改查”，那这种工作应该怎么总结或反馈呢？我一般是鼓励组员写月度总结、季度总结、年度总结等，特别要注意的是，这类总结必须要认真对待，认真写。如何让大家认真对待，其实方法很多，例如：可以找个时间让大家每个人都把自己的总结讲一下，总结要抄送组内所有人，组长要做个带头作用等等，我就不展开说了。
当你把这类总结的事情贯彻落实后，你就会发现作用很强大，用途也很多。如果组员很多的话，作为组长在月末的时候，很难做到很清晰地了解每个人这个月都做了什么，甚至是对于组员自己来说，也极有可能对自己这个月做了什么很模糊，这个时候月度总结就非常有帮助了，另外，你还可以择优抄送上级领导和组员。
而季度总结、年度总结，可以尽量让组员做成 PPT 汇报的形式，一方面，可以锻炼组员的总结、表达与沟通等能力；另一方面，还可以邀请上级领导参加，也可以选在绩效评定、升职加薪评定等时间点前，会带来诸多好处和便利。大家都知道，研发一般加班较多，常常总结才能清晰地让自己、同事与领导都知道你做了些什么有价值有意义的事情。
其实，做好了上面说的几点，做好了上通下达，也就不存在越级汇报的情况了。
注重培养归属感、责任感与主动性
说实话，自私确实是人的天性，不是自己的东西，很难谈什么责任感，更不用说主动性了。所以，我们才要强调培养主人翁意识，即培养归属感，这是后两者的前提和基础。那么，怎么培养归属感，怎么培养主人翁意识呢？
你可以将系统、业务范围等根据组员的兴趣点、以往项目经历等多种因素划分给指定人负责，并明确赏罚机制。要清晰地传达一种思想，那就是：这块东西就是你的，干好了评优、升职、加薪等都会优先考虑；干不好，出事情了，你要负责，我也会负责。有了归属感，责任感也就自然有了，当然了，前提是他要是一个负责的人。
而对于主动性，就需要多多鼓励、慢慢培养了。这个主动性呢，一言以蔽之，就是主动规划或者做了一些除了你安排下去的任务之外的，对他负责的那块未来有意义有帮助的事情。
建立 backup 机制
backup 机制，即互备机制，就是尽量让组内的每一个人都有一个或多个备份存在，特别是在组内发挥重要作用的人。直白点说，就是尽量要让组内的任何一个人都是可替代的，当然了，这里面也包括你自己。要尽量达到一种状态，那就是如果突然某天某个人不在组内了，这个小组以及负责的业务必须能够保证正常运转。
为什么要这么做呢？首先，我们任何一个人都无法保证“7*24小时”随时待命，那么，我们假设在某个时间点，有一块线上业务出现问题，而熟悉这块业务的只有一个人，这个人又恰巧不在公司且无法远程支持，那这个问题处理起来就会非常棘手。但是，如果除了这个人外还有一个或多个熟悉这块业务的人在，那情况就不一样了。
其次，我们都知道互联网从业人员跳槽频繁，万一某一天某个人离职了，如果这块业务只有他熟悉，那必然会造成交接成本升高，交接后的隐患也会更多。所以，其实很多公司都要求中高层的管理者，上任之后必须在规定的时间内培养一个或多个可以接替自己工作的人。对于最底层的小团队来说，也是一样的，只有尽最大努力贯彻落实 backup 机制，才能在最大程度上保证团队及业务的稳定性。
灵活的“7*24”，而不盲目推崇固定的“996”
谈到 996，其实有很多互联网公司是强制规定上下班时间的，强制大家执行 996。从我加入公司到现在，并没有遇到公司强制要求 996 的情况，至少我所在的部门还没有强制推行。偶尔项目比较忙的时候，995 还是有的，周末或节假日过来加班也是有的。
相对于 996，我更喜欢和提倡灵活的 7*24，这里并不是指大家要一周 7 天 24 小时一直工作，而是说，无论什么时间，是工作日还是休息日，是白天还是晚上，如果公司有事情需要你支持，例如：紧急的线上问题、紧急的需求开发等等，而你又比较方便的情况下，能够随时赶到公司或者在家远程支持。
对于加班这件事呢，我一般都是提倡：事情多的时候，大家就辛苦点，多加点班；事情少的时候，大家就早点回家，多休息休息，养精蓄锐而不是在公司干耗着混加班时间。如果休息日有特殊情况，需要大家牺牲自己休息时间来支持的，我们可以后续找一些恰当的时间请个调休假补偿。
目的其实只有一个，让大家保持热情，线上出现问题时能够积极及时处理，而不是用固定的 996 把大家搞得很疲惫，结果休息日出现问题的时候，没有人愿意支持处理。毕竟对于电商类产品来说，休息日也是用户使用量较高的时间，保证良好的用户体验也是非常重要的。
流程、规范与稳定高于一切
要保证团队稳定、业务稳定，那这个团队就一定要制定属于自己的流程和规范。每件事情都要按照指定的流程走，比如上线功能就必须按照测试、灰度、全量等流程走，任何步骤都不允许跳过；每件事都要按照指定的规范来，比如文档资料要按照统一的格式来，而不是随心所欲。
我们要清晰地认识到，很多线上事故都是执行者未按照流程、规范操作导致的，如果执行者按照流程、规范来做，至少能够降低事故的负面影响。
崇尚技术深度，而不盲目崇尚新技术
作为一名研发人员，技术自然是大家的安身立命之本。很多研发人员都喜欢研究新出现的前沿新技术，不是说这样不好，而是说，深度地学习和掌握工作中常用的现有技术才是更加重要的。一方面，我们要清晰地认识到好多线上问题都是因为对现有技术理解有偏差或者对用法掌握不到位导致的；另一方面，新技术在稳定性上往往有待验证，自己玩玩是可以，但是用在重要的项目上基本上不可能，万一出现问题，后果是非常严重的。记住，永远都不要拿项目的稳定性开玩笑。
技术成长与业务需求相结合，产品需求和自研需求相结合
好多人抱怨我平时只是在做“增删改查”，毫无技术含量，更不要扯什么技术水平提升了。我觉得，并不都是这样，好多业务需求还是很需要架构设计和细节把控的。技术和业务相结合，技术才有了价值，如果只会技术，那岂不是成了纸上谈兵。
另外，作为组长，一定要控制下产品需求的进度和占比，尽量留出一些时间用来做自研需求。毕竟随着系统中的功能越来越多，重构和优化往往是难以避免的，特别是那些比较急的需求很有可能采用了很暴力的设计和开发，是必须要尽早填上的坑，不然后患无穷。
团队管理的小技巧
做好新人培训
无论是工作多年的职场老手，还是刚入职场的应届生，在刚刚入职的那段时间都像一张白纸。他经历了怎样的新人培训，很大程度上影响着他未来在公司工作的态度和方式。另一方面，新人培训的好坏以及是否规范，也直接影响着新人对公司的第一印象。
所以，新人培训是非常重要的，要认真谨慎对待，下面是我认为几个比较重要的点：
- 流程规范培训要优先于技术培训：技术水平不行，可以慢慢学。但是，流程和规范一定要第一时间好好培训和指导。一旦某种不好的习惯养成了，后面再改就很难了。新人引发的问题中，很多都是由于操作不按照流程，不遵守规范导致的。
- 老人踩过的坑，新人也很有可能会踩：每个团队都应该整理一份“踩坑手册”，记录一下以前踩过的坑，遇到的线上问题及对应的分析总结。然后，每个新人入职时，都把这些常见的坑提前多熟悉几遍，不要求全都一一记住，至少要在脑海中留个印象，能够极大地降低踩“同类坑”的几率。一个人踩过的坑，尽量让整个团队的人都不要再掉进去了。
- 明确新人熟悉系统、技术等的顺序和进度安排：千万不要和新人说，我们需要用到 A、B、C 与 D 等等，你自己去看吧。最好可以制定一个合理的熟悉顺序和进度安排，明确好每天熟悉什么，几天熟悉完。你要知道，正确的熟悉顺序确实可以帮助新人提高效率，加快上手速度。另外，不要忘记，任务以及对应的 deadline 才是第一生产力。
- 一对一导师制：尽量不要和新人说，组内每个人都很 nice，有问题随便问任何人都可以。尽量安排一对一的导师，这种方式效果更好。
- 新人手册：每个团队尽量都要有一份新人手册，可以大家一起维护编辑。这样同一件事情就不用和 N 个新人说 N 遍了，大家自己翻阅即可，有问题再找带你的导师问。极大地节省了大家宝贵的时间，也方便在以后遗忘时查阅。
巧用主题池，做好团队技术分享
团队技术分享的好坏和分享主题的选择有着极大的关系。那么，什么样的分享主题才算是一个好主题呢？我认为，最重要的一点就是，分享主题要尽量和平时工作有点关联，可以是平时用到的技术点的深入研究，也可以是同类技术的横向对比。可以维护一个技术分享的主题池，每个人可以把自己想知道的问题点、技术点加到池子中，组长来做统一的把关和过滤，每个人分享的时候，一定要在过滤后的池子里面选。这样，既有一定的灵活性，可以让组员自由选择分享主题，又能在一定程度上控制好主题选择的范围，保证主题都是大家想知道和了解的，对大家工作和技术提升有意义的。
建立时间线记录，辅助排查线上问题
当出现线上问题时，第一要务是要尽快找到问题原因，尽快修复问题。那么，如何快速定位到问题原因呢？总结分析了很多线上问题后，我发现了一个规律。
首先，我将线上问题分为以下两类：
- 主动类问题：由研发人员主动操作引发的问题，我叫做主动类问题，也就是由功能上线、修改配置、修改开关状态等引发的问题。
- 被动类问题：不是由研发人员主动操作引发的问题，我叫做被动类问题，即由用户访问量激增、非研发人员的常态化操作等引发的问题。
我所说的规律就是：无论哪种类型的问题都是与时间强相关的。例如，如果你刚刚完成系统的上线发布，而后发现出现了线上问题，这个问题的出现时间又恰巧和你的发布时间相吻合，那么极大概率就是这次上线引发的问题。再例如，我们每年都非常关注的双十一大促，每到 0 点的时候，各系统的流量必然会达到一个峰值，而这个时候也是最容易出问题的时候。
那么，应该如何应对这两类问题呢？
针对主动类问题，建立时间线记录。将团队内的每一次功能上线、修改配置、修改开关状态等一切可能影响线上系统状态的操作都记录下来。记录内容可以简单地写一下操作时间点及操作内容概述，大家一起负责维护和编辑。这样，一旦发现线上问题，第一时间看一下问题的发生时间点附近是否有研发人员主动操作了什么。如果有的话，大概率和这些操作有关，能够较快地定位问题原因。
针对被动类问题，因为我们无法控制用户、非研发人员的行为，所以只能靠预测和演练。例如，双十一之前我们可以按照预测的流量进行演练、压测等。再例如，如果系统运行得好好的，突然出现线上问题，而出现问题的时间点在时间线上又找不到对应的主动操作，那么可以关注下该时间点用户访问量，系统调用量是否存在波动，是否由于非研发人员的操作导致。
结语
起初只是想简单总结记录一下，没想到洋洋洒洒写了这么多。说实话，我做管理的时间也不长，有些想法也没有深入去实践，难免有些偏颇和误差，欢迎大家随时交流和指正。 我在该公司这三年来得到的锻炼和成长，要由衷感谢一路走来的领导、同事与朋友。大家都非常优秀，无论是工作上还是生活上，都给我很多的帮助和指导，让我获益匪浅。感谢这三年时光里的每一个人，每一件事，每一个难忘的瞬间。
作者介绍
秋梦尘，一线互联网公司后台核心研发工程师，立志成为一名优秀的架构师和研发管理者。