Teamwork
前面一篇文章开了个新号提到：

在周围的人群中，相信有很大一批同学都和我一样，作为 IT 行业里的码农，干久了，有一些迷茫，有一些惆怅，不知道自己是继续做技术，还是转行当管理，不知道自己以后的路如何更好的走下去。”

这篇文章，从我的角度来谈谈一个程序员从技术转管理的过程，不一定适合你，但是肯定有可以借鉴的地方。

其实我不太喜欢用「管理者」这个词，在我看来，大家都是一个团队的，只是分工不同，没有存在着职位的上下级关系，你是团队中的一员，他也是团队中的一员，职责不同，仅此而已。所以后面我更多的称自己为 TL(team leader) ，做的是大部分工作偏管理而已。

说一下我从一个工程师到 TL 的转变过程。

刚开始的时候，公司 10+ 人，那时候的管理成本是比较低的。作为一家创业公司，初期的人员本身就是 CEO 亲自挑选面试的，这批人都是和公司目标和使命一致的人。一旦目标一致，大方向不错，管理者就不需要经常去修正目标。

慢慢的，公司逐渐的扩张，人员从 10+ 个变成了 100+ ，公司的场地也从一个复式的小民房变成了上千平的写字楼。一个管理者最佳的团队人数是 7 人左右，按这个标准出发。后面就有很多的一线技术人员逐渐脱离了技术岗，慢慢的开始兼职一些管理上的事务，这个转变也是一个循序渐进的过程，我认为经历了下面三个阶段：

技术/业务管理

在一个团队中间，随着时间的推移，总是有一些人在某些方面会比较突出，有可能是业务方面，也有可能是存技术方面。无论是业务还是技术，都会存在一些问题，你开始兼职扮演解决问题的那个人，管理工作开始萌芽。

虽然大部分的时间还是在 coding，只有团队内部有一些技术难题的时候会找你咨询，你更多的时候可能也是希望自己亲自上阵，三下五除二解决问题，很有成就感对不对。所以这时候可能大家心里更多的认为你是一个方案的提供者和解决者。

这种情况下你可能更多扮演的是救火员的角色，大家开始慢慢的依赖你，你不断给大家救火，不断给大家提供一些意见和建议，慢慢的形成了一定的领导力。

项目管理

等到大家对业务基本熟悉了之后，技术上的难题也解决的差不多了，产品就进入了稳定迭代的阶段。除非是大版本的更新，一般的小改动团队成员都可以应付，这时候技术上和业务上的述求就变得不是那么迫切，你更多的是从项目管理的角度去做管理。

你需要去协调保证项目完成的各个环节。你去沟通设计部门按时间出效果图，这样开发才好评估 UI 实现上需要花费的时间。你去了解服务器部门什么时候能够给到 API 的接口文档，什么时候能够联调。测试什么时候有时间，确定好了测试时间后又要回过头去协调开发，确定提测时间。这时候的工作基本上就是在不断的协调各个部门，使得能够保证整个项目能够按照预定的时间节点上线。

这时候你做的更多的是项目管理的角色，主要的目标是保证项目顺利按时的递交上线。

团队管理

随着公司的壮大，团队的人员也在补充。项目也在不断变多，你会发现光你自己一个人会一直处于救火状态了。每天来公司上班都会有一堆的会议在等着你。需求评审会，项目进度会，复盘会议，方案讨论会。你会发现真正 focus 在具体工作上的时间突然变少了，很多的时间花费在各种会议中，特别当突破 7 个人上限的时候，你发现，团队已经快要失去你的掌控了。

这时候你开始关注整个团队的管理，你需要不断的把项目下放，团队的成长成为了你管理的瓶颈。你需要花更多的时间去了解团队中的成员，哪些是适合承担技术管理的角色的，哪些是合适做项目管理的，哪些是适合将来带团队的，并且慢慢的让这些成员参与到这些管理中，你只有等这些成员慢慢成长了之后，才能够从整体上把握整个团队的发展。

以上，就是我这些年一直走过来的路，是我的一些切身体验，希望对你有帮助。还是那句话，不一定适用于你，但肯定对你有价值。