本文适合初入职场的IT新手。

如何做一名IT技术经理？做了几年程序员，你会发现程序员这个群体也是很多样化的，有喜欢学习的，有不爱学习的。喜欢学习的里面，有喜欢研究算法的，有喜欢看面试题的，有喜欢看基础知识的，有喜欢拓展到其他领域走全栈路线的。不喜欢学习的里面，有些是本身上进心一般觉得现状挺好，有些是打算扯皮混日子，有些是有阶段性更重要的事情占去了大部分精力。凡此种种，都不是个例。

IT技术经理是一个范围很广的职位，一般大到公司CTO，小到小团队领导，都算是技术经理。不同层级，对个人的能力要求和偏重方向是有所区别的，但总体来说是下面这几种能力。

一、技术的打磨

技术经理，顾名思义，技术也是占了很重要的因素的。如果没有“技术”，那就不是技术经理，最多是经理了。一个合格的技术经验，在他称为技术经理之前，必然需要技术上有一定的水平，至少需要到高级开发的水准，然后在技术的广度上需要有一定的涉猎，但并不需要每个点都深入，一则是没必要，二则也很难有那么多的精力。学技术这个事情是需要经常总结的，因为实际工作中用到的毕竟有限，很多东西不总结的话就容易忘掉，忘掉其实也没啥事，扩展广度的意义不是让你能熟练的手写相关代码，而是你知道某种场景下有没有什么方案比较好，团队其他人的方案是否有走偏等。

很多知识点都是很零碎的，要想把自己的技能树打造的足够庞大，有两个很实用的方法：

1.1、多做项目

要多做不同类型的项目，不要光靠公司里的拿点技术栈比较固定的项目，我建议初期可以通过做私活的方式来拓展技能树，没有业务需求和时间压力，光写demo会有很多实际要碰到的问题结果没碰到，少涨了很多能力的。通过大量从0到1的项目经验，自然而然会知道如何搭建环境、如何部署前后端项目、如果和数据库打交道、跨域是怎么回事如何避免、如何配置nginx等。私活是可以钱和技能二者兼得的，但是同类型的私活做过一两个就不要重复去做了，尽量做一些不同性质的，可以是用不同技术栈的（前端、后端、vue、react等），也可以是不同端的（比如PC端、wap端、小程序端、微信公众号端），或者是不同类型的产品（2B、2C、电商、管理系统等）。

当然这种项目有个缺点，虽然比hello world强多了，但是普遍缺少迭代重构，业务复杂度不高。而要有多迭代、业务复杂度搞的项目经验，就要靠公司项目来积累经验了。所以，如果你在公司里从事的工作是天天写一些专题活动页的话，这种重复活动进行了两三个月后就在没有任何意义了，该挪坑就挪坑。

在公司里一定要积累一定的迭代/重构经验，按我自己的感悟，这段经验主要是提高你阅读他人代码和优化代码的能力。看多了别人的代码，你就知道什么叫优雅的代码，什么叫如屎一般的代码了，烂代码看过了也就知道自己之前写的代码有多烂了，好代码看多了也就慢慢知道如何去更好的组织代码了。迭代多了，就知道要实现类似的需求，有时候有好几种方案（有的方案代码量会明显下降）就可以和产品去讨论是否可以调整需求里的某些点了。讨论多了，产品思维才能提高，碰到一些产品新人提的不合理需求，也就能知道其不合理之处，及时提醒之。

其实等你在积累了几年的公司项目经验，也从零到一做过很多私活项目后，你的能力已经至少是高级开发工程师的级别了。

1.2、多总结

画技能树是一个不错的总结方法，不过也不用完全从零开始画，网上有很多不错的技能树/思维导图，在此基础上补上你的细枝末节，就成了一个不错的帮助回忆过往技能的工具。这点我自己做的不好，记个TODO。

然后就是看面试题，通过面试题来检漏。其实很多面试题还是有助于帮助理解一些概念和本质（相对的本质，不是要你去当科研项目去研究）的。但是刷题别刷太多分了，除非你要去头部大厂加班，那里内卷得厉害，不刷题怕是不行（目标p6的话当我没说）。生命有限，把时间花在有意义的事情上，有些是你自己觉得没意义，别人也觉得没意义，然后就因为内卷得厉害，就要互相伤害，何必呢。

