世界顶尖运动队教练的成功秘诀

上周我参加了一门有关教练的研讨会，其中有荷兰女子曲棍球队主教练 Marc Lammers 的主题演讲。在世界杯的历史上，这个团队是最成功的，曾获六次冠军。在听演讲的过程中，我意识到为什么这个团队可以取得如此卓绝的成就。她们的成功，在很大程度上，要归功于教练 Marc 的执教方式。Marc Lammers 发现了可以令团队释放全部能量的秘诀，大家不仅像一个整体一样齐心协力，每个人作为团队的一份子也各尽所能；而这一切都以意想不到的方式发生。我的的确确得到很多启示。本文总结了他发现的原则，并描述了这些原则如何应用到软件开发之中。

我本人作为一个Scrum Master，发现他揭示的原则可以在我自己的Scrum 团队中使用。原因在于，这些原则从本质上适用于任何团队，无论这些团队是装配汽车、打曲棍球或是开发软件。本文中，我希望分享一些Marc Lammers 在研讨会中提供的执教秘诀和经验，并说明如何在每日的Scrum 和项目实践中使用这些知识。也许，即使有了它们你也无法获得世界杯，可如果不注意使用，团队的所作所为也许会令你和客户大跌眼镜。

原则1：

利用有效沟通的威力

Marc Lammers 提到：

在执教生涯的早期，我花了很多时间和精力，来让大家明白我的所作所为。所以，我会在冗长的演讲中，向团队阐述我那聪明透顶的执教理念。为了确保大家都能收到传递的信息，我会问：‘大家都明白了吗？’人人点头，我也心满意足。然而，大家比赛时的表现证明：她们根本没有理解。她们好像根本没听我说。所以，我开始施以更激烈的方式——大声训斥。很不幸，这根本不起作用。我跟我自己的教练说，跟这帮无能的聋子们一起，不会取得任何成就。他却说这全是我的错。他把沟通研究的结果给我看，研究发现：一个人所能记住的东西：

• 对于听到的能记住 10%
• 对于看到的能记住 35%
• 对于同时听到和看到的能记住 55%
• 对于自己重新表述的能记住 70%
• 对于自己重新表述并且动手做的能记住 90%

这使我恍然大悟。我开始使用开放式的问题，让她们可以重新复述我的策略，并创造彼此之间可以对话和互动的空间。这样一来，她们不只可以更深入地理解我的想法，我也开始了解她们的考虑，并从中受益良多。从那时起，我在赛前的叮咛嘱咐终于可以在比赛中得到充分的贯彻。

至于 Scrum，我可以在各种交换领域或信息的场合中使用这个原则。设计讨论、向开发人员或业务人员沟通需求、向业务人员或新的团队成员解释开发流程，或者你想到的其他场合，都是适用的。这些时候，使用开放式问题、对话风格的沟通、重新描述等沟通方式，可以极其显著地提升彼此的共识；因为这些方式强迫所有的参与者去发现他们真正理解或思考的东西。由此而构建起来的互信和互敬的关系，在我看来，是最重要的生产力提升因素。

其实我早已在每天的 Scrum 实践中发现了这些法则。不过，能够知道高效沟通带来的诸多好处，这已弥足珍贵。

原则 2：

只有做事方式不同，才能产生不同结果。

上述的沟通故事中还包含了另一个重要原则。Marc Lammers 知道自己一开始的沟通方式失效之后，他先采用了更严厉的方式，却没有反思自己的所作所为。我想这是人的本性使然。如果得不到期望的结果，我们就会以为是因为力度不够。因此，我们会工作更长时间，以更严厉的方式谈话，投入更多精力，在周末也努力工作，等等等等。大多数情况下，正像 Marc 的经验所证实的，我们都无法取得进展。当他换了一种完全不同的方式来看待问题之后，才取得了原本想要得到的结果。

这个原则有许多适用场合。想想 Scrum 是如何推进估算的。以前用功能点估算，与特定团队的交付能力无关；而 Scrum 会根据有经验的团队的开发速度和故事的发展程度进行点数估算，实践证明，这样做的准确性出人意表。所以，Scrum 不会去修正功能点数使其日臻完美，而是采取了完全不同的方式，在简单性和准确性上收效显著。

该原则常被误用。有一个典型的例子，当截止日期来临之际，人们经常被要求去加班工作，即使以当前这些人力已经明显无法在最后期限之前完成。顺便说一句，这样做也许是必要的，可实际上，这样做已经证实只是对症状的治疗，长期来看，毫无意义。不仅会对团队的精神和团队成员的健康造成严重伤害，同时会影响软件的质量。bug 率会提升，而且还会耗费更多人力在修复引入的 bug 上。通过加班解决问题，只能让事情变得更糟糕。

