红帽白皮书新鲜出炉!点击获取,让你的云战略更胜一筹! 了解详情
写点什么

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

  • 2008-09-04
  • 本文字数:6585 字

    阅读完需:约 22 分钟

上周我参加了一门有关教练的研讨会,其中有荷兰女子曲棍球队主教练 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 中文站用户讨论组参与我们的线上讨论。

2008-09-04 20:542144
用户头像

发布了 479 篇内容, 共 151.7 次阅读, 收获喜欢 47 次。

关注

评论

发布
暂无评论
发现更多内容

VS code常用插件推荐(总结整理篇)

孙叫兽

vscode 大前端 插件 Vue 3 引航计划

【21-8】PowerShell 输入输出

耳东@Erdong

PowerShell 6月日更

密码学系列之:feistel cipher

程序那些事

加密解密 密码学 程序那些事

区块链技术让传统旅游业焕发新机

CECBC

面试官问“你有什么问题要问我”,如何完美回答?

架构精进之路

6月日更

【Flutter 专题】103 初识 Flutter Mixin

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 6月日更

react源码解析13.hooks源码

全栈潇晨

React

Python——字典的使用

在即

6月日更

百度的云图丹青

脑极体

话题讨论|从2021苹果全球开发者大会中,你得到了什么启发?

石云升

wwdc 话题讨论 6月日更

论现代科技发展趋势:停滞、减速 OR 蓄力?

老猿Python

发展 科技 软件技术

【Vue2.x 源码学习】第十五篇 - 生成 ast 语法树 - 构造树形结构

Brave

源码 vue2 6月日更

Kubernetes手记(12)- StatefulSet 控制器

雪雷

k8s 6月日更

建信金科大咖访谈:人脸识别技术的发展与应用

金科优源汇

🌏【架构师指南】总结分库分表的实现方案

洛神灬殇

分库分表 架构师 6月日更 实现方案

「SQL数据分析系列」4. 过滤操作

数据与智能

数据库 SQL语言

页面怎么布局,当然是Grid ԅ(¯﹃¯ԅ)

空城机

JavaScript 大前端 6月日更 页面布局

架构实战营模块六总结

竹林七贤

云上 ARM 实例应用优化?现在带你读懂它!

亚马逊云科技 (Amazon Web Services)

OpenVINO+微软黑客松比赛项目简介

IT蜗壳-Tango

IT蜗壳 6月日更

故事|订单系统中的补偿事务

悟空聊架构

故事 事务 6月日更 订单系统 补偿事务

软件工程,其实没有任何工程而言

实力程序员

MySQL基础之十三:约束

打工人!

MySQL 6月日更

JDK 工具大合集

看山

Java 6月日更

Java8 的时间库(1):介绍 Java8 中的时间类及常用 API

看山

Java 6月日更

连续七年,我们持续领跑

浪潮云

Java包装类(Integer 详解 )

若尘

java编程 6月日更

企业如何成功应用机器学习?看这四点就够了!

亚马逊云科技 (Amazon Web Services)

前端开发华为鸿蒙系统应用 OpenHarmony JS

孙叫兽

华为 鸿蒙 OpenHarmony 鸿蒙开发 引航计划

一分钟开发一个表单

蛋先生DX

vue.js 表单 动态表单 6月日更

Linux之ls命令

入门小站

Linux

世界顶尖运动队教练的成功秘诀_研发效能_Urs Peter_InfoQ精选文章