举个例子，写业务代码的前后端一般实际工作中都用不到啥算法，所以算法这块只要了解冒泡排序、二分法排序、快速排序、队列、栈、树就可以了，树里只要了解二叉树，能实现二叉树的前中后续遍历以及借助栈和队列实现深度优先遍历和广度优先遍历就可以了。如果面试官问得再多，个人觉得你也不用考虑这样的公司了，要么是这个面试官是个初出茅庐的新人，要么就是公司实在比较内卷，去了也不自在。

这里我解释下为何说面试题过深可以判断公司比较内卷（前提是面试官不是那种因为应聘者没说出来一个dom操作api而把一个应聘架构师的人给否了的那种新人）。显然招聘本身是有成本的，如果应聘者就一两个人，那只要简历别太过分，还需要筛选简历的过程吗，挨个面试呗。但是如果简历很多呢？给所有人都安排面试显然是不现实的，这时候就会出现根据学历、工作经验、性别等基本信息来粗略先过滤一批人，诸如此类，到最后发现还有很多简历没被筛掉，这时候怎么办，这些简历一般看着也都差不多，但是招人的数量毕竟是有限的，基础知识热门面试话题就那几个，说来说去其实也很难筛选人，这时候算法就是一个很好用的筛选工具了。一般公司考非算法相关岗位程序员的算法，基本就问上面提到的这些就差不多了，问得更深的基本上说明应聘者实在很多，这样的地方你进去后你的替代性是很高的，你不想呆了公司很容易就能找到替代你的人，而且里面的人相对笨的人比较少，我觉得这样的环境下政治斗争、职场PUA之类的会比较多，呆着累，也浪费自己时间——因为需要把很多有意义的时间浪费在无意义的事情上。

二、资源的管理

作为一名技术领导，你需要有资源的管理能力。

2.1、人力资源的管理

你的团队现在有多少人，那就是你当前的主要资源。而且这么跟你说吧，其他到了领导岗了，很多时候判断一个人领导能力的强弱，就是看他曾经带过多少人，以及其团队做过的事。所谓千军易得一将难求，大致说的就是这么个理。因为能带许多人的岗位是相对比较稀缺的，所以能带很多人的这种经历也是比较稀缺的，一般有这种经历的人，业绩如果做得也不差，这人就是领导能力比较强的了。

如果公司并非处于稳定期，但是你的团队规模一直停步不前，说明你们的产品不太行，或者说明公司战略有所调整，你的部门已经不是重要部门了，不然的话很可能说明你的领导能力是有问题的。你们团队能力够强，能者多劳就应该干更多的事情，对公司产生更大的利益，从而可以向公司索要更多的资源，团队规模正常来说是会越来越大的，这是一个正向反馈。

插一句，上面提到了能者多劳并不是在鼓吹996福报啥的，相反那种遇到问题就搞加班这套其他啥也不会的职场PUA大师，我是比较排斥的，我认为这是没有远见的行为，一般搞这种花样的领导也细分好几种，有些是新官上任三把火先通过这种方式区分乖和不乖的；有些是为了大致了解下团队成员的忍耐度，以便在这个尺度上提高短期绩效；有些是没啥管理能力只能通过这种方式行使自己的权利；有些是没啥话语权纯粹是当上级领导压榨下级员工的权利机器；有些是通过这种方式降低团队成员能力提高自身地位的稳固性（但凡有点能力的人多少有些傲气容易被挤走，但是如果是有能力又愿意加班的领导也喜欢），当然还会有其他的情况，也不排除确实是公司阶段性需要加班，但是如果只是短期且后面能合理安排调休，也还算可以。

言归正传。正常来说你应当让领导们看到你们团队的价值，愿意提供给你们更多的资源（通常意义下就是可以招更多的人，可以提高大家的薪资待遇），让你们可以干更多的事把事情干得更好。切记，如果你没法为部门争取资源，你手下是会失望的，最终很多有能力且不求安稳的人会选择离开。员工也是会对领导，怒其不争的。这方面我多少有些体会，举一些例子：

1. 刚到A公司的时候，公司开季度大会表彰员工的时候我会去听听，后面我发现明明我做的事情比其他部门一些人做得有价值得多，但是他们就能拿季度优秀员工我不行的时候，会觉得不服气。
2. 有一年因为倒排期挤压了我们的开发时间导致一个项目上线后问题比较多，大领导把我们部门直接评级为B还是啥了，反正就导致这一年我们部门没有员工可以评A了（没有名额），也就是说不管你做了啥只要部门评级差你都拿不到A，所以要拿A除了有亮点，个人不能有什么错误，还要寄希望于团队也没啥错误，太看运气了，如今还要再加一个要多加班，这性价比实在太低了。

