项目案例分析：如何帮助团队消除障碍？

今天要跟大家分享的是：如何帮助团队消除“障碍”？

近年来仆人式领导力被越来越多的人接受和熟知，消除团队障碍就是仆人式领导的重要职责之一。

那在项目推进过程中，项目经理如何识别障碍，如何及时有效的做出响应，最终保证项目顺利推进就显得尤为重要。所以项目经理需要掌握消除障碍的艺术，需要不断提升自己的沟通能力、创造能力，以及必要的外交能力等等。

在处理团队障碍时，我们首先要确定哪些是团队真正的关键障碍。这一点是很重要的，比如说有些障碍可能是困扰个人的，那么完全可以让团队成员自己去“Google叔叔或Baidu前辈”找答案。如果是团队的障碍，那才真正是需要项目经理来解决的问题。

不要做“随叫随到”的项目经理

1

记得我当时刚进入一家新公司，我的下属是一名年轻小姑娘，作为项目经理的她对工作非常认真负责，项目中的任何事情都是亲力亲为努力地去解决，包括项目计划、人员安排、问题处理等等。

尽管如此，她所带的项目却总是出现各种各样的突发情况，导致实际项目进度与制定的项目进度计划脱节，然后就处在不断更新项目进度计划和不断推迟的状态中。我看到这个可爱的小姑娘对工作那个认真劲，每天都有着忙不完的项目问题要处理、要沟通。

因为她要解决项目中的每一个“障碍”，成了团队的“保姆”和“消防员”。但是很明显效果并不好，于是她跑来找我求助。我当时问了她三个问题：

1. 这真的是团队障碍，还是开发团队可以解决的事情？

2. 作为项目经理是否真的需要消除这一障碍？

3. 这里真正的问题是什么？

我想让她意识到，只有超出团队的自组织能力时，才会成为障碍，才是需要项目经理去排除的。后来的几个星期，项目慢慢变得可控了。

通过这个例子，我是希望大家知道，能够识别真正的关键障碍是最关键的，这样才能更有效的帮助团队，而不是成为团队中的“消防员”，不停地灭火，而无暇去寻找火因。这样做并不能帮助团队整体发展。

我是如何同时顺利解决两个障碍的？

2

我们识别到了团队障碍，那么怎么高效处理障碍呢？

这里想再跟大家分享另一个我曾经经历过的案例↓↓

案例背景

当时我们正在做一个跨境电商平台的CRM系统（客户关系系统）的全面升级改造的项目。在这个项目中，需求方涉及3个业务部门的诉求，系统涉及多个相互关联模块的升级，研发团队涉及产品、设计、开发、测试30多人5个Scrum团队。我担任整个项目负责人和2个核心研发团队的Scrum Master，在迭代过程中，我每天都会组织团队成员开站会。

一次站会中，其中一名资深测试工程师说：“测试服务器本周已经第三次宕机了，我还得再花一天的时间编写新的测试用例。”

另外一个刚入职两个月的90后开发同学说：“我已经花了三天的时间尝试为先前完成代码编写单元测试，目前并没有遇到什么障碍。”

要知道这个任务最初估计的时间只需要一天，而且当时这个团队并没有引入测试驱动开发TDD的方式。说到这里我想你可能已经意识到了这两位团队成员遇到了障碍。但是团队的资深测试人员似乎将我当作接力棒的另一端。

也就是说，只要将问题交给我，然后他就可以去做别的事情了。他在站会时说的几句话，其实就已经表明他认为这个问题是他无法控制的，所以他不认为这个问题是需要他解决的。然而另一个年轻90后开发甚至没有意识到自己遇到了障碍，他只是在努力完成自己的工作。

很多时候就是这样，是否遇到障碍其实是需要我们仔细识别的，真正的问题或者障碍是他不熟悉单元测试，他需要专门进行学习的；又或者是他碰到了一些无法进行单元测试的非常老旧的代码。

总之，无论哪种情况，作为Scrum Master我都需要仔细观察，深入分析，了解问题所在，这样我才能够知道他们需要什么样的帮助。

站会之后，我就去找这位开发同学沟通，正如我所料，尽管旧代码存在问题，但是他编写单元测试的经验确实非常有限。于是我跟他一起把这个问题写到了障碍卡片上以表明充分重视并要为此付出具体行动。也是要让他感到有人在帮他，自己并不是孤立的。