为了解决这个问题，Scrum 提供了一种更好的方式——使用紧急处理流程。其本质上是利用前述原则的一种具体应用方式。如果最后期限无法达成，而且事态很明显，Scrum 的紧急处理流程会建议考虑下列行动：首先，举行一次回顾会议，为了激发生产力，看看可以移除哪个主要障碍。其次，如果通过实施步骤一，没有带来明显的生产力提升，考虑哪些具体的任务可以外包给专家完成。这个专家不会成为团队一员，他所解决的问题应该是相对孤立的，而且团队不具备解决这些问题的专业技能。第三，如果没有这样的任务，试试重新划定范围吧。最后，如果客户不同意重新划定范围，当前的 sprint 就必须中止了。

总的来说，有勇气去从根本上考虑改变当前的做事方式，是在组织长期运转中唯一的结构化解决方案。真要这样做，即使前路上充满艰难险阻，达到预期目标的机会也会大大提高，因为团队不再会被送到死亡征途之上。

原则 3：

创新是得到更好结果的绝佳方式，却不是目的；
而且，要小心副作用。

Marc Lammers 说：

我总是在找创新的方法。在奥运会的比赛中，我很想指导她们如何发小角球，却发现在场外很难看到比赛的关键环节。我们以前是通过赛后分析录像片段的方式，可这对我来说太迟了。我希望可以实时进行。我在视频课程上得到启发，用一个电视摄像机接上长长的线，再连到笔记本上，可尝试了几次都不成功。在笔记本的屏幕上能够看到几个小窗口，从中可以看到摄像机实时捕捉的镜头。后来我试着联系了一些工程师，几个月之后就可以测试第一个原型系统了。从那时起，我就可以向队员们给出更细致的指导了。

想创新，我有三个要点想告诉你们：

1. 创新必须是为目的服务的。有很多次，我都想为了创新而创新，这不会带来任何改善。创新必须要能解决一个实际问题。
2. 每次创新都伴随着成长的烦恼。别指望它初战就能告捷。要不断进行调试和优化，直到它能带给你想要的竞争优势。
3. 创新会导致抵触。总有人对新事物有畏惧情绪。这个事实有两个含义：首先，当你遇到抵触时，你也许已经找到了真正的创新方法，所以为自己感到骄傲吧。其次，找到应对抵触的方法。不要指望别人喜欢你的新奇想法，要给他们接受和习惯你的想法的时间。

我坚信：如果我们在开发软件时认真考虑这些简单的智慧，很多项目都可以成功。它教导我：

• 关注目标：以我的经验来看在工具的使用上，有一种很明显的状况：很多用法都没有考虑是出于什么意图。我见过很多项目都是以工具为中心，而不是以结果为导向。人们总在考虑如何有效地使用工具，而不是如何交付更好的软件。这就是为什么“开始时不适用任何复杂的工具”在实践中如此成功的原因。使用白板和即时贴，经常要比使用一系列复杂的工具要来得更为有效，因为这会强制团队进行互动，而且把精力都放在面前的问题之上。
• 关注阵痛：项目环境的改变很容易带来阵痛。新成员的加入、新技术的使用、新流程的启动等等都是如此，而一开始人们总是会过于乐观。知道“阵痛”是变革的必然后果，这可以让我们对未来有更为实际的期待，而不是过于乐观。
• 关注抵触：举例来说，向组织中引入诸如 Scrum 这样的敏捷开发实践，通常都会引起抵触情绪。Marc 的故事让我认识到此类反应的存在，并帮我找到应对的方式，而不是匆忙下结论再与之斗争。介绍新鲜事物时，给予有抵触的人以耐心和关注，这比无情的“说服”和强力推动要来得更为有效。

原则 4：

不断挑战工作方式

Marc Lammers 说：

我们的训练包含很多 30 米冲刺。团队总是要反复做这个练习，因为多年来 30 米冲刺练习已经是众人皆知。后来，我想分析下在比赛中的奔跑模式。要想做到这一点，在一些培训课程中，我们为每个球员配备了 GPS。再分析其中的数据，平均来看，一名球员 15 米冲刺的次数要超过 30 米冲刺的次数。有鉴于此，我们可以让培训计划更符合实际需要。又一个小的改进诞生了。

这个故事教给我两件事：

