设计工程组织
您应该如何组织一个更大的工程组织，一个拥有数十名（或数百名）工程师的组织？有许多折衷考虑，没有一个正确的答案。但是，有些结构比其他结构更好。
这里的指导原则是，Conway的定律是不可避免的–您要运送组织结构图。并且，如果可能，您应该优化交付。 （这似乎很明显。很明显吗？）因此，您想尝试建立一个与您实际运送的产品尽可能一致的组织。换句话说，您的目标是建立一种反向康威定律：设计您的组织要匹配您要发布的内容。
否则，您的组织将在产品跨越组织边界的任何地方挣扎。例如，如果您拥有独立的移动组和网络组，那么您将很难交付在各个平台上都能正常运行的产品。这并不意味着就没有时候打破这一指导原则了–通常有令人信服的理由来设计不同的团队。但是请注意您接受的交付速度的权衡。
对于以产品为中心的团队，每个团队负责您的某些面向公众的产品。例如，如果您要构建音乐播放器，则可能会有一个播放列表团队，一个音乐提取团队等。另一种查看方式：如果外来人员查看您的产品可以绘制出相当准确的组织结构图，与产品相关的组织
以技术为导向的组织更多地基于后端技术进行细分。因此，您可能有一个数据库团队，一个后端软件团队，一个前端Web团队，一个移动应用程序团队等。
通常，以产品为中心的团队可以更快地交付更好的产品。再说一次，康威定律是不可避免的。如果要交付一项新功能需要多个团队进行协调，那么与一个组织可以由一个团队执行一项新功能的组织相比，您将很费劲。
建立以产品为基础的团队并不总是那么容易，尤其是大规模的团队。较大的产品可能很难按产品线细分到足够精细的程度，以至于无法容纳规模庞大的团队。而且，经常有一些基础工程与单个产品功能不符。
大型组织通常最终需要混合使用：一组平台团队，用于构建和维护基础结构，共享库和工具；以及一组直接在产品上工作的产品团队。
在稳定的团队中，员工会加入团队并无限期停留。团队是长期存在的，而项目属于团队：团队可能随着时间的推移而从事不同的工作，但人员却保持不变。
基于项目的团队组成以处理特定项目，并在项目结束时解散。团队是临时性和目标驱动的。每个项目都有不同的人员。
稳定的团队是产品组织内部的规范，而基于项目的团队则在咨询店或服务组织内部更为常见。
通常，稳定的团队会产生更好的结果。在团队凝聚力的形成，风暴，规范，执行阶段，团队需要一段时间才能“凝结”并以最高的生产率工作。我的经验是，至少需要6个月才能达到“表现”水平，有时还需要更多时间。如果员工更频繁地更换团队，团队将永远无法发挥全部潜力。
基于项目的团队的主要优势在于技能设置和人员配备水平的灵活性。这就是咨询组织倾向于项目团队的原因：几乎不可能预测下一个客户需要什么样的技能/人员，因此为每个新客户组成一个新的团队值得在生产力损失方面进行权衡。但是，可以管理稳定团队的咨询组织-例如通常，通过拥有一组团队，并将项目分配给最合适的团队，通常效果会更好。
有时，产品组织会希望组建临时团队来处理某些重要的战略项目。我在Heroku期间的一个例子：我们是一个拥有稳定团队的组织，但是当我们决定建立Private Spaces时，我们认为该项目足够重要（并且在技术上也具有挑战性），因此可以组建一支专门团队专注于该项目，即使它以复杂的方式遍及整个组织。
这可能是一个有效的举动，特别是如果希望团队持续足够长的时间来度过成长的痛苦。将新团队专用于一个特殊项目是打破组织惯性并获得新成果的好方法。它也有一些缺点：加入这些“特殊”团队经常会遇到竞争，对那些未被选中的人的不满，以及在项目缩减时人们不愿意退回到原来的团队。 （我们在Heroku上看到了这两种方法，但是执行时的权衡是值得的。）
大多数团队不是纯粹的工程团队；他们需要其他技能。设计与制作项目管理是最重要的。但是，即使只是在工程领域内，在一个以产品为中心的团队中，有些团队可能仍需要具有各种各样技能的员工-前端，后端，移动开发人员等。
单学科团队按技能集对人员进行分组，例如，使用Python / Django的后端团队，前端JS / React团队，Android和iOS团队等。产品和设计是独立的团队/组织，而这些人员浮动有时会支持多个团队。
跨学科团队将团队需要执行的所有工作整合在一起。因此，一个团队可能需要后端和前端开发人员，设计师和产品经理，内容制作者和编辑者-可能需要交付任何东西。
通常，跨学科团队的表现要优于由单学科团队构建的组织。出于以上原因，我也是出于同样的原因：康威的法律和团队凝聚力。如果设计是与工程分开的职能，那么您的组织每次需要发布既需要工程又需要设计的功能时，都需要支付组织费用（阅读：全部）。这通常会导致设计在最后一刻被“拍打”的功能，或者看上去很漂亮但功能已损坏的东西。
但是，跨学科执行可能非常困难。一方面，团队可能变得笨拙：复杂的产品可能需要太多不同的技能，以至于需要太多的人才能组成一个团队。可能有一种方法可以分解该产品，但有时没有。
在多学科和/或产品组合的团队中，报告如何工作？如果集成团队中有设计师，他们会向谁报告？交付团队的经理还是设计师？
在与技能相关的报告链中，人们向与他们的技能相匹配的经理报告。工程师向工程经理汇报（他们汇聚到工程总监和工程副总裁）；产品经理向其他产品经理汇报（最多产品副总裁）；设计师向设计师汇报，等等。
借助与交付情况相符的报告链，无论纪律如何，员工都可以向其交付团队的经理报告。因此，由设计师，工程师和产品经理组成的交付团队都向同一个人（可能来自任何这些学科）汇报工作。
通常，以交付为准更有效。组织正在尝试优化交付，并且让一个团队（包括其经理）完全负责交付是非常有效的。与技能保持一致的团队可能会在实际交付方面遇到困难：当他们错过最后期限时，将矛头指向其他团队可能比承担责任更容易。
与技能保持一致的团队面临的最大问题是，他们通常会下放到矩阵管理中。人们最终会正式向某位经理报告，但在其他项目经理或团队领导下进行日常工作。 （或者，更糟的是，还有其他多个项目负责人）。由于经理看不到日常工作，因此他们将无法提供有效的反馈或了解团队的绩效。充其量，他们可以询问项目负责人的进展情况并传递这些信息，但是电话游戏并不能带来很好的反馈。在绩效评估期间，您会最清楚地看到这一点，因为经理对员工的绩效没有第一手的了解，所以这非常困难且充满压力！
通常，对交付对齐的团队的反对是这样的：“嘿，我是工程师，我无法向项目经理报告！他们怎么可能理解我的工作！？”用专业术语来说，这是废话。
事实是，管理是经理最重要的技能。我们知道，优秀的工程师不一定能成为优秀的经理。那是因为这是一套完全不同的技能。管理技能（反馈，指导，解决冲突，团队建设等）在各个学科之间都可以很好地转化。
现在，领域专家确实需要特定领域的指导和反馈，而且来自不同学科的经理不一定总是能够提供反馈。也就是说，我可以帮助Python程序员调试损坏的测试，但不能为设计人员提供有关选择调色板的指导。 （嗯，我可以，但是没人会对结果感到满意！）
因此，拥有交付团队的组织需要创建其他渠道以用于特定领域的指导和反馈。 这通常采取“行会”或其他类型的实践社区的形式。 如果您要针对交付进行优化，那么应该遵循稳定，多学科且与产品保持一致的原则来指导您组建团队的方式。 出于某些原因（其中有些很好）可以背离这些原则，但总会有一个折衷方案，那就是运输难度更大。 感谢Aidan Feldman向我提出了有关激发这篇文章的工程组织的问题。
