做了六年多技术管理，聊一些经验总结

前言

我是从 2014 年开始正式走上管理之路的，在那之前虽然也有带过几个初级程序员，但毕竟不是正式的管理职位。正式踏上管理岗是从做一个小主管开始的，刚开始只管理几个人；之后担任过一些业务线的技术负责人，管理十几二十人；最多时管理百人团队，负责整个研发部门。一路从技术主管，到技术经理，再到技术总监，中间也和别人合伙创业当过 CTO。有空降管理过现成的团队，也有不止一次从 0 到 1 组建团队的经验。

六年多的管理经验，说多不多，但说少也不少，肯定也有自己的一些心得体会，如今就用文字来和大伙分享我的一些经验总结。

我打算根据管理的三个级别来聊：技术主管、技术经理、技术总监。这里所说的这三个级别，并不是指代具体的管理岗位名称，可以简单理解为技术团队中的基层管理者、中层管理者、高层管理者，具体的再一一细说。

技术主管

如刚才所说，技术主管并不指代具体的岗位，而是指初级技术管理人员，主要负责管理某一垂直技术领域，包括管理该领域的基层技术人员。比如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也称为技术组长，而且也不一定设置明确岗位。另外，在有些小公司，管理层级少，可能就没有设置技术主管的岗位，而直接挂名技术经理，比如我的第一份正式管理岗，挂名就是 App 技术经理，管理 Android 和 iOS。那时候的我其实既是基层管理者，也是中层管理者。这在小公司很正常，甚至处于初创期的 CTO，还需要同时担任高层、中层、基层所有的管理工作。

技术主管所管理的人员一般只有几个人，多的可能十几个。如果人员超过 20 人，最好对团队根据细分领域做一下拆分。比如 App 人员如果超过 20 人，那就可以拆分为 Android 组和 iOS 组，每组再分别设置一个主管，而原先的 App 主管则可以升级为技术经理。

对公司部门来说，技术主管优先考虑肯定是从内部人员中提拔，条件不满足的情况下才从外部招聘。比如，组建新团队的时候；或当前团队都只有些初级工程师，缺乏能够独当一面的人；或团队中都是些技术宅，只想专研技术，不想做管理。这些情况下，一般就需要从外部招聘合适的人选。

能荣升技术主管的，一般工作经验 3-5 年，专业技术能力已经非常娴熟，可达到资深级别，还具备一定的架构能力，能够独当一面。学习能力、沟通能力、对业务的理解能力等，也都是比较出众的。一般可以对标阿里的 P6 级别。

想要做好技术主管的工作，也不是那么轻松的。作为一名技术主管，平时大部分时间依然还是用在了技术设计、写代码、解决 Bug 等工作，这和基层的程序员没多大区别。但是，技术主管除了需要做好这些程序员本身的工作之外，还需要花时间做开发任务的分解、分配，以及代码 review、技术设计评审、面试、和团队内外的人员沟通协作等管理工作。因此，想要做好技术主管的工作，提高时间管理的能力是很有必要的。不然的话，就会把自己搞得很忙很累，最后管理工作没做好，还影响了作为程序员本身的工作。也因此，有些人就会开始退缩，不愿意当技术主管，觉得会占用自己过多的时间，平时写代码的时间都不够，哪有时间做管理。想要在管理这条路上不断往上爬，这是必须要迈过去的第一道坎。

从程序员升级为技术主管，最核心的转变就是：从管理自我到管理他人。所以，我想谈谈关于管理他人的一点经验，主要还是分享下在选人和用人上我自己的一些做法。

关于招人选人，我有一个标准，也是我最看重的一点，那就是候选人的深度思考能力。不只是技术人员，包括产品经理、UI 设计、测试人员等，我都会考察他们的深度思考能力。深度思考能力越强的人，越能看到问题的本质，各方面的能力也会越优秀。

那么，如何考察候选人的深度思考能力呢？其实也简单，多问些为什么就可以了。比如，对于应聘架构师的候选人，可以类似下面这样层层追问下去：

1. 问：你们系统采用什么样的架构？答：微服务架构

2. 问：为什么采用微服务？答：为了快速迭代

3. 问：为什么用了微服务就能实现快速迭代？答：服务间解耦，可以分小组分别独立开发、测试和部署

4. 问：分了多少个小组？每个小组多少人？为什么这么分？答：……

