导读：我们清楚管理网络服务器、数据库和其他软件系统的必要性。在成长型企业，管理开发团队同样重要。大部分科技公司在管理10人左右的开发团队会遇到瓶颈。过去几年，Adam wiggins（Heroku的创始人之一）在 Heroku 相当成功地探究过这个管理困境，这篇文章将呈献他在管理团队的经验和每一阶段所遇到的问题和可能的解决方法。

阶段一：自酿

在开始阶段，你的公司有2-4个人在客厅、咖啡厅或者一个共同工作空间工作。沟通协调是很容易的，大家坐在一起，每个人都知道其他人在干什么。公司的创始人和早期的员工都很有自主性，貌似没管理的必要。每个人都是多面手，参与公司的各项事务。你有一个单独的群聊频道和单独的邮寄名单all@yourcompany.com。没有什么迫切需要去跟踪任务和发现什么漏洞。整个公司的运营状态和产品现状都在每个人的脑海中。

在这个阶段，你在试图创造或者说是呵护你那刚起步的产品，说的通俗点就是你要知道你自己在干什么。任何形式的框架或者固定的程序都是极其有害的。每个人必须是个多面手才能解决任何出现的问题，专家的话，在遇到棘手的问题时就会很厌烦，更有甚者会转移团队的重心。他们想把产品发展固定到某一个自己所熟悉的领域。

阶段二：初始聘用

一旦你拥有了一点资金，能够雇佣多一些的开发者，达到5-9人，你也许会发现“无线协调办法”开始失效，有些人会坐到别人旁边，希望知道所有重要的信息。你有时会密切关注其他几个人的工作，这是很耗时间的，或陷入沟通不畅，结果所有人都在修复同样的漏洞，回复同样的邮件或是响应同样的程序页面。

到了这个阶段，你会想到构建一点公司架构：也许是在周一做重复计划、每日的站立会议和用白色书写板跟踪一些大的待办事项和一些漏洞，或利用一些简单的工具，例如Lighthouse。也许你会转向Zendesk一样的支持系统，可以指定传入式的支持请求。你也可以通过Pagerduty增加简单的轮流加班。你的单独内部沟通和邮箱通道就能够继续正常工作。

不要引入太多的组织结构和工作流程。一些创业公司在这一发展阶段会宣传自己已经成长为一个真正的公司，立马想要切换到一些笨手笨脚的策略。例如使用羽翼丰满的Scrum，重量级工具如Jira，或是雇佣项目管理经理和技术经理。不要做这样的事情。你的团队以“无线”模式运转的很好，团队或许有一些天生的领袖人物在掌控大量的工作，而且他们都参与其中。即使你的产品发布后，到了消费者手中，你仍在某种程度上摸索你公司的未来。引入官僚主义无疑会阻碍你做成自己真正想做的事情，而这个初衷会在不断的创业过程渐渐浮出水面上来。

这一阶段的关键是专注力。每个人仍是多面手，但是开发团队应该目标一致，一步一个脚印。如果想多线作战，你什么也做不好。伟大的公司多是衰落于多线作战而不是在某一领域失败。慎重地选择你的战场，然后保持专注力。

进入阶段三前的危机

达到10-15个开发者，你要着手调整大的团队建构了。有人告诉我说很多有希望的创业公司没能从第二阶段安全过度到第三阶段。

拥有了如此多的开发者之后，反复计划，站立会议和其他形式的开发者团队会议都颇具规模，而参加者与会期间会感到厌烦。每一个独立的开发者很难在别人事无巨细的工作展示中发现意义和共识。

在公司规划中，当一个阶层或是来源档案变得很大时，解决方案就是把他们分解成小块。管理一个开发团队也是如此。你需要把团队分解成定向的几支队伍。

阶段三：分解团队

分解单一的多面手团队不是看起来那么容易的。阵营划分错误会造成更大的协调障碍。划分得当会增加团队的专注力，幸福感和效率。

一个好的团队的关键在于权责分明。团队对自己负责的部分拥有远见和方向感。她能够全权在自己的领域运作，不需要别的团队的许可或信息，除了一些跨团队的罕见的案例。

软件架构和团购架构间的精密筹划会很有益处。到现在为止，你也许已经把整体的团队变成了由多个部分组成的分布式系统，通过REST、AMQP或者其他RPC机制沟通交流。如果你现在没这么做，你应该马上考虑这样做，与分散开发队伍同时进行。在各个软件构件和原始团队中间应该有一个显而易见的筹划，每一个构件都有自己的资源库和部署位置和流程。

决定人员分布有些武断的成分在。我的办法是跟每个开发者坐下来谈心，深入了解他们最喜欢工作的领域。因此我人尽其能地分配我的团队。一些人发现第一次团队分配很适合他们，而另一些人不是很满意，他们需要马上转到别的团队。随着时间的推移，团队的分工日益明确，我们能更加容易地人尽其才。让开发者追随自己的内心，然后他们将会到最适合自己的团队做自己最擅长做的工作。

到这个节点，你应该很清楚自己的产品和市场的契合点。如果公司发展到这个规模。你还在寻找公司存在的意义，你就遇到大麻烦了。如果事实果真如此的话，你应该停止公司的业务扩展，停下脚步直到发现切合市场的产品。

专门化

另一个分组的动机是专门化。工程专家的分类包括ops工程师高级系统管理员、基础设施开发者、前段网络开发者、后端网络开发者、业务工程师、数据分析师和聚焦特定编码语言的开发者。编码语言专家越来越普遍，因为越来越多的互联网公司使用诸如Erlang、 Scala或Clojure等函数程式语言写入高并发组件。这些函数程式语言由不同的开发者负责，而不是 Ruby、 Python、或是 PHP网络组件的创始人。

在早些时候，专家很难令人满意。发布软件产品工作有很多层级，关系到很多有贡献的人，每个人都有贡献。这使得开发者兼顾非常广泛的领域，从ops项目例如OS上的kernel更新到前端项目例如为UI编写jQuery效果。

一旦你拥有了12个开发者，你的产品已经有了一定的使用量和成熟度，同时也出现了一些问题。管理数据库不仅是个全职工作，更需要很强的专业知识背景，如果这人同时学习jQuery 、iOS和Erlang ，他是不能够胜任这份工作的。

你需要这样的员工，他们能够而且乐于专注于某一领域，这样他们才能成为这一领域的专家。一些人将是目前的多面手，他们愿意专注于某一领域，而另一些将是新雇佣的员工。你现在能够雇佣些专家，这些人在公司规模缩小后将不会再适用于公司。有多面手在身边总是有用的，一些多面手也许能进入管理层，成为公司团队的股东而不是亲力亲为的开发者。