指导组织进行多技能开发
关于即将出版的新书的系列博客中的第六篇:创建敏捷组织——系统方法，塞萨里奥·拉莫斯和伊利亚·帕夫利琴科著。
一个成功的团队一起为业务目标服务。这样做所需要的团队技能总是在变化。例如，目前的一项顶级技术在几年内可能就不那么先进了。新技术不断涌现，您的产品团队需要深入了解这些技术，以保持竞争力。为了适应这个不断变化的世界，经常深入了解新领域的人是标准而不是例外。
多功能学习影响敏捷性
当敏捷团队保留最大化利用单一技能专长的目标时，它就有多个隐式积压，而不是一个。具有相互依赖任务的团队中的多个隐式积压(在产品开发中主要是这种情况)导致了团队工作的序列化，这增加了完成工作的端到端时间。你能听到的最典型的短语是，“我要做这个任务，因为我能最有效地完成它。”对个人技能的关注还迫使企业改变产品待办事项列表的顺序，以确保每个人的单一专业都有任务。因此，团队不会从客户的角度来处理最关键的特性，也不会对价值交付进行次优化。
优化个人性能的另一种策略是为相同的产品引入更多的团队backlog，然后团队倾向于关注整个产品的一部分，并减少跨职能，如图1所示。这不可避免地导致了人为的依赖和更长的交货时间。
图1团队之间的特性依赖关系
处理他们自己的团队待办事项列表的团队对整个产品有一个狭隘的看法，并且没有意识到当他们从客户的角度处理低价值的工作时。
从单一产品待办事项列表中工作，不可避免地会在单一技能的团队成员中产生知识缺口。知识差距越大，开发人员就越需要一起工作，并帮助团队中的其他人获得额外的技能。随着时间的推移，团队成员发展第二甚至第三技能，成为多技能专家。
我们经常听到这样的说法:“我们理解这背后的想法。但是，一个深度专家将比一个交叉训练的专家更有效和更有知识。”我们同意这个论点。但是敏捷组织并不训练人们如何创建有效的资源。相反，他们组成的团队能够接受变化并将瓶颈最小化。
自主团队将资源对准瓶颈的能力非常重要，因为它将开发过程中的队列最小化。由于这些瓶颈可以在项目中迅速且不可预测地转移，团队成员在专业之外工作的灵活性是处理这些瓶颈的关键工具(Donald G. Reinertsen，管理设计工厂)
当系统负载过重时，即使容量的微小变化也会导致周期时间的显著差异。
你能为公司做些什么?
你应该选择一个专注于整个团队的跨职能部门经理
典型的组织设计鼓励人们在狭窄的、单一技能的职业道路上成长，优化个人的表现，而不一定是他们所在团队的表现。例如，在一个设置章就作为部门经理对待员工，负责评估和员工发展。有关于Java或UX等技术的章节，他们的目标是帮助人们在特定技能方面发展。
因此，与其让单一技能的部门经理专注于个人表现，你应该选择一个专注于整个团队的跨职能部门经理．
这样的设计应该导致:
- 与其让单一技能的部门经理专注于个人表现，不如让跨职能的部门经理专注于整个团队。
- 跨职能部门经理——没有任何权力给团队分配工作——应该专注于改进组织设计和团队效率。他们还帮助个人发展，为整体团队绩效服务。
- 促进员工发展的专家领导(或者普通团队成员)。这些人没有给团队分配工作的人力资源责任或权力。
创建一个支持多技能专家的人工操作系统
理想情况下，你的团队中应该有精通多种技能的人，但不幸的是，这些人很难找到。然而，你能做的是创造条件，鼓励人们随着时间的推移发展成为多技能专家。
因此，创建一个人工操作系统:
- 结合个人和团队成就来评价员工。
- 重视员工成为多技能专家。
- 重视团队中深度专家和多面手之间的平衡。
一个组织可以通过创建一个多技能增长系统来实现这一点，该系统允许人们创建自己的工作路径。图2显示了一个通用的值系统。
图2多技能价值体系
团队中需要的确切技能会随着时间的推移而变化，所以特定的技能最好不要固定。此外，深度专家和通才之间的确切平衡取决于团队环境和开发产品所需的技能。因此，人工操作系统让团队弄清楚:
- 最好的平衡是什么?
- 哪些团队成员开发了哪些技能?
团队有责任确保他们成长为有效的敏捷团队，管理层也在那里支持他们这样做。
总结
从单一产品待办事项列表中工作，不可避免地会在单一技能的团队成员中产生知识缺口。随着时间的推移，团队成员发展第二甚至第三技能，成为多技能专家。在组织层面上，引入关注整个团队发展的跨职能经理。此外，您还需要创建一个支持多技能专家的人工操作系统。
在接下来的两篇博文中，我们将概述:
- 指导团队进行多技能开发
- 大规模地向产品负责人过渡