这些相互关联的问题，是可以不断追问下去的，问题也并非有标准答案的，也并不是考察候选人是否知道正确答案，而是考察他是否思考过这些问题，是否有自己的一些想法。当然，候选人也不可能对所有领域的问题都能答得上来，所以尽量多方面考察，并尽量从候选人所熟悉的领域进行深入。

再说说用人方面，我比较崇尚于为下面每个人的自我成长而负责。我会去了解每个人的职业规划，为他们的职业发展路线提出建议，并在工作中不断给他们提供成长的机会，包括分配的任务、提供的技术指导和培训、定期的一对一沟通，等等。其实，从本质上来说，就是为了激发他们的善意和潜能。

我做基层管理时就已经开始实践选人用人的这些方法论，而且成效还非常不错。

符合我的标准招进来的人，做事基本都是很高效的，大多都能成为团队里的骨干成员，有时还能做到远超我的预期，有着突出的表现。不过，有时候，长时间没招到合适人选或急需用人时，我只能减低标准，这时候招进来的人，则有些参差不齐了，部分人虽然也能完成任务，但成果就是不尽如人意。

也因为我用人的方式注重于他们的成长，所以，他们也很尊重我、支持我、追随我。我管理过的团队，离职率也一向比较低。

作为基层管理者的技术主管，建议重点培养自己的以下能力：

1. 专业技术能力：这是技术管理者的立身之本，肯定需要不断精进，如果技不如人，是无法服众的。

2. 业务理解能力：对业务有正确的理解，甚至能理解到业务的本质需求，才能让技术实现价值。

3. 任务分解能力：技术主管承担着开发任务分解分配的职责，如果分解不当，漏掉了一些环节，就会导致任务的延迟、质量的不可控，为项目带来了风险。

4. 时间管理能力：管理者需要在有限的时间里高效地管理多种事情，自然就需要提高时间管理能力。

5. 团队建设能力：管理者的核心价值就是打造出一支优秀的团队。

6. 向上管理能力：向上管理没做好，会影响职业的发展，但切记，向上管理并不是拍上级的马屁。

7. 领导力：领导力不同于管理力，不能靠职权，而是靠个人魅力，建议尽早培养。需要明白一点，大部分技术人员更喜欢被“领导”，而不是被“管理”。

技术经理

技术主管作为基层管理人员，更多时候只是个执行者，要求能够「正确地做事」，能够带领一线团队高效地执行上级所交代的任务。

技术经理，作为中层管理人员，主要职责则是根据高层管理所确定的目标，制定实现目标的具体计划并保证实施，还要为最后的实现结果负责。

技术经理具体的工作职责，不同公司会有所不同，但主要可能包括：制定技术规范、制定工作计划、项目整体的架构设计和架构优化、跟进项目进度、团队建设、与其他部门的协调沟通等。

对技术经理的工作年限一般要求 5 年以上，技术上对架构能力的要求高一些，本身至少也应该是个能够独当一面的架构师或技术专家，可以对标阿里的 P7 级别。不过，在具体要求上，大厂和中小厂是不一样的。大厂对技术深度的要求会更高，小厂则比较看重技术广度。但大厂基本很少对外招聘管理岗，同级别的高 P 技术岗反而会招得多。所以，大部分人只能在中小企业发展管理路线。另外，技术经理也不一定是从技术主管升上去的，也可以从高 P 的技术专家转岗的。

在管理能力上，对技术主管所要求的也同样对技术经理有要求，而且要求更高。比如，业务理解能力，技术主管更多只是停留在对业务局部的一些点和线方面，而技术经理应该精通业务，对业务应有全局观。再比如，团队建设方面，技术主管更多只是偏于对个人提供技术指导，而技术经理则需要制定具体的团队建设方案，比如制定技术培训方案，以提高团队整体的技术水平。

技术经理还有一个核心工作就是培养技术主管。如何培养呢？最核心的一点就是要懂得授人以渔，教以方法论，而不是一旦出现问题就直接帮他解决问题。技术主管上任初期普遍会存在一些不足，比如，在任务分解方面会做得不太好，经常会分解得不彻底，会导致增加很多沟通成本甚至任务延迟；面试时也不太懂得如何抓重点，会浪费很多时间；团队成员出现分歧时，也不太懂得如何妥善处理。这些都需要技术经理花时间、花精力去慢慢指导技术主管，要让技术主管明白背后的方法论，而不要简单地丢给他解决方案。