同时，单元测试的这个问题我也不只是针对他一个人。我还为测试服务器问题也写了一张障碍卡片。并邀请这位资深测试和我一起来跟进运维的同事，找出测试服务器宕机的问题所在。运维同事重新启动服务器，很明显问题是系统性的原因，但运维没有时间去进行处理。

就在当天晚些时候，研发老大来我们团队的会议室，看到了障碍清单。就跟我沟通说，他发现测试服务器已经成为一个反复出现的问题，他承诺从自己的角度开始解决这个事，尽量彻底的解决它。同时老大还承诺，如果对这位开发成员有帮助的话，他可以协调人给他做单元测试培训或提供一些书籍。

于是，这两个障碍就这么顺利解决了。

解决障碍的3个实践要点

3

带着这两个障碍卡，我们一起来分析一下当时项目的问题以及解决思路：

第一点，我们要确定哪些是团队真正的关键障碍。

正如上述案例中的那位90后开发同学，有一些团队成员并不能及时的意识到自己的工作存在问题，即使意识到了也未必能够准确的分析出根源在于哪里，所以这个时候就需要团队领导认真观察，发现问题，排除障碍，使项目顺利进行。

第二点，在识别了障碍后，我们需要通过一些方法和手段更高效的解决它。

回想这个案例中我做了哪些事情？可能你会说：你啥也没做呀，都是你老大来处理的！！！但其实写障碍卡片就是这其中最关键的动作，这就是我的方法和手段。

我可以帮助这两名团队成员几分钟内解决他们的问题，但我需要配备一些简单的障碍消除工具。一旦有障碍被提出，我们就需要让它看得见。

最好的方法就是：在团队任务墙上的某个区域维护一个高度可见的列表，凡是遇到的障碍都写下来，随着项目的发展，你就会发现一些共性的问题，是需要你集中去解决的。

在项目的整个生命周期中，项目团队会遇到很多无法想象的问题和困扰，这些可能来自外部环境、组织本身、团队和个人能力等诸多方面，只有正确有效解决并消除团队障碍，项目才可以成功交付。

其实，高效识别和解决团队障碍的方法与手段有很多，可能需要大家在未来的工作和学习中不断领悟，并实践这些方法。

“阻滞剂”、“经典障碍”和“地雷”

4

最后，我归纳一下，在项目生命周期中，团队遇到的障碍的三种类型：阻滞剂、经典障碍、地雷。

第一种称之为“阻滞剂”，阻滞剂是典型的阻止团队在正常轨道上运转问题，大多数人往往认为，当他们想象障碍。也许硬盘在测试人员的笔记本电脑上破裂，让他在接下来的两天里完全无法工作。或者，也许一个开发人员的女儿突然生病了，他需要提前离开去接女儿放学。阻滞剂不管是什么原因，阻滞剂往往很容易被发现，因为团队里有人一出现就磨蹭停下来。

第二种称之为“经典障碍”，经典障碍有点棘手。这些都是使您的团队放慢脚步的事情，但不一定会让他们停下来。团队通常会意识到这些问题，但是已经习惯于解决这些问题，以至于他们只是简单地将它们注销为“事情将一直如此”。在某些情况下，团队可能已经习惯于这些问题，以至于他们甚至不再注意到它们，或者甚至忘记了它们的存在。常见障碍的例子包括：无权更改其生产环境以提供新功能的团队；或者，由于处理过时的源代码控制系统而不得不经常停止纠正合并冲突的团队，他们没有更换的自由。

这些，可能需要熟练的技术人员才能发现这些障碍，因为团队通常已经习惯于处理这些障碍。团队甚至不必在项目例会中就提起这些障碍。作为项目经理的工作是首先将这些问题引起团队注意，并提醒他们这些问题已经存在，并且正在减慢它们的速度。

但是，一旦团队接受了这些问题，障碍通常不会像阻滞剂那样容易被消除。

这是因为障碍往往是一个全球性的、系统性的问题，影响到整个团队，而不是单个个体。此外，障碍往往是由于组织结构或文化中的因素而产生的更微妙的工件。这些会使它们很难取出。

