Heroku的首批团队

Heroku的初始团队分布如下;

● API-拥有面向用户的网络应用和与之相配套的Heroku客户品质

● 数据— 建构运营数据库系统  作为数据库服务产品

● Ops-维护运行系统的有效性

● Routing–管理 能协助用户Web流程 获得HTTP路由请求

● 运行时间—处理包装代码   为了 部署、开始、停止、管理 户进程

每个团队都由1-5个部分组成。例如，API团队拥有Rails app，在api.heroku.com和“Heroku客户品质”运行。数据团队拥有为数据库服务的开通和监控工具，还有个人运行数据库。Peter van Hardenburg 是数据组的创始人和现在的领导者，他在视频的后半段谈到了这一点。

团队规模和角色

对我们而言，理想的团队结构式2名开发者，一个业主。一个开发者长期来看是不够的，我们需要另一双眼睛来看代码，一总是一个寂寞的数字。三个开发者也能运行的很好。到了4-5个人时事情就会变得复杂了，因为没有足够的空间让所有的工作不重叠。几乎所有的 Heroku团队都有2名开发者。

业主是有些拙笨的一个词汇，但这又是最好的一个词，用来形容一个人同时做着产品管理、项目管理和团队的综合运营等工作。业主为团队注入了商业认知和价值观，还有如何才能扩大生产规模。他们能够促进跨团队沟通，通过商业价值区分项目和任务的优先级，或许还能够为高管和整个公司提供团队进展的现状报告，这也许会决定这个团队的生存。

我是互联网创业公司“业主”角色的爱好者：很强的技术背景意味着他们对自己所做的工作有很深刻的理解，而且能够很好的控制他们团队对自己的敬意。这类型的领导者不是在每个团队都找得到，但我们应该尽可能的去找。在很多情况下，这就在说服的功力，使一个技术人员放弃自己最初的梦想——编码。

不要让开发者隶属多于一个团队。他们是创造者，需要在团队现行的项目上持续保持专注度，不能够为了别的任务分心。然而，业主又是可以多任务操作，也不总是一个全职工作，一个业主在2个以上团队工作对跨团队交流沟通是有益处的。

凝聚力

在前几个阶段，你应该让所有的开发者专注于一个单独的目标，避免多线作战。当为单独的团队设定了专业领域之后，情况就有变化了。你应该开辟多个战场。各个团队独立作战，不需要关心别的团队在干什么。

同时追3-5个大项目是很酷的。在Heroku分组后的几个月之后的某一天，我们三个不同的团队都有了重大的进展，这是一种难以置信的感觉。

但现在你会有一个新的问题：缺乏凝聚力。分散的团队会制定各自的路线图，独立决定今后的特色。为了避免产品的碎片化，需要有人制定一个总体的规划和一个总的产品价值体系。更简洁的说就是需要制定一个战略。

文章来源：adam.heroku.com