项目经理在敏捷中的职责

作者 Vinay Aggarwal 译者 顾全 发布于 2009年12月29日

领域

过程 & 实践

主题

企业级敏捷 ,

敏捷技术 ,

敏捷

标签

管理

书里的敏捷不谈管理者的角色，而是谈教练/促进者。本文首先解说了各行业通常意义上的项目经理角色，然后试图将其与敏捷中的教练/促进者角色相对应。在这一探讨中，本文也试图拓宽教练/促进者的工作范围。

在探讨敏捷中的项目经理角色前，让我们首先看看各行业中到底为什么需要管理者。

1. 人无完人

   人类头脑的工作方式是非常复杂的。世上没有两个脑袋想法一模一样。就像两个指纹绝对不可能重合，两个个体的工作方式也不可能哪怕90%合辙。美妙的自然，创造出如此多而各不相同的个体，实在让人赞叹。但是，商业目标对所有利益相关方都保持“唯一而相同”。这里提到的人，代表所有参与项目的利益相关方，他们来自不同部门，如（a）项目团队成员、（b）业务用户、（c）管理层和出资人。每个项目在每个地方都需要管理人员，从而做到：

   1. 让人们与项目目标保持一致并调优其工作方式。
   2. 发挥人们最佳能力。
   3. 帮助人们保持专注和激励。

   如果项目中每个人都是完美的，那无论什么行业的任何项目都不可能失败，不管是瀑布还是敏捷的软件开发模式，完美的人总能造就完美的项目。

2. 控制改变

   生活中唯一不变的就是改变。什么事物都会变，不管是有形的（如需求）还是无形的（如人员）。

   1. 需求就像风，总是吹拂（就是改变）。
   2. 人的经验和阅历每天都在改变[比如，我明天的经验比今天将+1天]。这会带来改变，对我的：
      1. 抱负
      2. 技能
      3. 信念
      4. 态度
      5. 任何其他软硬技能
   3. 业务和市场瞬息万变。因此，客户的期望可能改变。
   4. 技术领域时时发生着改变和创新——软件项目环境、架构和设计、开发流程都可能改变。
   5. 资源流动在长期项目中不可避免。
   6. 就数学意义而言，计划是一个时间函数。无论是在项目组、项目还是Sprint层面上，不管你计划如何周密——它可能明天就无效了。计划中的所有属性（任何层面的任何计划种类）都有时限，有些近在明天。当所有事情不断地、不可预期地发生改变，昨天的计划如何能在明天有效呢。在这一语境中，管理者的角色是：
      • 给予人们持续激励，让人们全心投入到项目中。
      • 以实际的过渡计划应对资源流动，将对业务的影响降到最低。
      • 时刻注意计划，让计划与时俱进，采取相应的额外步骤来管理影响和改变。
      • 因为人员和计划都是动态的，所以要与利益相关方就影响和应对策略保持持续沟通。
3. 交流导致嫌隙和冲突


1. 沟通交流是所有快乐之源，也是所有冲突之源。
2. 它是一种艺术，总是需要勤勉不怠、深思熟虑，提前想到信息会如何被受众解读，是否会冒犯某人，是否足以保证信息的传递顺畅到位。世上少有人具备这一艺术。
3. 开发人员通常太注重技术，于是（有意或者无意地）忽略了这一精巧艺术。
   
   项目经理在很大程度上控制着沟通交流职能。他/她应当在团队成员愿意承担时对其下放部分责任。
4. 流程并非完美


1. 没有完全理想的流程（比如软件开发方法，不管敏捷或瀑布，都不完美，没有理想的流程来忠诚地定义客户-供应商关系，而且就算有，也几乎不可能按照其实质精神来履行）。
2. 就算一个流程对某人或在某种情况下运行绝对良好，它对不同环境下的另一个人也许就会可怕地失败。
   
   管理者应该让团队关注于结果，而非总是担心流程。“流程为我所用，我不为流程所用”——意思是，遵循流程并非最终目标，它只是达成某种结果的工具。管理者应该与团队一起，决定流程的哪部分对该项目最佳，并只适用那个部分。
5. 流程实施不当


