|
导读：我们清楚管理网络服务器、数据库和其他软件系统的必要性。在成长型企业，管理开发团队同样重要。大部分科技公司在管理10人左右的开发团队会遇到瓶颈。过去几年，Adam wiggins（Heroku的创始人之一）在 Heroku 相当成功地探究过这个管理困境，这篇文章将呈献他在管理团队的经验和每一阶段所遇到的问题和可能的解决方法。 阶段一：自酿 在开始阶段，你的公司有2-4个人在客厅、咖啡厅或者一个共同工作空间工作。沟通协调是很容易的，大家坐在一起，每个人都知道其他人在干什么。公司的创始人和早期的员工都很有自主性，貌似没管理的必要。每个人都是多面手，参与公司的各项事务。你有一个单独的群聊频道和单独的邮寄名单all@yourcompany.com。没有什么迫切需要去跟踪任务和发现什么漏洞。整个公司的运营状态和产品现状都在每个人的脑海中。 在这个阶段，你在试图创造或者说是呵护你那刚起步的产品，说的通俗点就是你要知道你自己在干什么。任何形式的框架或者固定的程序都是极其有害的。每个人必须是个多面手才能解决任何出现的问题，专家的话，在遇到棘手的问题时就会很厌烦，更有甚者会转移团队的重心。他们想把产品发展固定到某一个自己所熟悉的领域。 
Heroku logo
阶段二：初始聘用 一旦你拥有了一点资金，能够雇佣多一些的开发者，达到5-9人，你也许会发现“无线协调办法”开始失效，有些人会坐到别人旁边，希望知道所有重要的信息。你有时会密切关注其他几个人的工作，这是很耗时间的，或陷入沟通不畅，结果所有人都在修复同样的漏洞，回复同样的邮件或是响应同样的程序页面。 到了这个阶段，你会想到构建一点公司架构：也许是在周一做重复计划、每日的站立会议和用白色书写板跟踪一些大的待办事项和一些漏洞，或利用一些简单的工具，例如Lighthouse。也许你会转向Zendesk一样的支持系统，可以指定传入式的支持请求。你也可以通过Pagerduty增加简单的轮流加班。你的单独内部沟通和邮箱通道就能够继续正常工作。 不要引入太多的组织结构和工作流程。一些创业公司在这一发展阶段会宣传自己已经成长为一个真正的公司，立马想要切换到一些笨手笨脚的策略。例如使用羽翼丰满的Scrum，重量级工具如Jira，或是雇佣项目管理经理和技术经理。不要做这样的事情。你的团队以“无线”模式运转的很好，团队或许有一些天生的领袖人物在掌控大量的工作，而且他们都参与其中。即使你的产品发布后，到了消费者手中，你仍在某种程度上摸索你公司的未来。引入官僚主义无疑会阻碍你做成自己真正想做的事情，而这个初衷会在不断的创业过程渐渐浮出水面上来。 这一阶段的关键是专注力。每个人仍是多面手，但是开发团队应该目标一致，一步一个脚印。如果想多线作战，你什么也做不好。伟大的公司多是衰落于多线作战而不是在某一领域失败。慎重地选择你的战场，然后保持专注力。 进入阶段三前的危机 达到10-15个开发者，你要着手调整大的团队建构了。有人告诉我说很多有希望的创业公司没能从第二阶段安全过度到第三阶段。 拥有了如此多的开发者之后，反复计划，站立会议和其他形式的开发者团队会议都颇具规模，而参加者与会期间会感到厌烦。每一个独立的开发者很难在别人事无巨细的工作展示中发现意义和共识。 在公司规划中，当一个阶层或是来源档案变得很大时，解决方案就是把他们分解成小块。管理一个开发团队也是如此。你需要把团队分解成定向的几支队伍。 阶段三：分解团队 分解单一的多面手团队不是看起来那么容易的。阵营划分错误会造成更大的协调障碍。划分得当会增加团队的专注力，幸福感和效率。 一个好的团队的关键在于权责分明。团队对自己负责的部分拥有远见和方向感。她能够全权在自己的领域运作，不需要别的团队的许可或信息，除了一些跨团队的罕见的案例。 软件架构和团购架构间的精密筹划会很有益处。到现在为止，你也许已经把整体的团队变成了由多个部分组成的分布式系统，通过REST、AMQP或者其他RPC机制沟通交流。如果你现在没这么做，你应该马上考虑这样做，与分散开发队伍同时进行。在各个软件构件和原始团队中间应该有一个显而易见的筹划，每一个构件都有自己的资源库和部署位置和流程。 决定人员分布有些武断的成分在。我的办法是跟每个开发者坐下来谈心，深入了解他们最喜欢工作的领域。因此我人尽其能地分配我的团队。一些人发现第一次团队分配很适合他们，而另一些人不是很满意，他们需要马上转到别的团队。随着时间的推移，团队的分工日益明确，我们能更加容易地人尽其才。让开发者追随自己的内心，然后他们将会到最适合自己的团队做自己最擅长做的工作。 到这个节点，你应该很清楚自己的产品和市场的契合点。如果公司发展到这个规模。你还在寻找公司存在的意义，你就遇到大麻烦了。如果事实果真如此的话，你应该停止公司的业务扩展，停下脚步直到发现切合市场的产品。 
Adam Wiggins
专门化 另一个分组的动机是专门化。工程专家的分类包括ops工程师高级系统管理员、基础设施开发者、前段网络开发者、后端网络开发者、业务工程师、数据分析师和聚焦特定编码语言的开发者。编码语言专家越来越普遍，因为越来越多的互联网公司使用诸如Erlang、 Scala或Clojure等函数程式语言写入高并发组件。这些函数程式语言由不同的开发者负责，而不是 Ruby、 Python、或是 PHP网络组件的创始人。 在早些时候，专家很难令人满意。发布软件产品工作有很多层级，关系到很多有贡献的人，每个人都有贡献。这使得开发者兼顾非常广泛的领域，从ops项目例如OS上的kernel更新到前端项目例如为UI编写jQuery效果。 一旦你拥有了12个开发者，你的产品已经有了一定的使用量和成熟度，同时也出现了一些问题。管理数据库不仅是个全职工作，更需要很强的专业知识背景，如果这人同时学习jQuery 、iOS和Erlang ，他是不能够胜任这份工作的。 你需要这样的员工，他们能够而且乐于专注于某一领域，这样他们才能成为这一领域的专家。一些人将是目前的多面手，他们愿意专注于某一领域，而另一些将是新雇佣的员工。你现在能够雇佣些专家，这些人在公司规模缩小后将不会再适用于公司。有多面手在身边总是有用的，一些多面手也许能进入管理层，成为公司团队的股东而不是亲力亲为的开发者。 Heroku的首批团队 Heroku的初始团队分布如下; ● API-拥有面向用户的网络应用和与之相配套的Heroku客户品质 ● 数据— 建构运营数据库系统 作为数据库服务产品 ● Ops-维护运行系统的有效性 ● Routing–管理 能协助用户Web流程 获得HTTP路由请求 ● 运行时间—处理包装代码 为了 部署、开始、停止、管理 户进程 每个团队都由1-5个部分组成。例如，API团队拥有Rails app，在api.和“Heroku客户品质”运行。数据团队拥有为数据库服务的开通和监控工具，还有个人运行数据库。Peter van Hardenburg 是数据组的创始人和现在的领导者，他在视频的后半段谈到了这一点。 团队规模和角色 对我们而言，理想的团队结构式2名开发者，一个业主。一个开发者长期来看是不够的，我们需要另一双眼睛来看代码，一总是一个寂寞的数字。三个开发者也能运行的很好。到了4-5个人时事情就会变得复杂了，因为没有足够的空间让所有的工作不重叠。几乎所有的 Heroku团队都有2名开发者。 业主是有些拙笨的一个词汇，但这又是最好的一个词，用来形容一个人同时做着产品管理、项目管理和团队的综合运营等工作。业主为团队注入了商业认知和价值观，还有如何才能扩大生产规模。他们能够促进跨团队沟通，通过商业价值区分项目和任务的优先级，或许还能够为高管和整个公司提供团队进展的现状报告，这也许会决定这个团队的生存。 我是互联网创业公司“业主”角色的爱好者：很强的技术背景意味着他们对自己所做的工作有很深刻的理解，而且能够很好的控制他们团队对自己的敬意。这类型的领导者不是在每个团队都找得到，但我们应该尽可能的去找。在很多情况下，这就在说服的功力，使一个技术人员放弃自己最初的梦想——编码。 不要让开发者隶属多于一个团队。他们是创造者，需要在团队现行的项目上持续保持专注度，不能够为了别的任务分心。然而，业主又是可以多任务操作，也不总是一个全职工作，一个业主在2个以上团队工作对跨团队交流沟通是有益处的。 凝聚力 在前几个阶段，你应该让所有的开发者专注于一个单独的目标，避免多线作战。当为单独的团队设定了专业领域之后，情况就有变化了。你应该开辟多个战场。各个团队独立作战，不需要关心别的团队在干什么。 同时追3-5个大项目是很酷的。在Heroku分组后的几个月之后的某一天，我们三个不同的团队都有了重大的进展，这是一种难以置信的感觉。 但现在你会有一个新的问题：缺乏凝聚力。分散的团队会制定各自的路线图，独立决定今后的特色。为了避免产品的碎片化，需要有人制定一个总体的规划和一个总的产品价值体系。更简洁的说就是需要制定一个战略。
|
|
|
