任何成功的初创公司成功的关键是产品和工程之间的密切协作。这听起来很简单，但实际上可能非常困难。这两个团队可能会有冲突的目标和不同的成功定义，需要协调。工程团队可能希望构建一个具有最佳开发人员体验的，可完美扩展到未来的产品。产品团队可能希望快速验证他们的想法，并推出吸引客户付费的功能。另一个常见的例子是工程主导的“工程路线图”和产品主导的“产品路线图”，两者完全独立，导致产品工程的混乱。这两种思维方式让你的组织的两个部分相互矛盾。最简单的做法是跳过艰难的对话，在孤岛中运作，偶尔聚在一起发布版本。我们相信，将这两个不同的组织整合到有凝聚力的团队单元中，可以消除组织摩擦，提高价值实现时间。
你是如何陷入瓶颈的？
在初创公司旅程的开始，对齐是自然的，因为你是一个紧密合作的小团队，而且产品和技术领导者很可能在公司成立之前就建立了密切的个人关系。最初的创业想法非常强大，并且随着它迅速获得吸引力，接下来要做什么对所有团队来说都是显而易见的。然而，随着公司的发展，基于技能的垂直领域开始出现，管理层也增加了更多层级，这些管理者并不总是努力与他们的同级建立有效的合作关系。相反，他们专注于紧急任务，比如保持应用程序运行或准备融资轮。与此同时，初创公司面临着一个关键的转折点，公司需要决定如何最好地投资产品，并需要一个整体的策略来做到这一点。
运营良好的初创公司已经在跨职能的产品团队中工作。一些职能会自然地很好地协作，因为它们属于同一个垂直层次结构。例如，开发和测试——在初创公司中很好地整合，但在传统的企业 IT 中通常是孤立的。然而，在我们与之合作的扩展公司中，我们发现产品和技术团队是相当分离的。当员工在活动导向组织中更多地与他们的职能保持一致，而不是与结果导向团队保持一致时，就会发生这种情况，并且这种情况发生在各个层级：产品经理与技术主管和工程经理不对齐；主管与主管不对齐；副总裁与副总裁不对齐；首席技术官与首席产品官不对齐。
最终，瓶颈将通过降低组织绩效而感受到，因为它会扼杀客户和业务价值的创造。初创公司会看到它表现为组织紧张、破坏性异常、不受控制的技术债务和速度损失。幸运的是，有一些关键的迹象表明产品和工程组织之间存在摩擦。在本文中，我们将描述这些迹象，以及降低沟通障碍、构建平衡的投资组合、最大限度地提高投资回报率以及长期最小化风险的解决方案。
如何摆脱瓶颈？
消除产品和工程之间的隔阂对于建立高绩效产品团队至关重要。跨职能团队必须有效地沟通和协作，他们必须能够就如何最好地实现目标进行协商。这些是 Thoughtworks 在与我们的扩展客户合作时克服这种瓶颈所采用的策略。
识别并强化你的“第一团队”
从最基本的层面上来说，产品团队是一群人，他们围绕共同的目标共同行动，创造业务和客户价值。每个团队都以自己独特的方式或以自己独特的范围为价值创造做出贡献。作为领导者，重要的是要识别并强化围绕价值创造而不是组织报告结构的团队动态。这个跨职能产品团队成为团队成员的“第一团队”。作为领导者，当你将你的团队定义为你的直接下属时，你正在启用一个部落概念，这会导致“我们与他们”的动态。
第一团队思维方式由Patrick Lencioni定义，并在他的许多作品中引用，包括The Advantage和The Five Dysfunctions Of A Team: A Leadership Fable，虽然它通常用于与建立跨职能领导团队作为主要问责团队而不是组织报告相关，但同样的概念也适用于产品团队。
仅仅改变你组织的语言，而不改变它的行为，不会对你的扩展困境产生可衡量的影响。尽管如此，这是一个简单的起点，它解决了导致绩效问题的组织摩擦和更大的文化问题。
改变语言
一个组织愿意在打破孤岛方面越积极，它就越有可能有效地打破一些使它们能够存在的隐含的“与”状态。
-- Duena Blomstrom
采取积极主动的方式来调节组织中使用的语言，是打破障碍和减少摩擦的简单第一步。
- 将你的组织从业人员群体称为除“团队”以外的任何其他名称——例如，小队、豆荚，或者适合你组织文化的任何术语，这是一个可以产生重大影响的小变化。
- 为你的跨职能产品交付团队命名，理想情况下使用他们的产品或价值流的名称，是另一个简单的改变，它可以帮助这些多学科的个人采用一个新的团队身份，与他们的组织报告背景分离。
- 从专业词汇中删除“我们”和“他们”。想出替代术语，但保持相同的“那边那个群体——不是这个群体”的语境，这是在作弊。我们在专业环境中经常过滤自己和我们的语言，这种语言需要添加到“不允许”列表中。
改变行为
我们这些试图改变组织文化的人需要定义我们想做的事情，我们想以什么方式行事，以及我们希望彼此以什么方式行事，提供培训，然后做必要的事情来强化这些行为。文化将因此而改变。
-- John Shook
当一个组织没有产生预期的结果时，改变它的文化是很难的。关于这个主题已经写了很多书。通过事先定义和传达团队及其各自团队成员的预期行为，你为你要创造的文化的基调奠定了基础。
- 领导者应该树立一个无责文化的原则和期望。当出现问题时，这是一个很好的学习机会，可以对其进行研究并用于持续改进。一个例子是无责事后分析的概念。
- 设定期望，并定期检查期望行为的采用情况。让团队成员对这些行为负责，并拒绝容忍例外情况。
- 面向“团队”的构建围绕价值流而不是功能。将“团队”定义为交付共同价值的群体，区别于通常为了深化或交付特定能力（如产品管理或质量保证）而组成的实践社区或卓越中心。
- 承认某些性格类型之间的兼容性较低。将有才华的人员调动到不同的位置，以找到最佳的团队协同效应。
定义和传达你的扩展如何交付价值
从很多方面来说，一家公司就是一个拥有共同目标的大团队——组织的成功。当产品和工程团队对该目标没有共同的理解时，他们很难就如何实现目标达成协作协议。为了避免这种摩擦源，高管必须明确阐述并传播其组织为客户、投资者和社会提供的整体价值。领导者有责任描述产品组合中的每个产品和服务如何为交付该价值做出贡献。管理层必须确保每个团队成员都了解他们每天的工作如何为组织及其客户创造价值。
目标是创建一个关于企业如何创造价值的共享心智模型。实现这一目标的最佳方式高度依赖于企业的性质。我们发现某些类型的资产在我们的快速成长型客户中既常见又实用。
描述客户和用户价值的资产
这些资产应该描述您的产品和服务创造的价值、为谁创造价值以及衡量该价值的方式。示例包括：
- 商业模式画布/精益画布
- 用户旅程
- 服务蓝图
- 人物角色
- 同理心地图
- 故事板
- 工作力量图
- 产品概述（一页纸等）
描述您的经济模型的资产
这些资产应该描述您的公司从客户那里获得的价值、创造该价值的成本以及衡量该价值的方式。示例包括：
- 商业飞轮
- 价值流图
- 沃德利地图
- 留存率/流失率模型
- 客户获取模型
- 客户终身价值模型
- 预计资产负债表和损益表
描述您的战略的资产
这些资产应该描述您选择以这种方式服务这些客户的原因、您用来做出该决定的证据以及您可以提高创造的价值和收到的价值的最高杠杆方式。
- 目标客户画像
- 问题树
- 影响图
- 机会/解决方案树
- 层次结构图
- 因果循环图
- 其他定制框架和模型
拥有这些资产后，重要的是在演示文稿、会议、决策时以及最重要的是发生冲突时不断参考它们。在更改它们时进行沟通，以及更改的原因。征求组织的更新。简而言之，将它们纳入您的日常运营，不要让它们成为墙纸或另一个隔间装饰。
我们发现的一个简单启发式方法是，选择一个随机的个人贡献者，让他们回答这些资产所回答的问题，以此来了解您在沟通方面的成功程度。他们能够在不参考资产的情况下回答这些问题，就越能将这种思维融入他们的工作。如果他们甚至不知道这些资产的存在，那么您还有很多工作要做。
这些资产创造的协调性和重点可以更好地部署组织资源，从而实现扩展。此外，它们可以重新引导产品和工程之间的自然张力。您可以使用创建和更新这些资产作为真正的协作和关于加强公司的想法的健康分歧的场所，而不是无益的人际摩擦。
创建跨学科的流对齐团队
当一家公司刚刚起步时，它通常只有一个价值流。但一旦它发展壮大，它就需要将产品和服务分解成多个价值流，以便各个团队可以完全拥有各种产品或产品的一部分。这种分解的最佳方式超出了本文的范围（我们个人非常喜欢团队拓扑作为一种思考方式），但一些需要考虑的关键事项是：
- 这个价值流及其包含的产品和服务可以作为一家独立的公司存在吗（即使它不会非常成功）？
- 您可以将您的价值流与公司创造价值的特定方式，或公司为其创造价值的特定客户或用户对齐吗？
- 您的不同价值流如何相互作用？
定义价值流后，是时候将多学科团队成员聚集在一起——因为价值创造是一项团队运动。请这些价值流的领导者创建类似但更详细的资产版本，然后确定从头到尾交付和发展价值流中产品和/或服务价值所需的技能和能力。
将这些人集中到一个结果导向团队中，而不是跨活动导向或功能团队协调工作。在敏捷 IT 组织设计中，Sriram Narayam 指出：“流程和间接性越多，有效协作的摩擦就越大。相反，团队内部的人员无需安排会议来相互协作。他们不断地协作，并根据需要进行非正式的即时会议（虚拟或面对面）。”虽然这种模式有助于减少结果导向团队内部的延迟，但也减少了多学科团队成员之间的摩擦。
请记住，随着公司的发展，您可能需要拥有“团队的团队”，多个团队围绕一个价值流进行协调，以及该价值流的跨职能领导者团队。随着价值创造的复杂性增加，跨产品交付团队保持共同目标的重要性也随之增加。
产品经理和软件工程师有共同的责任来了解客户的需求，以便他们能够定义和优先排序工作。没有产品人员与工程师的理想比例；每个产品都将有不同的比例。重要的是要知道，两者都负责理解、优先排序和创造价值。
随着产品的演变，团队的需求也会随之演变。定期盘点团队的能力，并授权与流对齐的团队为自己的需求进行辩护。确保团队拥有充分的资源，包括人员、技能、信息和权限，以便能够高效地交付，而无需过多依赖外部资源。资源充足、授权且自主的产品团队作为一个整体运作，无论每个人的汇报结构如何，都能够显著减少跨学科的摩擦。
在所有级别建立团队工作协议
确保每个团队成员都知道自己在扮演什么角色
最好的团队是那些已经协商出最适合自己的工作方式的团队。对于组织来说，建立合理的默认值来指导不太成熟的团队如何有效地作为一个团队工作非常重要。即使有既定的默认值，团队也必须拥有自主权来决定哪个成员承担哪些责任。这种自主权的衡量标准会导致更高的责任感和更高的内在动机。当新的团队组建时，将这种工作协议编入团队的共同知识库中。在回顾会议中，随着团队更多地了解每个团队成员的优势和劣势，重新审视这种团队工作协议，并相应地重新分配责任。这种团队工作协议既成为团队的社会契约，也是其他团队所没有的独特的“责任指纹”。当新的团队成员加入或轮换到团队时，拥有可参考的团队工作协议可以加快整合，并在入职期间减少价值实现时间。
团队工作协议通常包含以下内容：
- 团队名称：团队的唯一标识是什么？
- 团队使命：这个特定团队存在的意义是什么？它预期交付什么价值？
- 团队指标：团队将如何衡量成功？包括价值创造指标，而不仅仅是活动指标。
- 团队职责：为了确保成功需要完成哪些工作，哪些团队成员同意拥有这些工作项目？组织可以将典型活动和团队责任分配建议作为种子，但团队成员可以自由地在彼此之间重新协商。
- 团队技能：这个特定团队需要哪些技能才能确保成功？
- 团队规范：团队成员在行为、互动和决策方面应遵循的准则、原则、仪式和/或合理的默认值。
协商平衡的产品投资组合
上图解释了平衡投资组合的最佳点，我们在这里权衡了技术与产品的投资。过度投资于产品功能繁重的积压可能表明对技术债务和跑道的投资不足，导致解决方案设计不足，而过度投资于技术繁重的积压可能表明对客户价值功能的投资不足，以及解决方案设计过度。很难知道何时达到完美的平衡。随着公司发展和转型，它可能会随着时间的推移而改变。
我们经常遇到的设计不足的一个例子是，产品在可用性方面存在问题。这个问题意味着开发团队必须花时间灭火，这会降低专注度并影响他们的生产力。虽然这在您规模较小时可能是可持续的，但如果您的客户使用量激增（在快速增长中），团队就会不堪重负，客户体验也会受到影响。当您的业务最无力偿还时，这种债务偿还总是会到来。
如果技术团队过早地进行了太多优化，就会导致另一种不平衡，最终导致过度设计。一个例子是过度拟合的架构，这些架构是为处理数十万用户而构建的，而公司只有十个用户。当创业公司转型时，很多工作最终都被抛弃了。在构建可扩展的产品以应对未来需求与构建当前生存所需的产品之间，始终需要权衡。
重要的是能够发现这种组合何时失衡，并能够纠正它。持续改进过程非常重要。如果一个团队（在产品团队级别或管理团队级别）意识到他们的共同目标，那么跨职能团队可以定期评估平衡，并使用数据作为指导。一些数据是可量化的，而另一些则更主观。您可以用来指导您的信息包括：
- 收集个人意见——工程师是否感到高效和积极？产品经理是否认为团队效率很高？
- 生产力指标——我们能多快地测试和构建新功能？
- 当前状态和近期未来状态的看法——我们是否为了未来的可扩展性而过度复杂化构建？
- 产品增长——我们是否知道我们正在朝着产品的目标前进？是否有足够的分析、用户测试和客户反馈来确认我们的产品投资正在取得回报？
- 趋势——随着我们构建更多功能或增加用户，指标如何趋势？例如，查看构建时间、部署到生产环境的交付时间和事件数量等指标。随着复杂性的增加，技术投资应该控制它们，并减少开发人员的繁琐工作。
一位经验丰富的技术专家，他已扩展了技术平台，非常有价值。他们可以利用自己的直觉来解读数据，发现潜在的未来问题，同时采取务实的观点。
考虑跨职能需求
一个好产品不仅仅是拥有最新功能的产品。
- 它必须构建为高性能、可靠和稳定的产品。
- 它应该是成本效益高的——运营产品的成本不应超过产品产生的收入。
- 产品的底层架构应该能够快速有效地进行未来的功能开发。
- 它应该考虑到客户扩展，并且能够扩展，而无需太多返工。
- 它不应将私人客户或业务数据置于风险之中。
这些以及产品的许多其他品质都属于跨职能需求的范畴。为了尽快推出新功能而未能考虑这些需求会导致复合问题。
有些问题比较明显，因为您可以观察到它们。当客户抱怨时，它们很明显。其他问题只有在长期内才会显现出来。Martin Fowler 谈到了保持内部质量的重要性——进行重构、创建自动化测试、解耦您的架构。早期阶段的公司往往会跳过这一点，以换取短期生产力提升。这可能是正确的决定，但一旦他们考虑添加更多团队，就必须解决内部质量问题，否则就会失去长期价值创造。
平衡积压工作
创建平衡的积压工作从信任开始，因为它本质上是产品和工程之间的谈判。我们建议每个产品负责人努力与他们的技术同行建立密切的合作关系，反之亦然。在努力寻找平衡的过程中，会有很多困难的讨论，也应该有。初创公司资源非常有限，通常不得不做出艰难的权衡，在改善开发人员体验和构建新功能之间做出选择。
富有成效的谈判取决于透明度、共享详细信息的的能力以及从对方角度看待事物的愿望。如果产品经理了解技术架构和策略，他们可以提出更容易构建的想法。如果技术人员了解产品策略背后的推理和研究，他们可以提出产品人员没有想到的替代解决方案，例如利用 ML/AI 来解决问题。
在协商积压工作时，初创公司通常发现难以理解潜在投资之间的相对影响——而且由于使用和收入指标易于获得且易于理解，因此通常会优先考虑会影响这些指标的工作，这会使投资组合失去平衡。为了抵消这一点，我们建议找到允许您衡量技术投资影响的指标。每种情况都不同，但有一些经过研究支持的、事实上的标准已被证明可以提高长期生产力，您可以将其用作起点。
- 专注于 DevOps 和 DX 结果驱动的指标。阅读最大化开发人员效率是一个很好的起点。
- 在 Thoughtworks Scaleup Studio，我们有一些合理的默认值，这些默认值来自对成功扩展公司正在使用哪些实践和技术的调查。这包括持续交付、面向领域的微服务、谨慎使用技术债务、构建实验过程和基础设施。
- 设定不可协商的质量标准并坚持下去。例如，每种语言都有一套良好的实践，我们可以轻松地自动检查我们的工作是否符合这些实践。
随着你的成长，产品与工程协作方法
阶段 1
实验
初创公司本身就是一个团队。
初步工作协议和资产来描述使命宣言。
投资组合高度倾向于产品投资。通常是为了提高知识而构建，而不是构建一个可用的产品（例如一次性原型）。
尝试不同的经济模型。
阶段 2
获得牵引力
公司开始分成子团队，仍然认为自己是一个“大团队”。
工作协议变得更加具体
客户价值资产得到完善，并用于入职和定向。经济模型变得更加清晰，但仍然灵活。
聘用您的第一位非创始人产品和工程负责人。
投资组合仍然高度以产品为导向，专注于创建持久的产品——支持规模的关键基础投资。
阶段 3
(超)增长
规模太大，无法作为“一个大团队”运作，分解成流对齐的团队。
为中层管理创建跨职能领导团队。创建第一个平台工程团队。
不再寻找新市场。投资组合加倍投资于您的产品创造的价值。
客户价值、业务策略和经济模型资产现在非常具体，变化非常缓慢，并且设计用于分发。
每个产品和子产品根据需要创建自己的价值陈述和资产。
阶段 4
优化
领导者必须积极努力防止沿着职能线形成孤岛。
团队结构开始发生变化，以优化最大程度的自主权和代理权。
支持跨职能群体技能发展和一致性的结构出现。
创建多个团队，使流对齐团队的工作更高效（平台工程、产品运营、设计运营等）。
核心产品的投资组合变得更加专注于技术投资，包括对开发人员体验的投资。
