技术管理者怎样跳出“泥潭”

近几年面试了不少新人，当问到职业规划时，大多都会说先积累技术，然后往架构师的方向发展。这可能是技术人的一个特质，喜欢跟机器相处，沉浸在代码之中，而不喜欢跟人打交道。

现实的情况是，一些中小公司可能没有专职的架构师岗位，即便有，也是需要身兼多职，很多时候程序员都在没做好准备的情况下，却被公司推到了管理岗位，即便是冠上了架构师的头衔，也需要做很多管理的工作，通常会面临下面的一些问题：

初次接触管理岗，需要和人打交道了，难以适应
仍然把自己当成是一个高级的开发者
需要多任务并行处理事情，分不清主次
团队成员从3、5人发展到10来人时，流程、做事方式等都需要转变，也会面临巨大的考验

今年年初，我就面临了一次很大的考验，团队的成员越来越多，公司的项目也越来越多，产品团队这边压力非常大，我也几乎到崩溃的边缘，甚至还给领导写了一封“诉苦”信，归根结底，还是能力的提升速度没有公司的发展速度快。

经过领导的引导和自己的调整，我觉得已经突破了瓶颈，并在这大半年的时间里有了明显改善和进步，下面分享一点我的体会。

心态

做任何事情，心态都非常重要，不好的心态会使你对完全能够胜任的事情也产生排斥的想法，最终做出非常糟糕的结果。举一个加班的例子：

如果你觉得8点就能搞定下班，但因为各种非自身原因导致10点才能完成；
提前考虑的比较周全，认为需要到11点才能完成任务，但因为配合的很好，10点就完成下班了。

同样是10点下班，后一种点心态就会好很多，因为在事前心里就有了预期，而实际结果比预期的好。

所以我们在进入管理岗位后，就要有随时会遇到各种问题的预期，解决一个个点问题就是我们升级打怪的过程。就像我们领导说的，必须经历痛苦才能够成长。

任务归类

作为一个开发人员，领导安排的任务按时交付就算合格了，如果能再考虑下扩展性、重用性、性能等问题就算是很优秀了，做的事情相对单一，平时也不会受到很多外界的干扰。

一旦走上技术管理岗位，会感觉事情突然翻了很多倍：

制定产品的任务计划
需要考虑团队成员的成长
合理地安排任务
各部门之间的协作
重难点技术的攻关
核心代码的编写
解决团队成员遇到的各种问题
…

如果没有一个合理的安排和归类，就会像无头苍蝇一样，到处乱窜，一天下来感觉非常忙碌，但好像又什么事情都没做。所以任务的归类非常重要。

事情再多，都可以按照，重要紧急、紧急不重要、重要不紧急和不重要不紧急这四个象限来进行分类。类分好了，先做什么，后做什么，就一目了然了。

任务下放

程序员通常都很自信，觉得自己写的代码是最好的，看别人的代码总觉得有各种各样的问题，在排查一些历史问题的时候，经常会说，这谁写的代码，这么烂，最后一看Git记录，发现是自己写的。

所以到了管理岗位后，任何事情都喜欢亲力亲为，就造成了自己忙死，而团队成员工作不饱和。带领团队后，对团队中每个人的性格和优缺点都要了如指掌，这样才能做到知人善用。

在上面一步做了任务归类后，就可以清楚地知道哪些是可以分配下去，哪些是需要自己处理。例如：

项目组反馈了一个紧急Bug，这是需要做的是准备好重现环境，安排合适的人进行排查和修复，而不是直接打开VS开始调试代码了。

懂得合理地分配任务，才能有更多的精力去做更重要的事情。

善用工具

不同的时期，有不同的做事习惯和风格，最早我团队只有3个人的时候，平时的沟通和任务的分配基本都是口头转述，因为这样效率最高，但仅限于团队成员足够少，并且每个人都能够配合默契，这样口头转述的内容才能不失真，真正地做到有效率。

慢慢地团队中加入了很多新鲜血液，再用口头转述就会存在很大的问题，同样的一句话，一个新人的理解和你想要达到的效果可能相差很远。这时就需要有文档了，我们现在使用语雀来写需求文档，更多的时候，我是让开发人员自己来写这个文档，然后我再来复审，看需求的理解是不是完全清楚了，这样做有一个好处，开发人员不是被动地接受任务，而是主动地参与思考。

团队成员增多，每天的需要提测的任务也越来越多，如果还是手动地发布部署会浪费大量的时间，这时就需要使用Jenkins、Docker等自动化构建的工具了。还有需求和任务的管理也必须工具化、流程化，这一块我们采用的是我们自己做的产品搭建出来的任务系统。

善用工具，可以将繁琐的，重复性的工作交给机器来做，就会有更多的精力去做更重要的事情。

最近一段时间的新的体会，希望对您有所帮助。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。