我做技术经理的时候，还担任过公司里某些业务线的技术负责人，统筹管理项目的技术研发进度，其实就是项目管理。有些公司，会设置专岗来做项目管理，一般称为项目经理。但不少公司和我一样，是由技术经理兼做项目管理的。另外，还有部分公司，会由产品经理来兼做项目管理。

其实，要做好项目管理，对业务和技术两方面都熟悉是再好不过的。毕竟，从流程来看，项目管理包含了需求、设计、开发、测试、上线五个阶段，前两个阶段是业务强相关的，后三个阶段是技术强相关的。因此，最好的项目管理人员，应该是既懂业务又精于技术的，才能更好地统筹全局。但现实情况却是这样的人比较稀少，所以，更多时候，一个项目的前两个阶段主要由指定的产品经理进行管理，后三个阶段则由指定的技术负责人进行管理。而统筹全局的人，则从两人中再指定一人，或直接由上级领导来统筹。所以，确切来说，我当时所担任的项目管理，其实只是技术层面的项目管理，统筹项目全局的是我的上级领导。

技术层面的项目管理，我主要采用敏捷开发方法，并结合 TAPD 或 TOWER 等工具进行管理。项目管理涉及到的具体事务不少，我只挑几个重点说一下：

• 代码分支管理：建议用 Git，不要用 SVN。要制定适合团队和项目情况的代码分支管理规范，可以从简单的 TrunkBased 模式开始，在实践中再不断去优化演进。

• 每日站会：站会的时间控制在 15 分钟内，目的主要是同步项目进度，发言要简明扼要、关注重点、禁止报流水账，可提出问题，但切记不要在站会中讨论解决问题，留待会后再去沟通解决。

• 复盘总结：每次版本迭代结束后，应该组织复盘总结会，这很重要，总结成功经验，吸取失败教训，有助于提升团队能力。

• 质量管理：这应该是项目管理中最重要但却是最难管理的一块了，其会贯穿整个研发流程中几乎每一个阶段。主要的管理工具包括测试驱动开发、设计评审、code review 等。

作为中层管理者，技术经理一般不会对基层员工进行直接管理，因此，想要管理好下面的整个团队，更需要提升自己的领导力，通过领导力而不是职权来让基层员工信服。

技术总监

高层技术管理岗，大厂和中小厂在这个级别上对管理者的能力要求，差距非常大。比如，阿里的总监级别，职级一般得在 M4 以上，M4 对应于 P9。阿里的职级体系有两条线，P 系列为技术岗，M 系列为管理岗，对应关系为：

• P6 = M1，主管

• P7 = M2，经理

• P8 = M3，资深经理

• P9 = M4，总监

• P10 = M5，资深总监

再往上就不列举了，马云卸任前是最高级别，为 M10。

而一般小公司的技术总监，跳到阿里可能只会给到 P7 级别，很优秀的可给到 P8，能达到 P9 的绝对是凤毛麟角。大部分技术总监难以达到 P9 或 P8，很多时候是因为技术深度达不到高 P 级别的要求。因为小公司的技术总监，能力更偏向于“全能型”，优势在于广度，而深度难免会成为短板。而大厂因为分工精细化，对广度反而没什么要求，但对深度要求很高。

另一方面，大厂的高 P 们跳去小公司当技术总监或 CTO，很多人也会面临广度不足的问题，难以很好地统筹全局。因此，习惯了大公司“精细化”模式的人也未必能满足小公司“全能型”的需求。

所以说，大厂和小厂的总监，几乎是两个不同的方向。而我自己也没有大厂总监的经验，所以我在这方面的经验主要适用于中小厂。

我的总监级别的管理经验，也有三年多了，具体岗位担任过技术总监、研发总监、CTO。管理的团队人员最多时近百人，最少时则是从 0 搭建。当 CTO 的时候责任最大，但团队的人员却是最少的，最多时也就 20 多人，后来因为熊市来了，资金链断裂，融资失败，团队最终解散。担任研发总监时，管理的团队是最大的，整个研发部门有百号人，包括技术人员，也包括产品和运营人员。

作为技术总监/研发总监/CTO，最核心的能力就是能够组建和管理整个研发部门，打造出一个高效的研发团队。