1. 流程实施总是意味着更多的工作，更多的辛劳，更多的跟踪记录，而这些是任何通常意义上的开发团队力图避免的。流程开销被很多人当成是罪魁祸首。
2. 一个特定流程在整个项目期间被100%原汁原味地实施，是很罕见的。
   
   如果任何对流程的违背可能导致混乱并对项目产生负面影响，管理者需要干预并保证对所有优良实践的高度遵守。

如果以上5个原因都不成立，就没有什么行业需要管理者了。但是很不幸，以上5者在每种行业、每家公司、每个项目和每次sprint全都存在。投资人和利益相关者必须在任何项目中得到好的投资回报(RoI)，所以需要有人来摆平这些事情，并且仍然帮助达成项目的业务目标。所有上述五个属性实质上都不是技术相关的，可以通过应用管理实践来很好地应对。而扮演这一角色、将管理实践带入项目的人，在企业界就叫做“管理者”。但这不是说，管理者们有万灵仙丹来让上述这些达到完美，但是他们能帮助人员和流程得到调优，监控并应用横向思维的管理概念，来产出创造性的解决方案，以使上述五点不会大范围地影响业务目标。这一角色的一个子集，在敏捷用语中被描述为教练/促进者。

敏捷创造了一个新词汇，叫“自组织团队”。我个人是自组织团队的忠实粉丝。它在很多时候运行良好，尤其是在那些人们于公共生活中展现高度责任和义务标准的文化中，这是因为人们把这些高标准同样带进了办公室，完美地匹配了“自组织”团队。让每个雇员都工作于自组织的模式中，是所有公司的梦想。但是就像所有人类各不相同一样，不是每个人都适合“自组织”的团队。比如，不是每个医生都能成为外科医生、牙医或者整形医生，但是每个医生仍然都对社会有用。相似地，不可能期待每个人都能以“自组织的风格”工作。然而，同样是这些（不适合自组织定义的）个人，假如以不同方式处理，仍然可以成为很棒的贡献者。这里就是项目经理角色变得特别有帮助的地方，他可以通过多多少少（依赖于个体情况）的监管，让团队成员做出最佳的工作。敏捷使用“教练/促进者”一词来代表这种角色。另一方面，这一角色在人们稍稍偏离自组织状态时也工作良好。在如下3种情况中，教练/促进者或许必须延展其工作范围。

1. 人们过度偏离自组织状态（比如非常无组织、非常不专注、情绪化等等）。
2. 人们的软技巧与业务需求不相匹配（比如，不能做到积极主动，害怕讲话，沟通不良，时间管理差等等）。这些软技巧的缺乏，不可能让真实的潜力转化为绩效。
3. 人们得了企业病（比如诽谤中伤，嫉贤妒能，自吹自擂，知识垄断，阿谀奉承等等）。技术上讲，假如有强力的管理者（而非教练）以持续的监督来控制他们，在影响到团队互动之前就扼杀这些苗头，仍然可能使这些人有所产出。

我在此的意思是，我们应当对所有专业人员具备高度的包容。但是处理和发挥一个个体的长处，方法因人而异，没有适用于每个人的通行法则。组织在这一点上应当反省。所有国家都有很好的技术人员，他们可以是好的贡献者，但也许不能自组织。这就是教练/促进者会转为更像一个项目经理的地方。这些人也许会犯错，也许需要引导和监管，也许缺乏软技巧，如此等等。在教练/促进者的有限范围内，让这些类型的人员与敏捷相适应来完成工作，会成为一个噩梦。我对各种各样的人充满尊重，也坚信这些人可以成为好的贡献者，但是你需要延展教练的职责范围，给与其某种权力来强硬地表明“什么该做，什么不该做”。这里项目经理的角色就变得有帮助。下表展示了一些觉得需要项目经理的其他领域。

