你要招聘怎样的 Scrum Master？

你是否注意过近期的各种招聘 Scrum Master 的广告呢？某些招聘广告将 PMP 认证作为应聘的必要条件，某些招聘条件则表示如果你能够在指定时间内完成某个项目，或者满足了某客户的需求，则能够提供额外的奖金。某些招聘条件要求应聘者完成整个团队的招聘计划，或者管理客户的需求。某些招聘条件要求应聘者创建跨国成员的团队，或者更糟的是在不同的国家创建多个团队。某些条件还要求应聘者承担教练的重任。所有这些招聘条件都打着同一个名号 ——“Scrum Master”。

我了解每个敏捷团队所面临的情况都不一样，也能够理解每个 Scrum Master 的工作都会有些许不同。但会有这么巨大的差别吗？很显然，以上这些职位的背景情况都是完全不同的。因为虽然这些团队所招聘的人才都称之为 Scrum Master，但他们所招聘的其实不是同一个职位。并不会仅仅因为招聘的职位名称相同，就意味着它们的工作性质也相同。

如何完成招聘目标？

技术人员的招聘一直以来都有些混乱。HR 部门虽然尽心尽职，但往往对技术性工作并不了解。他们知道对某些其他职位可以使用一些通用的职位描述，因此他们就会建议招聘经理：“你就不能写一份通用的职位描述吗？”而那些没有经过管理方面培训的招聘经理就会想：“嗯，这位 HR 专员认为这是个好点子，她一定没错。”于是他们就会为那些无法替代的人才去建立通用的职位描述。错误之一。

HR 部门还会看重各种证书的作用。其实你我心里都清楚，即使是最高级的认证也只不过表示你在某个阶段学习了某些东西，并且在你通过测试时对那些知识有所了解，仅此而已。认证不代表你能够把知识熟练运用到新的环境中来，但 HR 部门仍然乐于把认证作为工作申请的筛选条件之一。错误之二。

Scrum 是当前敏捷方法中最为人熟知、并且宣传最多的一种，但不代表它一定适合于你的环境。那么招聘经理和 HR 部门又如何进行筛选呢？她们只要 Scrum Master，无论这个职位是否适合公司。错误之三。

比起进行一个全方位的职位分析，使用一个通用的职位描述、看重认证，或者把 Scrum Master 本身就当作职位描述，这些方式确实显得更易于实施。但实际上，比起使用一个你未必需要的通用的职位描述或者认证筛选，如果你进行一次职位分析，并且弄明白了你所招聘的职位到底需要怎样的技能之后，整个过程会进行得更迅速和简单。

现在就让我们来做一次简单的职位分析，看看我们能从这些招聘广告中了解些什么信息，并且最后决定：如果 Scrum Master 不是最适合这个职位的名称，那它实际是什么？

首先从职位分析开始

如果你不过分纠结于职位名称，而是从职位分析开始着手，你将更容易找到适合你的人才，也更容易填补所需的职位空缺。以下是我的网站所使用的职位分析模板：

首先回答以下 4 个问题：

• 与这个职位在工作上产生互动的有哪些人？
• 这个人在工作中要扮演哪些角色？
• 公司愿意为这个角色提供怎样水平的薪资？
• 这个人要承担哪些管理内容？

接下来的两个问题触及到更深的层面，它们主要讨论了工作内容及工作目标：

• 这个职位的工作内容及工作目标是什么？
• 哪些周期性的工作成果是必须的？

如果你问问自己这些问题，你的发现可能会令你吃一惊。

以下是某位招聘经理 Ruth 的一段话：

当我们开始列举这个职位的各种互动、扮演的角色、工作内容及工作目标时，我们的需求就非常清晰了。我们需要一个项目领导人。并且我们仍然需要能够定义这个项目的自由发挥度的一个人，这也是整个项目的实际动力。我们需要他吸引公司投资者的兴趣。我们要求项目管理展现出项目组合级别的工作情况，因为并非所有的项目都已经迁移到敏捷方式。因此，我们所需要的是一位项目经理，而不仅仅是一位 Scrum Master。我们需要 Scrum Master 为整个团队带来活力，但我们也需要一位项目经理。那实际上的问题就是：我们需要两个人还是一个人？

