战胜变化中的阻力

  • Mark Levison
  • 秦时月

2008 年 8 月 31 日

话题:敏捷技术管理文化 & 方法

在 Agile 2008 大会上,《Test Driven: TDD and Acceptance TDD for Java Developers》的作者 Dave Nicolette 和Lasse Koskela举办了一场研讨会,“战胜变化中的阻力”。不管是实施敏捷还是重新布置办公室,只要是变化就都会遇到阻力。问题在于遇到阻力时怎样应对。

当我们提出改变的建议而遭遇阻力,我们往往都会先做出情绪化的反应(生气或是沮丧):这群傻 B,犟驴……Dave 认为,这种想法丝毫无济于积极的推行变化。

阻力的根源可以分为以下三种:

  • 认知:我不明白需要改变什么东西,会带来什么好处,怎么改变。
  • 情绪:我能做到么?我会喜欢它么?我是不是感觉受到了威胁?
  • 行为:我拒绝被人吩咐做事。

其形式又可以分成如下类型

  • 主动 / 被动
  • 公开 / 暗地
  • 个人 / 集体

  • 攻击型 / 羞涩型

我们一起玩了 Dale Emery 发明的游戏:“将阻力作为资源”——回答了这个问题“为什么‘一个聪明能干真诚友好的人’会抵触别人提出的改变建议?”Dale 设计这款游戏的目的是,“找出怎么应对阻力的想法,并且学会它,记住它,表达出来”。我们玩这游戏的时候,每张桌子都会一起讨论出一些实际案例。对于每一种阻力,我们都会找出“缘由”,对每一种缘由找出多种“应对方案”。每桌选出一名代表来做汇报。

后来到了角色扮演时间,Lasse 加入了这个汇报团队,扮演了一个拒绝加入站立会议的成员角色。作为一个团队,我们桌讨论 过很多导致某人不想参加站立会议的情绪上的原因,但是当这个代表扮演起 Scrum Master 的角色,他忘光了这些情绪上的问题,努力从认知上说服 Lasse——毫无作用。最后整个团队都介入了讨论,请求 Lasse 作为团队中的一员, 试着在下几个 sprints 中参加站立会议。

哪些人将抵触变化?这要依赖于这些想法的根源,还有他们相互冲突的优先级。开发人员希望交付质量,客户想得到功能,还想让管理层控制住预算。所以每个人都会从自己的立场考虑问题。

在应对阻力时,我们应当记住Kotter 和 Schlesinger 的 6 步模型

  1. 促进。给大家支持,在转型期帮助他们缓解恐惧和紧张的情绪。
  2. 教育和沟通。预先做好沟通和教育工作,大家就可以明白为什么要作出变化。
  3. 参与和投入。如果大家都参与到推动变化的过程中来,他们就更容易接受变化,而不是抵触。
  4. 谈判和协议。给抵触者否决权,让他们把感觉有威胁的因素切掉。或是让他们离开。
  5. 连纵。从抵触者中选出领导者,一起参与推动变化。如果这些领导者只是名义上的角色,这种办法反而会引火烧身。
  6. 明处暗处的高压统治。这适用于时间紧迫的情况,是最后的选择。经理可以明着或者偷着给雇员压力,让他们搞清楚,继续抵触的结果就是被炒鱿鱼、换岗,或是得不到提升。

Dave 和 Lasse 都认为最好只关注前三步,把剩下的扔一边去,因为它们有可能会让事情变得更糟。

Johanna Rothman补充说,如果你发现了阻力,你应当想一下这是否也体现出来了你自己身上的阻力。

所以,当我们遭遇阻力时,应当把脚步稍稍收回,考虑找人一起玩一下 Dale 的游戏,这可以帮助我们分析出问题的本质和应对方案,对当前情况作出改善。

查看英文原文Overcoming Resistance to Change

敏捷技术管理文化 & 方法