情境编号	事实	敏捷如何有用	敏捷帮不上忙的地方 （而管理者可以！）	备注
1	人无完人	举行每日进度会议，让他们保持专注，让产品负责人保持需求与业务相一致。	1.专注点是否在正确方向上？ 2.产品负责人是否每个冲刺都改变目标？ 3.责任是否真正分担？如果每人都觉得别人更有经验、懂得更多，所以更要负责，该怎么办？ 4.人们是否以敏捷之名掩盖自己能力的不足？ 5.团队是否做到真正自组织？ 6.人们是寻找外部原因作为借口，还是真正有所改善？ 7.团队中是否有某人正抢占所有功劳，而损害了团队动力？ 8.是否有人垄断了知识，不与团队分享？	具备横向思维的管理者可以想出创新的办法来管理不完美之处。 教练可以用合适方式提出如何做事，但如果人们不遵循又如何？比如，要是团队在演示后不听取产品负责人的反馈呢？这是可接受的，还是必须强制听取？
2	控制改变	敏捷在每个冲刺开始时欢迎新的需求，而Scrum Master在冲刺中防止范围蠕变。	1.Scrum Master是否正确履行职责？ 2.测试人员是否按时做了工作？ 3.人们的软技巧和承诺是否正在改变？ 4.客户是否突然开始不信任敏捷？ 5.客户是否突然开始期待不切实际的事情？	敏捷以需求优先级来照管改变，但只是一部分。 产品负责人可以发挥影响力，在冲刺进行中增加故事，可团队不知道如何应对？ 任何方法都无法应对无形的改变。
3	沟通不适当	敏捷用站会提供了每日沟通的机会，也用回顾会议创造了大家畅所欲言的平台。	1.团队是否真正提出障碍？ 2.团队是否积极主动地沟通所有事项？ 3.受众是否完全理解了沟通内容？ 4.我们的沟通中是否有语言或文化的隔阂？ 5.分布式的沟通是否成了瓶颈？用户体验是否良好？ 6.是否所有email都得到回复，并达到预期、质量良好？	公司沟通是与懂得写程序非常不同的课题，也是很困难的课题。 管理学研究解释了沟通的艺术性。 任何流程都不能处理软技巧。
4	流程不完美	敏捷在软件开发中有效。	每个方法论都有其局限，最终是人来使项目成功。	差的敏捷不如没有敏捷。
5	流程实施不恰当	敏捷是一个实施依赖于人的流程。	1.人们是否遵循流程？ 2.流程可否改善？ 3.流程的哪些子集适合我的项目？ 4.例外在哪里，何时偏离流程没有关系？	一个简单例子——在敏捷中，团队是否进行大量的结对编程？ 最佳实践何时真的成为我项目的最佳实践？

如果情况出错，项目经理可以拓展其角色至教练/促进者之外。他/她可以控制那些本质上不适合敏捷或是意图上不愿意敏捷的团队成员。我想要指出3个业内普遍流行的神话，他们在敏捷的语境中更加显著。

1号神话：管理者们有万灵仙丹。

事实：处理人的头脑非常复杂，极其有挑战性。这里没有科学，只有纯粹的艺术。不管你做什么，总有不可管理的人，不可控制的改变。以我的愚见，一个好的管理者能够：

1. 完全解决50%的问题，
2. 部分解决15%的问题，
3. 通过沟通让问题显而易见，让15%的问题看上去没有影响或者超出范围，
4. 20%的问题总归存在（有些特定情况下的人和有些改变就是无法管理）。我们必须接受这一点。

请注意，如上这些数字只是我的经验表达，不是基于任何科学的研究调查。

管理者也是人，像其他人一样并不完美。“全方位思考（holistic approach）”的管理是另一个概念。它是一项完全不同的职业，其设计就是为了管理不完美的人和流程。具备相当经验和学识的人可以带来很多价值。

2号神话：管理者们总是限制自由。

事实：对某些霸道的管理者可能是如此。但是实际上，好的管理者创造一个环境，提高表现，让人们发挥出最佳水准。有经验和见识的管理者可能暂时性地限制团队的自由，但其目标最终只是帮助人。有时候人们不能提前看到这一点，因为(a)缺乏经验(b)工作环境过于宽松(c)总是伴随着短视的傲慢心态(d)其他任何未言明的原因。

也有可能是，不胜任的人员惧怕被曝光，于是感觉管理者限制自由。渴望做出成绩的人应当提高自己的标准，利用管理者的经验来弥补不足，并与他/她紧密工作，以获得更多责任，让管理者可以放心休息。

3号神话：管理者不应该有权威。

