< 概述
团结于共同事业
灵活机动的跨职能团队是成为有效数字化组织的关键，并且完美体现了如何在工作中进行协作。将来自不同职能部门的人员聚集在一起，集中力量实现一个目标，并在整个企业中复制这一过程，从而使公司能够同时处理多项产品和服务开发计划。可以说，这是以当今商业环境所要求的速度和规模采取行动、进行创新的唯一途径。
一个团队在其实力和生产力都处于巅峰状态的情况下成功开展协作，这将是一件美妙的事情。但很多跨职能团队——据《哈佛商业评论》报道，约四分之三的团队——至少在某种程度上是功能失调的。有时这是结构上的问题造成的结果，但根据我们的经验，这与团队的工作方式也有很大关系。这就是为什么企业需要强调一种确保团队在实践层面和名义上都存在，并使团队协作成为现实的文化和流程。
直观表现
协作团队蓝图
跨职能人员组成：团队应当是多样化和跨职能的，使设计师、开发人员和业务代表以及可能需要在产品或服务推出过程中进行某种投入的其他部门（例如法务或财务）在一起协调开展工作，这一点很重要。这确保了团队有效地自成一体，并被赋予权力端到端地提供成功体验，而无需经常中断工作寻求外部批准。在整个产品生命周期中协同工作也使协作更加无缝。
结对编程：虽然团队最终需要作为一个整体进行协作，但以较小的单位启动协作可以加快进程。结对编程就是很好的一例。所谓结对编程，就是一种让两名开发人员协同工作的敏捷开发实践办法，通常是在同一个工作站办公，但有时也通过远程形式。这不仅仅是聚在一起完成一项任务，还是一个很好的机会，可借此与队友建立联系，分享技术和文化方面的知识，教学相长，同时也能够了解是什么激励了其他团队成员，又是什么使他们感到气馁。
团队解决方案评审：一起评审已完工的产品（或解决方案）为整个团队提供了一个分享知识、学习新技术和技能的机会。这样可以通过提高团队的“巴士指数”来降低风险——一个团队里若有某些员工离开则会导致整个项目脱轨，而“巴士指数”指的就是这类成员的最少人数。进行评审也是一个很好的机会，可借此确定在哪些方面开展协作被证明是最有效的，而哪些方面没有实现协作或出了问题。
回顾：进行回顾为团队创造了对某段时期内开展的活动或发生的重要事件进行反思或思考的空间，也可以庆祝所取得的成就，并共同制定未来改进计划。这份对持续学习的坚持以及对所取得工作进展的认可强调了这样一个事实，即协作能够真正地“开花结果”，并培养了强烈的团队紧密联系意识。
快速反馈和迭代交付：反馈是一种机制，通过这种机制，团队和个人可以验证其协作在哪些方面产生了必要的结果，在哪些方面则没有。除了识别问题，团队还需要合作，定期将见解反馈到过程和行为中，以加速和改进价值交付。更短的交付迭代周期可以缩短反馈回路，并帮助团队在不同的职能组之间建立信任，让业务和其他利益相关方有机会对所交付的内容作出反应。这些互动反过来又为与企业其他部门持续协作奠定了基础。
测试驱动开发 (TDD)：TDD 就正在开发的内容提供快速反馈，通过循环的“失败——通过——重构”流程将想法转化到实现。采用这一流程，开发人员在开始实施解决方案之前，通过为一个功能编写高级别自动化测试来启用该功能。然后，他们构建软件，通过较低级别的测试来摸索方向，直到通过测试。完成开发工作后，测试会保留下来并在每次构建时运行，从而树立人们的信心，相信代码会继续按预期工作。
为何重要
协作式敏捷实践带来的共同好处包括：
- 更好的产品质量
- 更高的客户满意度
- 提高团队士气
- 增强团队凝聚力
- 降低项目彻底失败的风险
- 富有成效的指导关系
阻碍因素
如果团队协作没有围绕具体目标来进行，则可能无法产生预期的结果。正如 Thoughtworks 首席咨询师，同时也是《企业敏捷性——在不断变化的世界中保持敏捷》的作者 Sunil Mundra 所指出的那样，“随心所欲地实施变革，说干就干”，会造成敏捷的假象，却不会产生任何影响。
他说：“从这种方式入手并没有什么问题，因为总有一些流程、仪式需要执行，但是如果你只是这样做，那么因组织系统性问题而继续存在的惯性将压过你在团队层面得到的任何初步进展，最终导致你回到原来的状态。如果不理解背后的动因，你将无从获益。”
对于团队协作而言，另一个主要威胁是企业层级过多，这可能会扼杀人们进行开放对话的想法，而开放对话能支持开展团队协作。Thoughtworks 首席科学家 Martin Fowler 说：“许多组织都存在权力斗争盛行的现象，权力斗争会影响人们进行真诚沟通的能力。这根本不适用于敏捷，因为敏捷需要更高程度的透明。”
如何实现
- 强调共同价值观的重要性
- 为团队树立明确的共同目标，让他们为之努力
- 突出强调团队协作与高绩效之间的联系
- 给予团队失败和学习的空间和自主权
- 促进形成团队纽带，以建立信任、提升干劲和动力
- 融入敏捷实践以加强沟通和联系
关键技术驱动力
团队协作可能被看作是一个“软”概念，任一跨职能团队里都会有非技术人员。然而，与此同时，数字化商业的现实情况和技术变革的步伐意味着基于协作的开发必须至少在某种程度上植根于“硬”技术技能，能够支持快速成型等过程以及动态解决方案以响应用户反馈。
Fowler 解释说：“这一点是软件行业特有的，但非软件行业也有相似之处。”“组织并没有对测试和开发、重构和自行决定权或所在行业的具体技术技能给予必要的关注。但这些因素确实能够促使企业从敏捷流畅度模型的第一层次向第二层次转变。敏捷流畅度模型提出，企业需要具备技术专业知识才能达到期望的生产力和有效执行水平。”
作者 JoJo Swords
在收件箱中获取《视野》
为数字领导者提供及时的商业和行业洞察。
《视野》订阅为您提供我们专家的最佳播客、文章、视频和活动，以扩展我们广受欢迎的《视野》出版物。