通常，当软件工程团队发展壮大时，您会发现生产率（定义为每人生产的工作量）下降。 任何功能的增加似乎都是永久的。 当您思考问题出在哪里时，您会发现这句名言安慰人：
“在一个较晚的软件项目中增加人力会使其变得更晚。” —弗雷德里克·布鲁克斯（Frederick Brooks），《神话人月》。
那么，你注定要失败吗？ 甚至尝试将人员添加到工程团队中是否浪费？
当我们向Freshworks的工程高级副总裁STS Prasad， BrowserStack的工程副总裁Sourav Sachin以及BrowserStack的首席技术官兼联合创始人Nakul Aggarwal询问时，答案很明确 。 他们认为，确实有可能加速增长并与团队规模的增长成比例地（或几乎成比例地）提高速度。 这就是他们建立印度两家最成功的科技创业公司的方式。
在孟买的BrowserStack办公室举办的#LearnAtAccel活动中，他们分享了扩展工程团队的经验。 一群渴望从坚强者身上学习的其他新兴工程负责人，倾听了他们的心声，并向他们提出了棘手的问题。 我们得到了有趣的答案。
当我开始审理程序时，令我震惊的第一件事是工程师之间迅速形成的友情。 他们很快就彼此适应了，这是我认为技术人员永远不可能发生的事情。 快速介绍其中的每一个（少于一分钟），有时会持续五到六分钟！ 谁会期望技术专家这么长时间谈话？
在介绍他们时，我要他们谈论的一件事是困扰他们的问题。 这些是他们最关心的三个问题：
- 招聘
- 招聘
- 招聘
一点也不奇怪。 但是，令我更为震惊的是，甚至没有与技术遥相关的问题。 人们强调了年度审查，流程，团队结构等。但是，通常的SQL vs. NoSQL，Node vs. Go或AWS vs. GCP都没有。 在介绍之后的整个五个小时中，即使是整个激烈的互动，也没有一个技术问题出现。
但是，即使对于像我这样的技术人员，这也是一个非常有趣的讨论。 因此，在这篇文章中，我试图从这次会议中总结我的所有经验。 它主要包含演讲者的智慧，但也包含我自己的一些想法以及与会人员的一些想法。
6的力量
扩展工程团队的全部目的是保持人们在快速协作，沟通，创新的工作启动模式。 但是你也要尽力而为 。 这是您需要随着成长而减慢的部分–您也必须以正确的方式开始做事，而且很多时候，这可能与所需要的哲学背道而驰。
根据“ 6的力量”来考虑团队规模是很有用的。软件团队的成长分为三个阶段：
- 早期阶段-少于6人：团队尽其所能，快速而肮脏的工作。
- 最初的成长-最多可容纳36人：您仍然适合一个办公室，而且许多早期实践可能仍然有效。 但是，在这个阶段中，您必须密切注意发生的事情并为下一个阶段做准备。
- 高增长-超过36岁：这是您需要建立结构和流程并认真思考如何组织事物的时候。 在这里，您不再说“这是我们过去做过的事情”。相反，您开始思考如何做事并为之辩护。 因为每个低效率都会乘以36或更多。
高增长阶段的挑战
当团队进入“高增长”阶段时，您将遇到许多前所未有的挑战。
技术债务
您开始意识到过去所做的一切都产生了很多代码。 您会发现缺少单元测试，会发现规模问题，并且会发现糟糕的设计决策使您陷入困境。 您甚至可能会渴望重写整个产品。
但是您还会发现业务人员的阻力，他们不会在重写甚至小型重构项目中看到任何价值。
成功处理技术债务始于企业与工程部门之间可信赖的合作伙伴关系。 您必须显示要添加的值，通常是将来速度的增加和/或灵活性的增加。 由于工程师倾向于过度设计，因此根据硬数字来证明更改是一件好事。 这样可以确保重构确实为业务增加了价值。
还必须将与每个重构有关的时间和方法的决定与业务结合起来。 有时，您可以将其用作现有功能的重大改进的一部分，有时，您可以在待办事项中将其变成纯技术故事。 无论采用哪种方法，最好将产品分成足够小的部分，以便团队可以完全控制每个部分或模块。
我的一个明智的朋友经常问：“你怎么吃河马？”看着我们茫然的面孔，他会回答：“一件一件。”在处理技术债务方面，没有什么比这更真实了。 永远不要一次重写整个产品，而要采用增量方法。 完整的重写方法通常带有过于乐观的估计。 重新测试整个产品的风险和精力也常常被忽略。
您还需要处理另一种债务： 产品债务 。 这是关于错误的功能决策，而不是错误的设计或代码。 有时是由于渴望取悦一些早期客户，而有时是由于对用户需求的不完全了解。 必须不时地进行硬调用以删除功能，因此要考虑基础架构的更改或重构时，通常会阻碍一大段代码。
每个额外的功能都带有额外的错误和额外的维护。 删除那些没有增加足够的商业价值的功能，以证明错误修复和维护的成本是合理的。
工程师分心
您可能看不到这一点，但是您发现工程师在过去的工作上花费的时间不到一半：构建功能。 现在，他们花费大量时间来处理生产问题，客户问题和突发性的高优先级要求。
前两个问题的正确解决方案是雇用或加强运营团队和客户支持，以免开发人员分担这些费用。 但是处理新计划外工作的中断并不是那么容易。 临时工作有两种：
- 生产错误
- 紧急功能请求
对于大多数人来说，“虫子”是一个讨厌的词。 对于工程师来说，这也是一个骄傲的问题，因此必须立即修复错误。 但实际上，并非所有错误都需要立即修复。 必须客观地评估影响，发生的可能性和受影响客户的百分比。 仅在完全合理的情况下，才应在冲刺过程中进行错误修复。
但是仍然存在如何为这些错误进行预算的问题。 一种选择是拥有一个专门的团队（也许有轮换成员）。 但这并不能扩展，因为您不能期望这个团队的成员是专家，甚至不熟悉代码的所有部分。 您会发现，这个“维护”团队经常会咨询代码的原始所有者，从而破坏了消除干扰的原始目的。 如果您希望维护团队只进行第一级分析，那么，组织中真正缺少的是L2支持团队。 他们是应该进行第一级分析的人员，而不是您的开发团队。
最好将实际维护工作留给在sprint内拥有组件和预算的原始团队。 它不仅可以建立所有权，而且可以提高效率。 随着时间的流逝，您将知道需要多少缓冲才能解决这些错误修复。 它还将使您的工程师考虑如何提高代码质量，从而最大程度地减少生产中的错误。 这不会是别人的问题。
但是它仍然不能避免上下文切换。 一整天都在考虑产品功能的工程师仍然因错误修复请求而分心。 解决此问题的一种方法是分配时间（例如每天5-6 pm），这些时间是此类修补程序的时间限制。 这还具有以下优点：可以限制花费在这些上的时间，并自动创建反压力以优先考虑修补程序。
对于紧急的新功能，这是计划问题，也要与业务团队建立信任关系。 如果您正在关注Scrum，这是自动的。 功能请求总是进入待办事项列表，它们是作为Sprint计划的一部分进行讨论和处理的，而不是在Sprint的中间。 这具有以下优点：
- 敏捷性和稳定性之间存在一个很好的折衷-工程师被单独留给整个冲刺，但是业务可以完全改变优先级（在冲刺之间）。
- 待办事项总会作为一个整体进行审查—没有新近度的偏见，并且事情不会因为仅仅考虑了一项功能而成为优先事项。 将它们与列表中的所有其他对象进行比较，并且相对优先出现。
您也可以考虑使用一个可以简化整个过程的角色，即技术计划经理。 他们可以减轻工程主管的重复性任务，还可以简化工程与其他紧密职能（例如客户成功，运营和其他利益相关方）之间的协调，理解和信任。
换旧手
随着团队的成长，早期工程师会感到失去控制。 这通常是因为新员工，同事对他们提出质疑或做事有所不同。 此外，由于引入了正式的产品管理功能，工程师在塑造功能及其优先级方面的发言权较少。
当务之急是您要对最初的人员进行投资，而不要随着团队的成长而理所当然。 由于早期获得的上下文和知识的深度，它们的存在比您想象的要有价值得多。 他们失去控制的感觉是很自然的-您应该听到他们的声音并与他们共度时光，与他们交谈，并使他们适应新的现实，其中之一就是塑造特征不再是他们的工作。
这并不是说他们没有发言权或知名度。 产品路线图的透明度，每个功能如何影响业务以及对最终用户的同理心都非常重要，这不仅对老手来说很重要，对每个人也很重要。 杀死生产力的最好方法是只告诉工程师该做什么而不告诉他们为什么。 至于旧手，一定要获得他们对核心产品变更的投入。
最后，一切都与沟通有关。 只是更大的团队需要更多。 路线图必须随附客户上下文，业务上下文和用户上下文之类的内容。 最初的人工会议和团队会议似乎很浪费，但是当您查看每个工程师的观点时，就会明白为什么需要它们。
将经理人与技术人员分开
您会发现，一些“好”员工承担了必须管理其他人才能完成工作的额外责任。 也许他们在这方面做得不错，但您还会发现自己没有充分利用他们的技术能力而在失败。
人们很容易想到，如果一个人擅长一件事，他或她也会擅长其他事情。 将其作为编程和管理来阅读。 不要犯这个错误。 确定哪些高级人员已准备好领导团队（并愿意这样做），哪些人希望将自己的鼻子深深扎根于代码中。 如果您不区分这两种人，那么您不仅会损害产品，还会破坏一些职业。
为了区别起见，团队负责人负责管理团队，领导和产品（或子系统）的交付。 技术负责人负责确保事情做对 。 从RASCI矩阵或其变体的角度来考虑这些是很有用的。
建筑师是技术主管的演进版本，但您不应让建筑师住在象牙塔中。 架构师需要具有业务意识，并应为产品做出积极贡献。 除了制定技术和架构决策外，他（她）还优先考虑，权衡取舍和估算。 他们不应充当顾问并仅提供文档，他们还需要交付代码和功能。
通讯细目
随着团队的成长，最大的挑战是维持早期阶段的信息交换水平。 早先，每个人都知道一切，但现在已经不知道了。 由于团队规模庞大，不再可能通过走廊上的对话或晚上的饮料传播什么。
要做的一件事是避免分散的团队。 这不仅使您的通信需求超负荷，而且还导致位置之间的信任问题。 当然，在极少数情况下（我曾经参加过，但我相信这是很少见的），多地点团队确实取得了成功。 但是，这需要深入理解和信任，或者需要两个位置负责人之间的“联系”，以及明确的职责划分。
另一件事是投资于文档。 哦，我知道，我知道，你在说：“但是，敏捷宣言Vasan说，与文档相比，他们更喜欢工作软件。 如果我们花时间在文档上，我们就不会敏捷。”
好的，我想区分两种类型的文档（如果需要，您也可以将它们称为频谱的两端）：
- 暂时的，指导性的：这些是告诉别人该怎么做的文件。 完成后，可以将它们丢弃。
- 永久参考：这些是基本参考文件，很少更改。 如果确实发生更改，则您不介意更新这些文档。
不要投资第二种文档。 务必写下所有您不想忘记的东西。 这包括考虑的选择以及做出特定决定的原因（这样，您就不会在每次再次遇到相同的选择时都绞尽脑汁）。 它还包括流程图和状态图之类的东西，这些东西很难从工作产品本身中收集。 您可以在新员工上班的第一周里阅读这些内容。 这些是经常参考的有用参考。
对于第一种，白板并用手机在其末尾拍摄照片效果很好。
结论
乍一看，《神话人月》盯着我们，告诉我们，不可能使Velocity成为团队规模的线性函数。 但是人们已经做到了。 总而言之，以下是您可以做到的事情：
- 处理技术债务：认识到它，花时间修复它，但是要证明它是合理的。
- 避免分心：让工程师去做自己最擅长的事情，让别人来处理其他事情。
- 保护老手：与高级工程师共度时光，让他们参与进来。 它们比您想像的更有价值。
- 认识不同的技能：为人员创建管理路径和技术路径，将高级人员彼此识别。
- 经常交流：团队规模越大，您就越需要。 投资于结构化的交流和良好，适当的文档。