事实：有些国家和文化从来就灌输公共生活中的责任义务观念，这些情况下是不需要权威的，教练/促进者在这类环境中将如鱼得水。但是权威的概念在有些仍在演化而未达到成熟阶段的社会更有意义。为了控制上述5个原因（本文开头所提），任何管理者在那些环境中都需要权威。没有权威的管理者就像没有油的汽车。研究显示，人的思想在心理上（尤其是成年期）就像硬铁条一样难于弯曲。要把钢铁塑造成漂亮的器具，权威是必需的。当全世界都变得非常勤勉、负责、成熟，以自组织的方式达到高效的时候——全球的管理学院都要关门大吉了。

结论

敏捷是一种很好的软件开发方法，它帮助克服了传统瀑布流程的一些不足。但是敏捷不是使项目成功的王牌。项目中进行工作表现的还是同一批人，而一有人的存在，就总有挑战。这个世界（以及人）充满了问题和缺憾。科学家们通过创新科技来帮助社会，类似地，管理这个职业帮助人们在受到制约的情况下仍能获得商业和职业上的成功。没有什么方法论可以排除管理者，除非是由完美的人来执行。流程是一套指导方针，有流程的地方就有偏差，有人的地方——就有问题。为了管理人和问题、控制偏差和改变——每个项目都需要专业管理的帮助。与此同时，管理者们也是人，他们也同属于这个由缺憾构成的世界，某些管理决策也可能失败。利益相关方必须接受这一点。在一定的环境中，管理者可能需要权威来应用一定的措施，来保证项目的最佳利益。这些措施可能在团队成员中遇到阻力，因此为了应用它们——有时候教练/促进者工作良好，而在有些情况下，具备权威的管理者才可以。

关于作者

Vinay Aggarwal是印度Xebia IT Architects的交付经理。他在IT业界有11年的经验。他拥有工程学学士学位，是PMI认证的项目管理专家(PMP)和经认证的Scrum Master(CSM)。曾在IBM和埃森哲等公司任职。他在瀑布和敏捷（Scrum）方法论上都有很多经验。他信奉横向思维，并将管理学概念应用于解决各种交付上的挑战。

查看英文原文：The Role of Project Managers in Agile。

---

感谢郑柯对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

1. 返回顶部

   good

   发表人 飞云 高

   不错的文章

   回复

2. 返回顶部

   Good

   发表人 张 林

   很有帮助。时刻要意识到不完美的世界，不完美的公司，不完美的项目，不完美的流程，不完美的个人。

   回复

3. 返回顶部

   值得深思

   发表人 Xu James

   很不错的文章。
   文章主体很好，说明了当前项目开发中的项目管理的必需的问题。
   给我带来了很清晰的概念。

   回复

4. 返回顶部

   棒极了

   发表人 huang edgen

   果然是经验丰富，受益匪浅！

   回复

5. 返回顶部

   务实的讨论了很多研发类项目中的现实问题

   发表人 Chan Jackei

   非常非常好的一篇文章！务实的讨论了很多研发类项目中的现实问题，包括敏捷本身的局限性，同时也探讨了如何切换在敏捷项目教练和强势的项目经理这两种不同的风格和身份中切换，来更好的解决这些问题。
   值得反复阅读。
   
   敏捷是一种很好的软件开发方法，它帮助克服了传统瀑布流程的一些不足。但是敏捷不是使项目成功的王牌。项目中进行工作表现的还是同一批人，而一有人的存在，就总有挑战。这个世界（以及人）充满了问题和缺憾。科学家们通过创新科技来帮助社会，类似地，管理这个职业帮助人们在受到制约的情况下仍能获得商业和职业上的成功。没有什么方法论可以排除管理者，除非是由完美的人来执行。流程是一套指导方针，有流程的地方就有偏差，有人的地方——就有问题。为了管理人和问题、控制偏差和改变——每个项目都需要专业管理的帮助。与此同时，管理者们也是人，他们也同属于这个由缺憾构成的世界，某些管理决策也可能失败。利益相关方必须接受这一点。在一定的环境中，管理者可能需要权威来应用一定的措施，来保证项目的最佳利益。这些措施可能在团队成员中遇到阻力，因此为了应用它们——有时候教练/促进者工作良好，而在有些情况下，具备权威的管理者才可以。

   回复

6. 返回顶部

   很有帮助的文章。

   发表人 张 少博

   确实，我们需要做的是，使不完美的过程尽量完美，并展示出完美的结果来。

   回复

• 更早的 >