合作伙伴关系可以加速敏捷、DevOps以及数据科学的技术创新，但需要确保有一个强大的基础。
“向开发团队传达信息的最有效和最有效的方法是面对面的交流。”——《敏捷宣言》
这一原则于2001年《敏捷宣言》写作时便有所必要，因为大多数员工在隔间办公，许多项目是由一个团队的任务和移交所管理的。瀑布式的项目管理方法具有高失败率，这导致越来越多的组织转向Scrum、Kanban和其他敏捷方法。
采用敏捷开发的组织经常选择将其开发团队联合办公。在某些组织中，这种移动使得将敏捷开发团队的员工招募成为全职员工成为了首选。随后，人们对于散布团队、使用外部服务提供商和依赖自由职业者的抗议日益增加。我们很容易将外包归咎于项目交付不佳，或将营销机构归咎于开发无法支持的代码。
如今，联合办公不再是那么重要了。大约58％的公司支持混合工作，而大多数敏捷组织使用工具来管理待办事项列表、增加异步通信并简化文档。
尽管如此，它仍然普遍倾向于招收员工而不是与第三方签订合同或寻求外部合作伙伴。我认为组织需要反思改变这种模式所涉及的机遇和风险。
合作伙伴关系可以加速转型
企业面临着显著的压力，必须改善客户经验、现代化应用程序并尝试新兴技术。Gartner报告称，一半以上的数字化计划落后于CEO和管理层的期望，而许多技术技能需求很高。这意味着CIO和其他技术领导人需要更多的选择来扩大开发规模，而不仅仅是招聘和培训员工。
这可能意味着敏捷开发团队、DevOps组织和数据科学团队包括员工、外部服务提供商的承包商、初创合作伙伴、代理机构提供的设计工作以及小型开发商提供的工程技术。
共同创建重构组织
为了实现组织目标，组织必须超越关于合作伙伴关系的“我们与他们”以及“我们和他们”的思维方式。相反，需要一个“我们与他们”共同创建模型。
共同创建是一种协作和节目管理方法，它将雇主、雇佣状况和组织层次结构从团队自组织的方式中删除。该方法将重点放在人们根据约定的方法在定义的目标上工作。
共同创建是关于人们如何协作的，并不涉及知识产权的法律定义，也不意味着正式的联合开发协议。签署合作伙伴时，组织的采购、法律和业务利益相关者必须指定这些合同考虑因素。
并没有共同创建的固定规则书，因此组织必须提供上下文和定义。以下是一些推荐的最佳实践。
1. 了解合作伙伴提供的附加值
在合作并定义共同创建模型之前，了解合作伙伴的优势以及他们可以为您的组织的重点工作做出贡献的地方非常重要。例如，一个合作伙伴可能提供云基础架构专业知识，第二个将开发数据集成，第三个将设计并测试用户体验。事先了解和设定期望确保整个团队在角色和责任上达成一致。
如果被邀请参加潜在合作伙伴的审查，则可以参与此对话；如果没有被邀请，则领导者应就选择合作伙伴的目标和要求进行沟通。
“成功的共同创建的关键在于确保您的合作伙伴不仅仅是在工作，而是作为真正的战略资产和顾问，支持您公司的底线。” Fortis嵌入式付款/金融和合作伙伴关系负责人马克·比绍普说。 “这始于在前期阶段提出深入追问，以确保他们通过多年的双方坐在谈判桌两边的经验真正了解您正在工作的行业的独特细微之处。”
在询问技能和能力的问题之外，还应评估合作伙伴的心态、风险容忍度、质量方法和其他需要与您组织的业务实践和文化进行协调的领域。 “在选择共同创建合作伙伴时，评估合作伙伴团队文化的质量至关重要，”非常好的风险投资公司的首席执行官大卫·德雷默说。 “通常，合作伙伴文化对您自己的团队产生的影响可能会带来比交付范围更大的长期奖励。”
2. 记录产品愿景和目标
大多数敏捷团队使用产品愿景来将产品经理的目标和路线图与交付团队的架构和开发实践对齐。产品愿景定义客户和最终用户人物、价值主张、成功标准、战略目标和其他所有团队参与者必须理解的标准。
VentureFuel的创始人弗雷德·舒恩伯格说：“共同创建是关于首先对期望结果进行对齐，然后利用个人超能力以新的、改进的方式实现该结果。” “关键是你必须了解你们双方的合作的价值，以及为什么这是一种可触摸的改进。”
这一点很重要，因为表现最佳的合作伙伴关系为所有参与方提供了价值和学习机会。当组织内的人可以回答“伙伴有什么好处”时，这种对齐有助于更多地投入到实现企业目标中去。
3. 定义组织的期望
将来自多个组织的Scrum大师、DevOps工程师和数据科学家集中在一个房间中，您可能需要一块罗塞塔石来解包每个人对于敏捷最佳实践、如何实施部署管道或在数据库中使用哪些命名约定的看法。
组织应定义其标准的开发方法、协作实践和合规要求，以设定清晰的前期期望。另一方面，重要的是开放耳朵进入共同创建程序，因为合作伙伴很可能有一些优于组织的方法论，这是潜在的流程改进。
Semaphore CI/CD的联合创始人马尔科·安纳斯塔索夫说：“每当涉及到共同创建时，拥有一个游戏规则是根本的。” “这个游戏规则至关重要，因为它为每个人创造了一个统一的界面，为协作提供了便利。为了使playbook实用，必须不断改进和更新，随着过程的变化。 ”
4. 转向开放和透明度，但确保严格保护关键数据
为了消除我们和他们的思维模式，考虑在至少符合合规要求的情况下转向更加开放、反馈驱动和透明的实践。分享有关性能问题和故障的信息，使每个人都参加回顾，公开审查客户投诉，并披露最具挑战性的数据质量问题。
安纳斯塔索夫将开放思维推到了更高的层面。 “共同创建新产品的最有力方法是公开构建它，”他说。 通过拥抱透明度并涉及您的受众，您可以建立信任，获得有价值的反馈，并加快成功之路。”
开放实践和透明度的唯一附注是数据安全和系统访问权。大多数组织遵循分离职责原则，要求所有带有个人身份信息的数据集进行数据遮蔽，并对用户数据和其他机密信息来源定义严格的访问策略。这些合规因素在以共同创建模型签署和与合作伙伴共同工作时非常重要。
5. 从实验中学习，但互相对自己的行为负责
敏捷团队的目标是通过验收标准定义“完成”，因此存在关于何时符合用户故事要求的共享理解。团队也尽力在部署新功能时符合冲刺承诺并满足客户期望。但事情不总是如计划的那样进行，许多团队使用冲刺回顾和采纳无错过程的后期检讨来确保人们关注改进并避免推卸责任。
这些都是团队应对满足交付日期和客户期望的压力的关键实践。组织领导者应将这些方法扩展到共同创建团队。
但是，组织也应通过记录所需行为、质量规格、服务级别最小值和其他期望来要求合作伙伴承担不可协商的责任。
最终，无法找到与第三方合作伙伴并进行合作的方式的组织将难以跟上转型进程的步伐。采用共同创建模型可以提供与完全内部或完全外包方法相比的显著优势，但需要整个团队承诺在目标和方法论上进行协作。