第一次碰到上面这些事的时候多少有些想法会觉得如果我们部门不那么弱势的话，我明明可以混得还不错的。说这些就是反过来告诉读者，如果你做领导但是没法为团队争取应得的资源，团队的作战能力是上不去的。当领导切记不要当好好先生，上司说啥你都说好，揽了一堆活把下面的人忙得不行，然后你还要不到资源（好好先生一般也不擅长索取资源），兵是不愿意在这样的将军底下做事的。当然也不能团队成员说啥你都说好，这样会缺少威信，好不好总体上还是要根据实际情况来的，但是该拒绝该否定的就该拒绝否定，不会说No的领导不是好领导。

再来说说团队组成。一般一个团队里，不太会都是厉害的（成本高），也不太会都是很弱的（真遇到问题没法做事）。一个团队里正常会有各种各样技术水平的人，而且也应该各种性格都有的人，有些人虽然技术一般，但是会活跃气氛，对提高团队凝聚力也是很有益处的。但是有些人是会降低团队凝聚力和战斗力的，如果碰到那种喜欢搞政治的（抱怨领导这种不算哦，当领导偶尔被底下议论是很正常的），或者弄虚作假混进公司实际能力太差的，该劝退的还是得劝退。

其实很多事情讲究共赢，共赢的事情大家做起来会更有动力，要做到这点，作为领导你需要有换位思考的能力，站在别人的角度去想问题。比如对大部分程序员来说，他们并不喜欢维护公司内部的文档，有些东西，比如代码规范之类的，不涉及业务不涉及公司机密，如果能放到github上进行输出，对这些员工来说多少也可以在简历上有所体验，运功维护文档的积极性就会高很多，除了代码规范文档之外，比如一些最佳实践、一些优化方案啥的，只要不涉及公司业务，很多其实都可以对外进行输出的，类似的还有团队博客就比单纯内部提交技术分享PPT要有意思得多，因为这些对他们日后写简历都是有好处的，而且不仅提高了成员维护文档的积极性，也提高了公司技术部门对外的影响力，也容易反过来让招聘变得更容易。除了站在一线程序员的角度来考虑问题，你还需要站在上司、平级同事的角度去考虑问题。记住，只要是能双赢的，就会比较好推进——比如你可以和另一个部门领导一起讨论做某件事，然后这件事会让上司对你们大家赞扬甚至加薪，我想那个部门是原因和你一起做这件事的，再比如如果某个工具的研发可以确确实实提高大家的战斗力或者说让大家更轻松，那么大部分人也是愿意做的。

做一名领导，还需要懂得合理分配精力，适当放权。事必躬亲，定然会陷于琐事，迷失重点。适当放权并非直接把权力下放就完事了，这样容易把事情搞砸。需要了解团队成员的个人意愿，可以通过平时的观察以及一对一的谈话，了解是否有哪些人愿意或者说是希望能在未来往管理岗发展的，如果有的话就可以做到共赢了，一般一个团队里一定会有这样的人的。当然你不能光让人做事，啥好处都没给，就算不长工资，至少要调整其工作内容适当给予一部分时间用于小团队的管理。最好能给个title，这样对其以后跳槽也有好处，才能共赢——现实就是一个地方坑位总是有限的，大部分人转管理还是通过跳槽到新团队实现的，公司内部的晋升路线大部分时候还是给领导的熟人的，所以最好给个title这样不管以后公司这边是否有坑位可以提供，对员工来说还有其他外部的坑位可以用。

2.2、其他资源的管理

除了人力资源的管理，还有其他一些物力资源也需要管理。比如账号的管理，比如系统资源的管理。这些不是主要事项，暂且不表。

三、项目的管控

一个项目要有序进行，需要尽可能按固定的周期进行上线操作，不要动不动就随意上线。这样会影响原先开发同学们自己给对应需求定的排期。

如果有新同事进来，一般容易给出一个较少的排期时间，可以适当延长之，避免项目周期太过紧张。

项目要让需求方排优先级。

对于需求方的项目，要过滤掉不合理的部分，然后把需求尽可能地拆成各个小需求，不然容易出现产品认为就提了一个需求（实际是一个大型捆绑需求，相关的不相关的一堆需求堆到一起），然后开发团队却花了很多时间的问题。

暂且这样，已经快五千字了，等想写的时候再继续写。