先聊聊从 0 组建团队的经验，这方面我有过两次经历。从 0 组建团队，最核心的还是如何才能招到合适的人选。最优的方案就是从自己的人脉中入手，以前带过的下属，或熟悉的同事、朋友，觉得优秀合适的可以试着挖过来，每个岗位上的人员，最好都是能够独当一面，后续有能力担任技术主管的。我当 CTO 时组建的团队，有好几个核心骨干就是我以前带过的下属，他们之所以愿意跟随我，部分原因还是因为认可我的领导力。这里要补充说一下，前面我就建议从技术主管开始就重点培养领导力，因为，领导力发挥作用的时候，不只是对在职的团队成员。

次优的方案就是靠别人推荐了，最后的方案才是进行社招。而不管是推荐还是社招，有些岗位，技术总监可能不熟悉相应的技术，就难以考察候选人的实际能力。我自己倒不存在这样的问题，毕竟我自己是个全栈。但大部分总监却非如此，那么，我提供三种方案：

1. 请技术专家帮忙面试，并给予相应的酬劳。

2. 请技术专家出一些面试题，并提供参考答案。

3. 总监自己花时间去了解相应的技术。

这三种方案，效果一般也是由高到低。花点钱请相应的技术专家帮忙面试是最好的选择，现在普遍都是视频面试，也比较方便。

接着，再跟大伙分享下我管理近百人的整个研发部门的一些经验。整个团队包括了产品经理、设计师、开发、测试、运维、运营等人员，需并行研发多个项目。有些公司的研发部门可能不会包括产品经理、设计师、运营人员，不过没关系，管理方法也是一样的。

管理百人级别的研发团队，第一个核心工作，就是采用合适的组织结构。一般有三种类型的组织结构：职能型、项目型、矩阵型。

职能型的组织结构，即是对团队成员按不同职能划分为多个小组，比如分为：产品组、设计组、前端组、App 组、Java 组、Golang 组、测试组、运维组、运营组。每个小组再分别设置一个组长，管理各职能小组的成员和相应的职能事务。主要优点就是能够发挥各职能小组的集中优势，人员调配上也有较大的灵活性。主要缺点就是在项目管理上，完成项目需多个小组相互配合，但项目经理缺少权力，协调难度较大，难以做到快速迭代。

项目型的组织结构，即是将团队成员按不同项目划分为多个项目组，每个项目组都分别有自己的产品、设计、开发、测试、运营等人员，每个项目组再分别设置一个项目经理，管理项目中的所有事务和人员。优点就是项目经理对项目可以全权负责，包括对项目成员也有全部权力，项目决策快、效率高，也可做到快速迭代。缺点则是项目组相对封闭，资源无法共享，很容易造成资源浪费，且项目之间缺乏交流，知识和经验也难以在不同项目组之间共享，对团队整体的提升造成阻碍。

矩阵型的组织结构，则是职能型和项目型的混合体，可对两种结构的优缺点进行取长补短，是目前大部分互联网公司所采用的方式。矩阵型结构，项目成员会有双重领导，职能经理和项目经理都是他/她的上级，对员工容易产生焦虑和压力。且如果权力划分不明确，两位领导容易产生冲突。

根据项目经理和职能经理权力的强弱关系，矩阵型结构还可以再细分为：弱矩阵、强矩阵、平衡矩阵。弱矩阵下，职能经理的权力更高，项目经理的角色更像个协调者。强矩阵则是项目经理有着更高权力，管理上更偏向于项目。平衡矩阵自然就是两位经理的权力都差不多，取平衡，而平衡之道其实也是最微妙的。

我这边主要尝试过项目型和弱矩阵型，从效果来看，弱矩阵型的组织架构会更加合适。至于平衡矩阵型，想要达到好的效果，需要精心建立管理体系，且对协调人的能力要求较高，而身边缺乏这样的人。另外，还有一种方案，就是让职能经理同时兼任项目经理，我曾任技术经理时就是这样，但我担任总监时，却缺乏符合要求的人。

作为技术总监，组建起研发团队只是第一步，想让这个团队变得高效，还需要做很多事情，也有很多方法，但回归到最本质上，还是要尽一切努力去激发成员们的善意与潜能。

总结

技术管理的方方面面还很多，限于篇幅，暂时就先聊这么多了。总结陈词，我只说两点：

1. 技术一定不能落下，不管是主管，经理，还是总监，最最核心的还是技术。

2. “管理的本质，是激发人的善意与潜能。” 谨记这句话并时刻践行之。