有一些 Scrum Master 实际上是敏捷项目经理

Ruth 为她的发现感到震惊。她所需要的人不仅是一个团队的催化剂与服务性领导（facilitative servant leader），并且还要担任一些项目管理的功能职责（但不是指命令与控制的工作方式），并将整个项目展示给组织的其它部门。她认为这样的人应该是一个敏捷项目经理。

一旦当她意识到这一点之后，她就能够重新修改这个职位的职位描述，并且招聘到比她最初所预期的更高级的多的人才。她决定寻找一位比她所预期的更高级的人才，即一位项目经理。

你可能会决定采用一种不同的方案：你的项目或许需要某些人去吸引公司投资人的兴趣并展示你的项目内容，然后有几个人去做项目组合方面的工作，再有几个人去参与某个特定的团队。在这种情况下，你需要两位人选：一位项目组合经理与一位 Scrum Master。按照我的经验来看，如果你的组织里有几位职能经理，当你的组织转型成敏捷方式之后，这些职能经理将乐于放弃传统的命令与控制型工作方式，并承担起新方式的管理任务。

某些 Scrum Master 其实是敏捷经理

有时你并不需要项目经理，你真正需要的是在 Scrum Master 这个职位上的经理。

Harry 正在考虑组织内的一些问题，以下是他对这些问题的描述：

我们已经是第二次尝试采用 Scrum 了。在我们的组织中，各部门的职能经理会选择一些成员加入某个 Scrum 团队，Scrum Master 必须承担一个非常有力的服务性领导者（servant leader），以保证团队成员对他们所属的 Scrum 团队尽心尽责。我仔细考虑了一下这个人所扮演的角色、他的工作伙伴以及他参与管理的部分，就发现实际上这个人会整天与管理者们打交道。按真正意义上来说，他的职责其实是保护团队不受管理者们的干扰。他需要创建这个团队的凝聚力，让团队成员们首先认同这个 Scrum 团队，接下来才是他们原本所属的职能团队。我认为这一职位其实更像是一名经理，并非因为他需要告诉团队成员做什么，而是出于他在整个组织内与同事们打交道的方式。这中间的微妙差别正是关键所在。这个职位的工作内容与目标也包括为整个团队完成目标铺平道路，他需要为团队扫除各种障碍，需要代表团队去进行一些活动。这些工作内容都是经理的范畴。如果我为这个职位找到了一位合适的经理，或许就能够顺利开展 Scrum 了。

Harry 很吃惊，他一直没想到他其实需要一位经理，因为之前他一直受到某种说法的影响，即敏捷不需要经理。

某些 Scrum Master 实际上是敏捷教练

Valerie 在分析她的 Scrum Master 职位时，回顾了一下团队的现状。其实团队的情况并不差，但每次他们在举行 Scrum 回顾会议（retrospective）时从来都列举不出任何需要改进的地方，一次都没有！虽然我不太清楚其他人的状况，但我自身一直都有许多需要改进的地方。

于是她决定招聘一位 Scrum Master 来为团队做一些教练工作，这名 Scrum Master 的教练工作可能比例不高，但这确实是他的一项主要工作。

某些 Scrum Master 实际上是担任跨越不同地区的项目团队的敏捷项目经理

请记住，一个 Scrum 团队是一个跨职能的混合部队，有着 5 至 7 名成员，共同参与某一个项目。一旦你的团队成员分布在不同的地区，即使你仍然可以使用 Scrum，但它将会成为一项挑战。

当 Anne 的领导告诉她，“我们要转向 Scrum 了”。她回答道：“太棒了！”，她的想法是，这只不过是领导们的一时兴起罢了。但当领导们告诉她需要招聘一位 Scrum Master 时，她才意识到他们是来真的了。