1. 不断问自己为什么要做正在做的事。要完成某项活动，是因为以前“总是”这么做么？还是因为这项活动真的可以为整体增加价值？它具体能带来什么价值呢？它跟必须要做的工作有什么关系呢？
2. 如果不能对上面的问题给出一个满意的答案，开始收集数据、衡量效果吧。只有衡量了才能知道是怎么回事。衡量可以让我们评估对策和调整的效果，看看是否有所收效。衡量可以很简单，比如“停止某项活动，看看会发生什么”。

以我的经验，每天都有很多时间被浪费掉了，因为我们把眼前的工作方式视为理所当然，而且不去质疑它的好坏。反复重复某项任务，可以让它看起来很合理，即使没有添加任何价值。从提升效率的角度考虑，通过衡量变化来质疑现有的工作方式，这是很有效的。

原则 5：

关注人的长处而不是弱点

Marc Lammers 说：

我们曾有个球员，她总是很难得分，因为她的反手球技很差。我想尽办法训练她的反手，但是毫无进展。尽管我们投入很多心血，但她就是无法进步。由于大家都关注她的反手，所以其他球员总传到她的反手，这也就难怪她总是处理不好了。当我濒临绝望之时，我问她想怎么打球？她答道：‘实际上，我喜欢用正手’。知道了她的喜好之后，我们开始训练她的正手。可我几乎不敢相信我的眼睛：几乎所有的来球，她都可以处理得完美无缺，又快又好。经过一些有针对性的训练之后，她的正手得分率达到了以前的三倍。

我一开始的方式，显示出整齐划一的训练方式是多么愚蠢。以 10 分的范围计，我想然让她的反手技术从 4 分提升到 6 分，可是她的正手天生就能达到 8 分，由于没有训练，也蜕变成 6 分了。经过正手训练后，她的正手从 8 分上升到了 9 分，这让她卓尔不群。以前试图关注她的弱点而不是长处，这是多么大的浪费啊。

如果一个团队成员不能按照他 / 她应有的方式表现（比如不守纪律、没有经验、思维混乱、毫不友好等等），通常关注点都放在了这个人的负面表现上。这个故事告诉我：通过有意识地发现一个人的技能而不是短处，不管是对于这个个人还是团队，都能得到更好的结果。如何找到方式容忍这个人的缺点，并发挥他的长处，这才是关键。

原则 6：

为团队指出明确的努力方向

Marc Lammers 说：

我过去认为：在比赛之前要激励团队，可以用类似这样的话：‘我们必须要赢，否则就要被淘汰了。’而效果却适得其反，这不能让她们表现得更好。一开始我总是不知道原因何在，现在我知道了。问题在于，一个队员无法仅靠一人之力影响比赛的结果。即使她已经拼尽全力，还是有很多她无法控制的因素在决定着比赛胜负。这种无力感让队员们感到紧张和焦虑，并因此无法将能力发挥到极致。 我认识到：胜负只是我们比赛方式的结果。好消息是：每个人都可以通过自己的方式来影响比赛。所以我们不在比赛前讨论胜负，而是小心重复我们的策略，还有每位球员必须要注意的自己的事情。这就更加具体，而且也易于控制。通过这种方式，队员们比以前更放松了，而且可以发挥最高水平。有比赛结果为证。

作为 ScrumMaster，从上面的事实中我发现：提前一年告诉团队“我们必须交付某些特定功能”，这毫无意义。大家对此无能为力，并因此而士气低落。即使是在一个 sprint 中，提醒团队交付他们事先答应要完成的功能，这也没有任何价值，只能给团队增加压力。如果大家缺少压力的话，这样做可能会有效果，但是绝大多数情况下下，压力不是问题的根源。

Marc 的收获告诉我们，要把注意力放在能使团队或成员生产效率有所提升的小改进上。是不是有什么障碍让团队无法取得进展？对于团队不熟悉的技术，我们是不是可以雇佣一个相关领域的专家？要是有人陷入困境却不愿意让人帮忙，是不是可以采取结对编程呢？时间有没有被消耗在毫无价值的文档之上？类似的具体问题是可以控制的，解决它们会自然而然提升生产率，同时增加了项目按时交付的机会。

原则 7：

眼光向内，只见局限；眼光向外，可能无限。

Marc Lammers 说：

