开发团队管理层如何实现权力下放？
发表于2017-08-27
作者：Samuel Rantaeskola
游戏开发的团队组织形式正在迅速转向自主组织、向下赋权、分散决策。当工作室朝这个趋势发展时，必然发生有（无）意识的交换；牺牲控制权以换取效率和创新能力。通过决策权下放，接近这个问题的人得以想出比集中式结构更明智的解决方法。
但这个新结构潜伏着一个大问题：这种团队如何合作？游戏开发充满相关性，因为产品是复杂的，且为了创造连贯的体验，一切者必须凝结为一体。团队无法各自为政；为了做出好游戏，他们必须互相依赖。这个问题的解决办法往往是集中管理方法论：有些东西总是必须管理的，对吧？
集中管理结构通常注重可预测性和控制。当短期计划布置到团队中去时，集中式思路会反映在产品待办事项中。为了增加交付的可预测性，第一步就是解决跨团队相关性问题，特别是，为了实现预测性和控制，制定要求团队必须遵守的高度瀑布式的时间表。
采用这种方法时，我们没有授权给团队，所有关键决策都是团队之上的管理层做出的，我们下放给团队的唯一权力就是让他们自己组织短期任务。为了真正实现权力下放，管理层必须信任团队能够自己协商与其他团队的相关性。他们必须是自己的工作的主人，能够自己决定开发的逻辑顺序。
Salesforce.com上发表了一篇关于如何用敏捷环境中的相关性管理解解决这个问题的文章。在文章中，作者表示没有人可以看到事情的全貌，因此相关性管理必须有团队的参与。作者还提出，相关性始终在变化，所以管理相关性的方法必须是连续的，而且要保证是连续的。
游戏开发的团队组织形式正在迅速转向自主组织、向下赋权、分散决策。当工作室朝这个趋势发展时，必然发生有（无）意识的交换；牺牲控制权以换取效率和创新能力。通过决策权下放，接近这个问题的人得以想出比集中式结构更明智的解决方法。
但这个新结构潜伏着一个大问题：这种团队如何合作？游戏开发充满相关性，因为产品是复杂的，且为了创造连贯的体验，一切者必须凝结为一体。团队无法各自为政；为了做出好游戏，他们必须互相依赖。这个问题的解决办法往往是集中管理方法论：有些东西总是必须管理的，对吧？
集中管理结构通常注重可预测性和控制。当短期计划布置到团队中去时，集中式思路会反映在产品待办事项中。为了增加交付的可预测性，第一步就是解决跨团队相关性问题，特别是，为了实现预测性和控制，制定要求团队必须遵守的高度瀑布式的时间表。
采用这种方法时，我们没有授权给团队，所有关键决策都是团队之上的管理层做出的，我们下放给团队的唯一权力就是让他们自己组织短期任务。为了真正实现权力下放，管理层必须信任团队能够自己协商与其他团队的相关性。他们必须是自己的工作的主人，能够自己决定开发的逻辑顺序。
Salesforce.com上发表了一篇关于如何用敏捷环境中的相关性管理解解决这个问题的文章。在文章中，作者表示没有人可以看到事情的全貌，因此相关性管理必须有团队的参与。作者还提出，相关性始终在变化，所以管理相关性的方法必须是连续的，而且要保证是连续的。
那么我们如何管理跨团队的相关性？
首先，我们必须放弃旧的范式，例如提前映射所有相关性以增加我们对产品的预测性。这么做可能增加产品（未必是好产品）的预测性，付出的代价是，大量初期投入和创新能力下降。初期投入是团队经历和鉴定一连串相关性所需的时间和创新能力下降，因为当人们在产品待办事项上花掉大量精力后，往往很不愿意做出改变。
如果我们可以放弃集中决策这个最后的堡垒，那么我们就可以开始看看团队如何拥有产品待办事项和持续合作以提前清除相关性问题，防患于未然。
为了把权力真正地下放给团队，以便他们自己解决相关性问题，你要做到以下几点：
1、跨职能团队必须根据特征来组织，且具有完成他们的产品待办事项上的目标所必需的所有（几乎）能力。否则，相关性太大，将迫使团队将花大量时间思考他们的相关性在哪里。（提示，不要采用学科导向型的组织方式）
2、产品待办事项必须是目标导向型的（而不是充满任务）。任务导向型的待办事项往往包含太多信息，以至于无法有效地确定相关性。
3、团队对产品待办事项中属于自己的部分，必须有明确的主导权。
如果工作室不能满足以上三个指标，那么就不能说管理层把权力下放给团队了，在看相关性解决方案前，最好看看如何达到这个状态。
达到这些条件后，工作室可以进行以下简单的步骤：
1、团队浏览他们的待办事项，对任何一个因外部相关性而无法展开工作的标都要把这个相关性记下来。
2、每一次冲刺待办事项的目标前都要进行至少一次例会，团队之间要讨论各自的最优先级任务。
3、团队在待办事项中新增目标时，要考虑到确定的和一致的相关性。
这个过程可能太简单了，但是一个好的起点。
在我看来，敏捷意味着在正确的程度上做出正确的决策，当然必须有人控制产品的整体方向，甚至对于分散决策结构也是一样。把权力下放给团队，使成员自己处理他们的相关性问题，可以避免管理层太过专注于思考如何优化成员的时间。相反地，管理层可以把时间放在掌握大方向和支持团队上。
首先，我们必须放弃旧的范式，例如提前映射所有相关性以增加我们对产品的预测性。这么做可能增加产品（未必是好产品）的预测性，付出的代价是，大量初期投入和创新能力下降。初期投入是团队经历和鉴定一连串相关性所需的时间和创新能力下降，因为当人们在产品待办事项上花掉大量精力后，往往很不愿意做出改变。
如果我们可以放弃集中决策这个最后的堡垒，那么我们就可以开始看看团队如何拥有产品待办事项和持续合作以提前清除相关性问题，防患于未然。
为了把权力真正地下放给团队，以便他们自己解决相关性问题，你要做到以下几点：
1、跨职能团队必须根据特征来组织，且具有完成他们的产品待办事项上的目标所必需的所有（几乎）能力。否则，相关性太大，将迫使团队将花大量时间思考他们的相关性在哪里。（提示，不要采用学科导向型的组织方式）
2、产品待办事项必须是目标导向型的（而不是充满任务）。任务导向型的待办事项往往包含太多信息，以至于无法有效地确定相关性。
3、团队对产品待办事项中属于自己的部分，必须有明确的主导权。
如果工作室不能满足以上三个指标，那么就不能说管理层把权力下放给团队了，在看相关性解决方案前，最好看看如何达到这个状态。
达到这些条件后，工作室可以进行以下简单的步骤：
1、团队浏览他们的待办事项，对任何一个因外部相关性而无法展开工作的标都要把这个相关性记下来。
2、每一次冲刺待办事项的目标前都要进行至少一次例会，团队之间要讨论各自的最优先级任务。
3、团队在待办事项中新增目标时，要考虑到确定的和一致的相关性。
这个过程可能太简单了，但是一个好的起点。
在我看来，敏捷意味着在正确的程度上做出正确的决策，当然必须有人控制产品的整体方向，甚至对于分散决策结构也是一样。把权力下放给团队，使成员自己处理他们的相关性问题，可以避免管理层太过专注于思考如何优化成员的时间。相反地，管理层可以把时间放在掌握大方向和支持团队上。