如何扩展开发团队(转)

原文标题：How To Scale a Development Team

原文链接：http://adam.heroku.com/past/2011/4/28/scaling_a_development_team/

 

作者通过自己在Heroku的经验，讨论了开发团队是如何从家庭式作坊发展到专业化团队的过程，在每个阶段中都给出了关键注意点，本文对于想创业和正在创业以及创业成功的人士都有可以学习的地方，让我们从头开始吧！

作为黑客，我们对于扩展web服务器、数据库和其他软件系统的需求已经驾轻就熟。对于成长型公司的一个同等重要的挑战是扩展你的开发团队。

大多数的科技公司在发展到大约10位开发人员时会遇到队伍可扩展性的棘手问题。有了前几年在Heroku成功指导这个过程的经验，这篇文章将呈现开发队伍成长过程的各个阶段中我所看到的以及每个阶段遇到的问题和潜在的解决方案。

第1阶段：家庭式作坊（Homebrewing）

一开始，你的公司有2-4男的/女的，你们在某人的住所、咖啡厅或者可以协同工作的地方工作。沟通和协调是很容易的：仅仅几个人挨个坐着，每个人都知道其他人在做什么。创始人和早期的员工倾向于自我引导的，因此几乎是不存在管理的需求。每个人都是通才，每件事都多多少少的插手。你有一个单独的组聊天频道和单独的all@yourcompany.com的邮件列表。没有任务跟踪甚至是bug跟踪的真正需求。整个公司情况以及你们的产品每个人都能记的清清楚楚。

这个时候，你试图创建并检查你的最小可行性产品，这是一个你试图想弄清楚你在这里到底做什么的奇特方式。这个时候任何一种组织机构或者流程的存在都将是极其不利的。每个人不得不是个通才并且能够解决各种类型的问题——专家们会在某种程度上（最好情况)专一而又（最坏情况）高度分散，因为他们想要引导产品到他们擅长的领域。

第2阶段：第一批员工

一旦你有了一点资金并且能够雇用更多的开发人员，让团队发展到共5-9人时，你可能会发现点对点方式的协调（希望坐的靠近队友从而能够听到每件重要的事）开始被打破。你要多做一些事（关注其他六个人的工作是耗时的）还要放弃一些事（你结束了试图修复相同bug，回答相同的支持邮件或者回应相同的Nagios页面的冲突）。

这时候，你想添加仅仅一小点的组织机构：也许一个周一的迭代计划、日常的短时会议、跟踪大的待办项目以及白板上或者简单工具（如Lighthouse）中的bug。也许你转而使用像Zendesk可分配传入支持请求的支持系统，并通过Pagerduty为页面添加一个简单的呼叫旋转。你们单独的内部聊天频道和电子邮件列表仍然可以正常运行。

这时候一定要抑制引入太多的组织机构和流程的冲动。一些刚起步的公司在到达这一步的时，宣称“我们已经长大了，现在我们可以像真正的公司那样去做了”并且立即尝试切换到难以承受的战术战略上。例如：成熟的SCRUM、重量级工具如Jira、聘用项目经理或者设计管理人员。不要做这些事。你已经有了一个在特定方式下大家一起工作、运作良好的团队；在团队里你可能有一些天生的领导者，当他们忙于自己手头工作的时还可以指导很多的工作；同时当你推出产品到用户手中时，在很多方面你仍然在尝试弄清楚你的公司到底意义何在。引入官僚主意到这个环境中几乎可以肯定阻止你真正想做的任何事情，这是探索你的可扩展商业模式的关键。

这个阶段，专注是关键。每个人仍是通才，但是在特定的时间（即里程碑）整个开发团队应该向着同一个目标。如果你尝试一心多用，每件事都会做的很糟糕。大公司更有可能死于机会太多造成的消化不良而不是由于机会太少导致的饿死。细心的选择自己战斗领域并一直保持专注！

第3阶段频临危机

成长到10-15位开发人员时，你正处于大团队结构变动的边缘。有人告诉我许多有前途的创业公司未能在这些阶段中经受住转变而失败。

有这么多的开发人员、迭代计划、短时会议或者任何其他类型的开发团队会议已经让这些与会者花费了太多的无聊时间。任何身处他人繁琐的工作明细中挣扎的开发者个人将会很难找到目标感或者共享的方向。

在编程中，当一个类或者源文件开始变大，解决的方案就是分解成小模块。扩展开发组织使用相同的原则，你需要把组织分解成具有针对性的团队。

第3阶段：分解团队

划分一支通才的团队比说起来要难的多，划分不得当，将会产生协调问题从而让事情更糟糕。划分合适，你将会看到幸福和生产力的大幅增加。

一支好团队的关键是划分好职权范围，拥有清晰的接口供其他团队使用。团队应该对他们所工作的产品部分拥有前景和方向。团队应该拥有最大自主权来操作所拥有的一切，无需获取许可或者来自其他团队的信息，除非少见的功能或者bug与其他队伍有了交叉点。

软件架构与团队架构的紧密对应将会是个很大的帮助。到这个时候，你可能已经把你的庞大应用程序转换成了多个组件通过REST、AMQP、或者其他RPC机制通信的分布式系统（如果没有，你应该强烈建议这样做，和分解的开发团队步调一致）。软件组件之间应该有明显的映射——每一个都有它们自己的源码库和部署位置/过程——和你的新生团队。