如果你的团队是跨地区的分布式团队，一切都变得更困难了。Anne 经过了一些研究之后得出了以下结论：

我明白，我们需要的人必须对各种敏捷流程都非常了解，而不仅仅是 Scrum 而已，因为我们需要一位高级人才。他会与每一位团队成员频繁互动，甚至很可能是团队的经理。我们最初只打算让某个人兼任这个项目，让他同时去承担别的任务，而现在则决定为此项目找一个全职的人选，这是一个巨大的转变。这名 Scrum Master 要为团队扫清项目内部，以及项目外部的各种障碍。他需要懂得如何捞取政治资本并恰当地使用，并确保项目在短时间能够发布。我需要一个非常能干的人。

Anne 最终决定她所需要的是一位高级敏捷项目经理，他需要理解项目组合管理，他需要理解快速成功的必要性，并且能够快速地提交工作成果。

某些 Scrum Master 实际上是担任跨越不同地区的项目团队的敏捷程序经理

当 Anne 的首个项目产生了一些快速的成效后，她的领导决定在一个更大的产品中推广 Scrum。他们听说过“Scrum-of-Scrums”（以 Scrum 作为计划管理方法），并认为这是个完美的方案。而 Anne 自己经过一番认真的研究之后，她要求领导们不要再向她推销什么完美方案了。

我调查过几种不同的敏捷项目管理框架，包含两种轻量级和一种非常重量级的框架。最后决定采用一种轻量级的项目管理框架，我们已经掌握了一些关于它的知识。它使用的是一种我们已经了解并正在使用的语言，这样我们的脚步也不会迈得太大。

Anne 打算招聘一位敏捷程序经理（Program Manager），而不是一位“Scrum-of-Scrums”中的 Scrum Master。她的组织对程序经理的作用有着良好的认识，一位程序经理需要协调各个子项目的进展以满足业务目标。这是个策略型的角色，而不是战术型的。另一方面，她的组织并不了解 Scrum-of-Scrums 中的 Scrum Master 的作用。

某些 Scrum Master 实际上是客户经理

Denise 是一家顾问公司的经理，他们为银行业提供各种服务。他们在银行业服务多年，也非常了解他们的客户。几年前他们转换到敏捷模式，而客户也对最终结果相当满意。不过有一个问题是他们并没有一位客户经理（Account Manager）。项目经理曾经担任过客户管理的职责，但现在的 Scrum Master 并不负责这一部分内容。以下是 Denise 所说的：

之前，我们的项目经理不仅管理项目，还要管理客户的期望，一切都运作良好。如今，我们的客户在扮演着产品经理（product owner）的角色。这没问题，但我们需要某人来管理他们的期望，在中间起到缓冲作用。否则客户每天都可以让团队成员们做这个做那个，这很疯狂。

因此这位 Scrum Master 的各种互动与他的工作目标其实更像是一名客户经理，他的职责并非一名项目经理或者常规的经理。如果你所处顾问行业，那这种区别是经常性的。

Denise 是正确的。在顾问行业中，在客户方 onsite 工作的 Scrum Master 确实与其他 Scrum Master 的工作性质非常不同。

某些 Scrum Master 实际上才是真正的 Scrum Master

某些时间，你有一个 5 至 7 人的小型团队，需要一位 Scrum Master 作为服务性领导。这种情况就是最棒的！

在我下一篇文章里，我将讨论或许你认为你的 Scrum Master 所必备的一些素质，包括工作质量、做事方式倾向及其它非技术性技巧。

关于作者

Johanna Rothman是《招到适合你的极客》（Hiring Geeks That Fit）一书以及其它一些书籍的作者。她经常为高科技产品开发的管理进行顾问、举办演讲并且撰写文章。她应用各种实用途径以应对项目管理、风险管理和人员管理等方面的问题，使得企业管理者、团队与组织运作更加高效。可以在 jrothman.com 看到她的更多文章。

查看英文原文： What Scrum Master Are You Hiring?