在曲棍球里面，有 38 种发小角球的方法。进行比赛时，我会发出指令告诉队伍应该如何发小角球。为此，我制订了一套复杂的身体语言，所有的队员都要认真学习。可是对手把这些记录了下来，而且做了分析，最后发现了我们的秘密。后来，他们就知道了我的战术意图，我们的优势也将会因此而消失。一个偶然的机会，我受邀加入了参加环法的荷兰自行车队。我意外发现，他们一直用无线电与车手保持联系。我想：“天哪，要是我们能这样做，那优势不就又回来了？”回来之后，我偷偷地研究了规则，发现没有提到任何关于无线电的内容。因此，我就假定这一定是允许的。后来我跟一家制作无线电的公司取得联系，要他们制作耳塞大小的设备，因为自行车手用的太大了。经过一些调整后，第一个原型可以运作了。

最有意思的是：我们一直把这个创新当成头等机密，而且继续用身体语言来迷惑对手。在一年半的时间里，都没有人发现我们的秘密，而且将对手玩弄于股掌之间。

在敏捷和 Scrum 中，有部分实践属于另外一种工作方式，即丰田的精益原则，我们将其运用到软件行业。显然，有人已经有过类似的主意了……

从 Scrum 的角度看上面的故事，我发现如果 Scrum 从其他相关方法论中借鉴一些实践，它就可以变得更加强大、适用范围更加广泛。可以举几个例子，统一过程的以架构为中心（architectural-centric）、以风险和用例驱动的方式，XP 的可持续开发速度思想、测试驱动开发，以及适合我们自己情况的结对编程等等，这些我都用过，而且从中获得很多宝贵经验。借鉴其他方法论，可以创建出适合个人需要的流程。

教给我，要用不同的眼光去看待其他与软件开发无关的领域，并取其菁华。世界上有很多有价值的东西，如何发现并将这些东西集成到我们的日常工作中，这是一门艺术。

原则 8：

目标越重要，积极性越高

Marc Lammers 说：

从金钱的角度来看，谁想成为一名曲棍球运动员，这个人一定是疯了。她们只能收到一点可怜的奖金，这点钱连生存都难以维系。尽管收入匮乏，申请者依然甚众。获胜并成为胜利团队的一份子，这会被全世界媒体报道，这样的感觉要比金钱或其他什么来得更强烈。

从理论角度分析，开发人员写一个类，不管出于什么意图，都无关紧要。实际上，这是有区别的。写这个类，是为了一个技术类库，还是为了内部的工具项目，甚或是为了新的 NASA 站点而写、以供实时跟踪去火星的探险活动，其产生的结果会完全不同。

Marc 的体会提醒我：激励团队的最好方式，就是让他们觉得自己目前的工作非常重要，而且可以改变世界。有些项目本身就可以产生这样的感觉。交付之后，媒体会来报道这些项目，作为广告大战的一部分，或是对社会产生影响。这些案例不需要费太多力气去激发团队的士气。

不过，大多数项目都不会有很多人了解，即使它们可能非常难以实现。只要提升项目对外的能见度和重要性，不需要花太多激励措施，大家的积极性就可以激发出来了。举例来说：

• 庆祝一次成功发布。邀请“重要”人士到场，请他们发言表示感谢，并说明项目对他们的重要性。
• 让用户知道新版本的发布或是项目进展，也可以发布到公司的新闻里面，通过这些措施，让公司知道你在做什么。
• 邀请部门老大或是 CEO 来访问项目，并将他介绍给团队。

认识到激励的重要性，这可能是提升项目生产力的关键因素。

结语

上述诸多原则听起来都像是常识。不过，要知道，是这些常识的应用让荷兰女子曲棍球队成为了世界上最好的球队。虽然有了这些理论和原则，如何在实践中做到合理运用、收放自如，这才是艺术。当我听到 Marc Lammers 演讲的时候，我意识到了他是如何做到的：快乐的激情、不断的自我反思、以及发现和实验全新工作方式的渴望。

这让我得到了最后一条原则：

将竞争精神、乐趣和有益的自我反思结合在一起，上述种种原则会自然实现。

就是这么简单。

尾注

Marc Lammers 已经完成了一本关于他的执教收获的著作，请移步至 www.marclammers.nl 查看。

关于作者

Urs Peter 是 Xebia 的资深咨询师，专长于敏捷软件开发领域。他已经参与了多个大型产品的开发，其中用到了敏捷方法论，比如 Scrum 和 Agile-RUP。目前，他在一个高效的分布式 Scrum 团队工作，为荷兰特路公司交付下一代信息系统。关于他目前的项目，可以查看《案例分析：荷兰铁路公司的分布式Scrum 项目》一文。

志愿参与InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。