起初决定什么样的人分配到哪个团队在某种程度上有点武断。我的解决办法就是大家坐下来并且深入的理解系统的哪部分是他们最有激情的。从这点我尽最大的努力来分配团队。第一次团队的分配，有些人找到了完美的家，其他不满意的人需要公平快速的转移到其他队伍。随着时间的推移，团队的领域就很好的形成，因此就能更容易的把新聘的员工插入到正确的岗位。让开发人员跟随他们自己的激情，他们将会自然的融入到团队并且做出最好的工作。

另外，这个时候你应该找到了合适的产品/市场。如果你的公司发展到这个规模并且仍在寻找公司的意义所在，那么你们的麻烦就大了。如果是这种情况，抓紧停止规模的扩大并缩减规模，直到你捕捉到了合适的产品/市场。

专业化

分解团队的另一个原因是专业化。工程类专家包括OPS工程师/系统管理员、基础构架开发人员、前端web开发人员、后端web开发人员、业务工程师/数据分析师以及开发人员，他们关注特定的语言。语言专家越来越普遍，因为许多网络规模的公司使用像Erlang、Scala或者Clojure函数语言编写高并发的组件，通常由不同的一组开发人员来处理而不是Ruby、Python或者PHPweb组件的作者。

在早期，专家是很少令人向往的。相对能做出贡献的人的数量，在产品线上有太多人工作在不同层次上。因此每个人在每件事上都做出了贡献。这种情况可能把一个开发人员分配到非常宽泛的工作岗位上，例如：在操作系统上更新内核的OPS项目，为用户界面编写JQuery效果的前端项目。

一旦你达到了拥有十几个开发人员的时候，你的产品已经达到了使用性和成熟度问题变得更难的层次。因此缩放数据库不仅是一个全职的工作，而且如果这个人同时通过学习成为一个JQuery的专家、iOS专家和Erlang的专家，更需要一个不可被收购的深层次的专业知识。

你需要的仅仅是几个可以并愿意密切关注相关领域的人，因此他们可以在这些领域建立非常深厚的造诣。其中一些将会是现有通才中决定专业化的人而且还会有一些新员工。现在，当你的公司还比较小的时候，你可以聘用这类并不是相称的专家。通才在身边通常是很有用的，其中有些可能进入了管理层——为团队灌输企业所有者的角色，而不是亲自动手开发。

Heroku公司的第一批团队

Heroku的初始团队分类看起来像这样：

• API团队——拥有面向用户的web应用程序和匹配Heroku的客户端gem。
• Data团队——构建并运行我们PostgreSQL作为一种服务数据产品。
• Ops团队——指导并保护产品系统的可用性。
• Routing团队——管理一切必要的路由到用户web的HTTP请求过程。
• Runtime团队——处理部署的包装码和开始/停止/管理用户进程。

这些队伍拥有一到五个组件，例如，API团队拥有运行在api.heroku.com和Heroku客户端上的Rails的应用程序gem。Data团队拥有数据库服务的配置和监测工具，以及所有单独运行的数据库。（Peter van Hardenburg是位有胆识的内部管理者，他创立数据团队并且现在领导着我们。在这个视频后部分他谈到了一点相关的故事。）

团队的规模和角色

对于我们来说，理想的团队构成由两个开发者和一个公司的老板组成。一位开发人员长期来说是不足够的（他们需要在代码上的第二双眼睛，另外，一个人是孤单的）。三位开发人员也可以工作的很好。发展到四至五位事情开始变得有点拥挤；未必有足够的空间区域让他们全部工作而不踩到其他人的脚。几乎所有的Heroku的团队都有两位开发人员。

“企业老板”在某成程度上是愚笨的术语，但是它是我们描述这个人为团队做一些产品管理、项目管理和一般管理组合的最好词汇。企业老板在了解团队的工作对于企业的价值以及如何适用较大的产品中充当重要的角色。他们可以跨团队沟通交流，通过商业价值帮助合理处理项目和任务，还可以提供团队的进展及表现状态报告给高级行政人员和/或整个公司来判定团队的持续存在性。

在企业家中我是一个黑客企业家的粉丝：强大的技术背景意味着他们对将要开始的工作拥有深入的了解，并有能力赢得被指挥人员的敬重。这种人并不是所有的团队都能找到的，但是如果能，尽力找出他们。在许多情况下，它涉及到需要具有相当的说服力才能让黑客放弃他们重要的编码生涯。

防止开发人员属于多个团队。他们是制造者，需要能够专注于他们团队的当前项目，避免分心或者试图参与多任务。然而，有时，公司老板可以属于多个团队。这并不总是一个全职的工作，通过同一个老板的两个或者多个相关的团队进行跨团队交流是有益处的。

凝聚力

在早期阶段，你应该避免一心多用，为了公司应该保证所有的开发人员关注单一的目标。随着每个团队领域的建立，这种情况已经改变。现在你可以并且应该选择多个目标。每个团队应该朝着自己的目标执行自己的任务，不用担心别的团队在干什么。

同时能够进行三个、四个、五个大的目标真是太棒了。在Heroku划分团队后的几个月，我们有一天三个不同的团队同时发布了主要的新功能。真是一种难以置信的感觉。

但是现在你有了一个新问题：缺乏凝聚力。你的松散的团队正在制定各自的路线图以及各自的功能决定。但是为了避免你的产品零零碎碎，有人需要来决定总体的方向及产品的功能集。更简洁的说：你需要一个战略方案。

但是，这篇文章已经足够长，就像团队的成长。另有时间我们再讨论凝聚力和战略方案吧。