用协同游戏解决“给力超问题”

文化&方法

摘要： “给力超问题”（Awesome Superproblem）代表了一些庞大、复杂而持久的问题，它们只能通过协同方式解决。协同工作的关键在于实现一些严肃的游戏，其中参与者自愿遵守游戏规则，意在创建更好且更持久的结果。

作者： Ben Linders

正文：

Luke Hohmann指出，“给力超问题”（Awesome Superproblem）代表了一类庞大、复杂而持久的问题，它们只能通过协同方式解决。协同工作的关键在于实现一些严肃的游戏，其中参与者自愿遵守游戏规则，意在创建更好且更持久的结果。

Luke Hohmann是Conteneo的CEO，他将在2017年精益&敏捷苏格兰大会上以“给力超问题”为题目做主题演讲。大会将于10月4日至6日期间在爱丁堡举行：

（精益&敏捷苏格兰大会）将广泛地覆盖部分常见主题，从整体上审视伟大软件产品的生成之道。各分会将会拓展与会者的思维，为他们引入新的理念，并为投身于精益和敏捷的新手提供帮助，使他们可以开始一个新的旅程。

InfoQ将以问答、总结和文章的形式覆盖大会全程。

InfoQ采访了Hohmann，所涉及问题包括：解决“给力超问题”如此困难的原因何在、创立协同工作去解决问题的条件是什么、如何能将回顾扩展到整个企业层面等。

InfoQ：什么是“给力超问题”（Awesome Superproblem）？

Luke Hohmann：当前，我将“给力超问题”定义为具有如下特点的问题。首先，问题应是非常“给力”的。这类问题会激发人们的敬意、畏惧和认真对待之心。其次，问题也应是“超级”的，是不能被个人单枪匹马解决的，必须协同他人一起解决。

InfoQ：是什么使得解决此类问题如此困难？

Hohmann：导致了解决“给力超问题”存在挑战的因素很多。下面给出从我个人经验中所发现的。

最突出一点在你的提问中就能发现：你使用了“解决”一词。这类似于提问，是否你可以“解决”吃饭问题、睡觉问题或是洗澡问题。当然你可以解决当下的问题，但是问题还会周而复始的出现。这类问题是一种持久性问题。

持久性决定了一个问题是否会成为“给力超问题”。例如城市预算、工作的未来发展、管理共享的和稀缺的天然资源、处理气候变化问题等。虽然我们并不能一劳永逸地“解决”其中任何一个问题，但我们还是需要去处理这些问题，正如我们需要解决吃饭、睡觉和洗澡问题一样。

InfoQ：在哪些条件下，协同工作可以解决问题？

Hohmann：我认为，如果使用游戏和游戏用于作为协同的基础，那么协同工作就能最好地解决这类问题。下面我将使用Innovation Game®的“修建产品树”（Prune the Product Tree）游戏为例。当然读者也可以使用自己最喜欢的游戏或回顾技术去验证概念。

• 我们应具有一个目标，或者说要去实现的事情。例如，在“修建产品树”游戏中，目标就是根据产品组成上的需求修剪产品或服务。

• 参与者应清楚地了解自身所掌握的资源、各自的角色以及如何使用这些资源（即参与和交互的规则，其中包括了获取和处置资源的规则）。继续回到我们的例子上，“修剪产品树”游戏的参与者被赋予了数量有限的苹果，通常每个苹果表示一个产品特性。但是，我们也可以考虑对“修剪产品树”游戏稍作变更。如果参与者能给出特别引人注意的想法，那么就可以“挣到”更多的苹果。

• 参与者明确地创建了开展工作所需的空间或“游戏场所”。有时是参与者亲自现场创建的，但是我们也看到，更多的企业已迁移到使用Conteneo Weave平台在线创建，这可解决分布式团队相关的挑战，并可以扩展。

• 在达成目标的过程中，具有清晰的反馈。所有“修剪产品树”游戏的参与者都可以看到结果。

• 协同结果将对参与者产生切实的影响。当“修剪产品树”游戏的参与者相信他们的反馈将会调整有问题的产品或服务时，游戏的效果最好。

• 参与者是自愿的。他们并未强制合作。

注意游戏是协同的基础。将此基础置于实践中，意味着要解决协作多维度设计空间的不同维度。下面给出其中一些常见的维度：

• 亲自还是在线：有时协同将是亲历亲为，例如单一Scrum团队参与发布计划。而有时协同是在线的，这时会有数十乃至数百个团队参与到这种参与式预算中。

• 团队的结构：一个团队可以是稳定的，也可以是动态的；可以是同构的，也可以是异构的；可以基于现有结构，也可以是以特设方式构建，这取决于设计者的目标。团队可以由内部利益相关者组成，也可以由客户或者合作者等其它外部利益相关者组成。

• 同步与异步操作：参与者可以实时地协同操作游戏，或是在很长的时间面上操作。

InfoQ：在实践中，自愿参与的情况如何？

Hohmann：我发现自愿参与如果是团队自身文化的组成部分，那么最容易实现。团队的行为规范是团队文化的组成部分，通常表现为工作协议。例如，尽管在“Scrum指南”中定义了“Sprint规划”中的Scrum实践，但是在实践中，我所指导的团队立刻在适当的Sprint过程中发现了真正的价值所在，并自愿选取了继续参与实践。只要 团队能在使工作组发现自身目标的协同框架中发现价值，那么这种自愿参与将会持续下去。

InfoQ早期采访过Hohmann，并做了名为“用在线游戏召开大型回顾会”的报道。在这篇报道中，Hohmann解释了为什么在线游戏适用于大规模回顾：

Hohmann： 在线游戏的成本比较低，也能比较快地得到结果，团队可以在方便的时间做回顾，并且能够提供更好的数据分析。有些人比较内向，还有些人愿意说出自己的心声，而不是在公司里随声附和，那这种在线的形式能够更好地获得和描述这些人的想法。

InfoQ：您是如何将回顾扩展到企业层级的？

Hohmann： Conteneo公司在可扩展回顾上处于领先的地位，所执行的回顾从十数个到超过60个敏捷团队。其过程十分直接：

• 确认企业的领导者正寻求对跨多个团队的性能加以改进。确保领导者明确项目将会给出一些相当棘手并难以解决的问题。

• 找出一到多个可以帮助企业识别改进机会的回顾框架。例如，Sailboat由于其隐喻性和开放性，无疑是一个好的选择，它使团队能够识别出哪些会构成障碍，哪些会产生加速。

• 找出一个可促成回顾的促进者团队。只要Scrum Master可以管理好自身的固有偏见，他们无疑是适合的人选。

• 为每个团队规划一个回顾。我们的经验是，如果通过亲历亲为的回顾技术实现此，那么需要过长的时间，并且过于令人乏味。我强烈建议使用专门设计用于大规模协同的平台。

• 跨团队的数据应从以下维度分析：

  • 类别：该障碍是否和人、过程、技术或其它因素有关？问题和分类是否表现出明显的模式？

  • 范围：该障碍是否可被团队修复（在团队的控制和/或职责范围内），或是需要由企业去解决？为说明其中的差异，我们假定在一个企业回顾中找出了一系列重要的架构更改，诸如Angular由1.6升级到了4。如果只有一到两个团队，那么协同更改十分容易实现。但是如果企业具有三十个、七十个乃至一百个以上的团队，那么就需要创建跨所有团的项目（即一个“企业范围”上的项目）。

• 在特定的更改列表上，添加代价及对影响的估计。

• 让团队选择它们想要解决的障碍。

• 开始工作！

查看英文原文： Tackling Awesome Superproblems With Collaborative Games