第三种称之为“地雷”，项目经理可能发现自己消除的最后一种障碍是等待他们的团队被绊倒的地雷和陷阱。这些可能是所有障碍中最棘手的类型，与团队曾经认识到但逐渐消失的经典障碍不同，这些障碍是以前可能从未注意到过地雷。通常，有经验的项目经理会认识到这些问题，原因仅在于他曾经看过它们落在类似的项目上，或者是因为需要第六感、“开天眼”才能注意到它们。

在敏捷项目中，Scrum Master可能会发现一些地雷，但对于整个团队来说并不完全清楚，其中包括：

职能经理积极地来参加诸如回顾或每日站会之类的仪式，从而限制了团队可以轻松共享的透明性或诚实性。或者，每日站会从早上移到了下午，这使团队成员没有机会让团队在每天开始时进行计划和同步，而只能在一次下午的站会上同步。甚至是产品负责人PO，他们过多地参与了多个团队，因此限制了他们有效地为任何一个团队扫清道路的能力。请注意，在所有这些情况下，尽管存在此类地雷并不能确保灾难每次都会发生，但至少要警告即将发生的问题。

使事情变得更加艰难的是，当项目经理首次尝试向团队指出地雷时，团队最初具有抵抗力的情况并不少见。这意味着项目经理在指导其团队以识别并消除这种特殊类型的障碍时必须具有敏感的触觉。

那么，作为项目经理，如何处理团队中“阻滞剂”、“经典障碍”、“地雷”这三种类型障碍？

第一种“阻滞剂”，作为项目经理，你的工作就是倾听这些问题，尽你所能清除这些障碍，这样团队才能继续前进。

“阻滞剂”的解决方案

很多这样的问题你可以直接说出来。是否有一台备用的笔记本电脑供测试人员同时使用，或者他可以与另一个测试人员配对，以并行测试他的用例？然而，有些其他人可能对此无能为力。开发人员突然因家庭疾病不得不离开办公室，开发团队能否围绕这段开发过程，开展其他工作？或者，他能在女儿康复期间远程工作吗？你可能需要努力消除这些问题，或者你可能需要有创造性地帮助团队，在这些问题阻碍项目进展时，解决它们。

第二种“经典障碍”，虽然，最初作为项目经理的首要任务可能是消除这些障碍，以便您的团队可以发挥最大的潜力，但理想的长期目标应该是使您的团队开始为自己消除这些障碍。

“经典障碍”的解决方案

前面已经提到过，障碍往往是组织文化中更深层次问题的征兆。如果是这种情况，那么与项目经理扑上去为团队解决这些问题相比，致力于识别、并找到适合解决这些障碍的团队上，将具有更长持久影响。这是因为解决组织深层次问题的最有效方法是组织自己认识并解决这些问题。即使项目经理也是该组织的成员，简单地为团队中的其他人解决问题，往往比让团队意识到问题，在行为上逐步解决更有意义，这更像一位教练的职责。

第三种“地雷”，与经典障碍一样，通常最好是引导团队自己消除这些障碍。但是，你如何执教取决于你的团队对这些问题的开放程度。

“地雷”的解决方案

如果你发现团队对学习和解决地雷问题特别敏感，那么简单地指导他们通过一系列主要问题来识别地雷可能会非常有效。

另一方面，如果你的团队由于强烈的文化偏见或组织严格的规章而抵制这种地雷的可见性，那么你最好站在一边，而团队正走向边缘，以帮助说明不解决他们道路上的地雷可能带来的失败。尽管这种方法并不理想，但通常只需要一两次，团队就可以更容易地接受关于地雷可能埋在何处的反馈

今日要点

▼有效解决团队障碍的思路：

1、我们要确定哪些是团队真正的关键障碍。而不是成为团队中的“消防员”，不停地灭火，而无暇去寻找火因。

2、在识别了障碍后，我们需要通过一些方法和手段更高效的解决它。除了“高度可见 和 障碍卡片”以外；我们还可以利用回顾会议。

▼三种常见障碍类型：

“阻滞剂”：往往很容易被发现，因为团队里有人一出现就磨蹭停下来。

“经典障碍”：在某些情况下，团队可能已经习惯于这些问题，以至于他们甚至不再注意到它们，或者甚至忘记了它们的存在。

“地雷”：这些可能是所有障碍中最棘手的类型，这些障碍是以前可能从未注意过的。

PMP备考学习资料需要的同学可以留言