S01E06 敏捷和项目管理

S01E06 敏捷和项目管理

大家好，欢迎大家收听PM网事，我是这档栏目的PM‘初级项目经理’。

这期节目我们来聊敏捷，在节目正式开始前，我先要声明，这期节目对于敏捷的态度是既积极又消极，但总体而言是消极的，热衷敏捷的朋友们既可以选择继续往下听，也可以选择就此打住，省得自己听完后生气。

我第一次听说敏捷，大概是在02年前后，当时软件开发还是瀑布的时代，大家习惯于在需求、设计、开发、测试、上线的路上一次次地重复着，瀑布模型带来的问题一直在困扰着项目，一直到某一天，一个叫做敏捷的模型吸引了我的注意，那时候的敏捷还是XP，它的一些做法比如说：userstory、快速迭代、测试先行和结对编程给了我不小的震撼，当时我就在想，这玩意儿如果可以实施，软件开发过程中的不少问题应该都可以解决。

等到再次关注敏捷，已经是10年前后了，当时大家已经在聊scrum，scrum与xp相比，又有了些不同，而现在，scrum已经成了一些互联网组织项目管理或者是产品管理过程的组成部分，说实话，对于这一点我既感到高兴又有一些忧虑，高兴，是因为敏捷确实可以在一定程度上解决互联网组织软件开发过程中的问题，忧虑，却是因为我们在互联网组织内部应用敏捷还存在一些误区，当然，接下来的观点是我个人的一些主观认识，如果有不正确的地方还请大家指正。

大家看到这期节目标题的时候可能会感觉有一点奇怪，什么叫敏捷和项目管理？敏捷不就是项目管理吗？

说实在话，敏捷还真不能等同于项目管理。如果敏捷不是项目管理，那敏捷是什么？

在我看来，敏捷是一种思想和行为，一种为了应对组织外部环境快速变化而产生的思想和行为。但是很遗憾，我们现在可能有点误入歧途了，我觉得，目前在应用敏捷的过程中可能还存在以下三个问题。

第一个问题，浮躁。浮躁基本上是互联网组织的通病，也正因为浮躁，所以导致我们的管理风格变得肤浅和功利，互联网组织的管理风格在我看来就6个字：快速、简单、粗暴，也正是因为有了这样的管理风格，我们才选择了敏捷。坦白的说，敏捷是一个不错的管理思想，适用于一部分互联网组织，但是，大多数使用敏捷的互联网组织都回避了更加重要，也更难实施的组织级敏捷，只选择了敏捷开发过程。希望敏捷软件开发过程可以解决或者回避组织级的管理问题是完全不切实际的。这就好比在古时候，两国交战，一名士兵胳臂上中了一箭，军医在把露出体外的箭杆剪断后，把还带着箭头的伤口一包，说：治好了。至于这伤口会不会感染溃烂，受伤的胳臂会不会因为这个而被截肢，这位军医已经不关心了。

第二个问题，手段变成了目的。这一点非常可怕，敏捷只是一种管理思想和手段，我们选择敏捷，是希望它可以解决我们在互联网软件开发过程中遇到的一些问题，而不是为了用敏捷而用敏捷，为了用敏捷而用敏捷纯属本末倒置，从根本上违背了管理的初衷。

第三个问题，夸大了敏捷的作用和适用范围。任何一种管理思想和手段都有它赖以存在的土壤和适用的范围，那种不分析管理目标和组织环境，开口闭口声称敏捷是包治百病的灵丹妙药的做法是不负责任的。这就好比在沙漠里种水稻，你非要说产量、成本都比南方的稻田更有优势，那就太挑战大家的智商了！

我们来看看敏捷开发中一些常见的误区，我大概整理了一下，总共有5个。

第一个误区：完全拥抱变化。

我们必须承认，在互联网企业的项目和产品研发过程里，变化是经常遇到的，所以啊，在互联网项目和产品研发过程中使用敏捷开发并且强调拥抱变化是可以理解的，但是，拥抱变化也需要有个度，不管再怎么变，变化造成的影响绝不能背离项目的目标和产品的定位，不管再怎么变，也绝不能破坏项目和产品的商业价值。为了变化而变化是没有价值和意义的，是需要坚决杜绝的。某些人拥抱变化可以没有底线，但没有原则地拥抱变化绝不能成为管理者的信条。

第二个误区：不写文档

做软件开发的人对于写文档普遍有一种本能的抵触，但是相对于写文档，他们看文档的兴趣明显要大的多。抵触写文档的原因无非就这么几种：第一个原因，文笔不好，写出来怕露怯。第二个原因，软件一天到晚变来变去，需要保持代码和文档同步，很麻烦，一旦文档没有跟着代码更新，以前的文档也就全都白写了，因为没人会相信不是最新版的文档，所以一套代码就解决了全部的问题，有一句话不是说吗？代码就是最好的文档。第三个原因，所谓写文档，很多时候就是拷贝粘贴成指定的格式，没有意思、没有价值。第四个原因，太忙，琐事缠身，没有时间写文档。最后一个原因，有写文档那工夫，几句话早就说完了，又简单又高效。

上面这些理由有的确实有道理，有的就纯属找借口了。

文笔不好？那是因为写的不够，写多了文笔就好了。

代码就是最好的文档？你接手一个没有文档，又从没接触过的系统的时候还会这么想？再者说了，你把需求、项目计划、风险列表写到代码里我看看！

太忙？没有时间？你为什么忙？为什么没有时间？很多时候不就是因为没有文档造成的吗？

又简单又高效？小团队里那是当然，可如果把需要写成文档的内容让你说几十遍你还会觉得简单高效吗？

不少传统IT企业之所以要强调文档，是因为当乙方当惯了，乙方开发完软件系统，交付上线一段时间后就要由甲方维护了，所以甲方一般都在合同里规定必须要有哪些文档，而且文档必须符合某种特定的格式，否则就扣钱，所以当乙方的一般都强调文档。但对于互联网企业来讲这种问题基本就不存在了，因为系统都是自己开发自己维护，只要人员管理得当，缺少一些文档不是一个很大的问题，就这一点而言，一些文档，尤其是形式超过内容的文档确实没必要写。

在我看来，写文档最大的价值有两个：第一个价值是文档可以拷问自己的思维，有些想法通过嘴说出来往往会觉得没有问题，而一旦你把它写下来的时候，经常会发现自己的想法其实是千疮百孔，嘴上说的远没有写下来的经得起推敲，很多时候项目的变更就是因为没有把信息写下来而产生的。第二个价值就是文档可以忠实地复制信息，一句话经过几个人传播可能就会串味儿，而文档就完全不会出现这种情况，而且文档的复制成本很低，对于人员流动较大、沟通渠道呈网状的互联网企业来说，一部分信息只有记录在文档上才可以确保准确而高效的沟通。

第三个误区：过于追求自由

自由，是每一个做软件的人内心深处的追求，也是互联网企业选择敏捷开发的一个原因，因为也只有在自由的状态下，在去除重重控制和没有高压的环境下，人的创造力才有可能得到释放。换句话讲，既然要实现自由，就要求我们实现自我管理。但是，自由，是可以没有边界的吗？这个世界上存在绝对的自由吗？一旦实现了自由，我们真的可以实现自我管理吗？

我们来看几个场景：

第一个场景：某技术人员在计划的关键路径上，而且他的作用无法替代，也就是说他的进度决定了项目是否会延期，某一天，他提出休假一周，如果批准他的假期，进度肯定延误，请问，如果你是他的管理者，你会同意他休假吗？

第二个场景：按照规范，关键的软件接口和模块必须要在压力测试合格后才能上线，但是，就是有人敢不做压测直接上线，结果导致系统响应缓慢，网站无法下单。请问，如果你是管理者，面对着百万级的损失，你会宽宏大量的拍着他的肩膀说没关系，自由是第一位的，下次接着来吗？

第三个场景：某项目，项目的目标、商业价值、成本、工期、可能的风险都已经评估完成了，确定项目可以实施。项目启动后不久，有人提出变更，如果实施变更，就会导致项目出现难以控制的风险，成本和工期会大幅增加，项目所交付的产品投入运营后可能会亏损，最关键的是，项目的目标变了。请问，如果你是管理者，你是会拒绝变更，还是轻松地说，没问题，不就是变更吗？不就是亏本吗？不就是砸了一堆人和资金，承受了高风险最后还都不知道自己干了什么吗？没关系，自由是第一位的，有句老话说的挺好，若为自由故，一切皆可抛嘛！

在这里，我扔一个问题给大家，在任何一家互联网公司，我们真的可以做到若为自由故，一切皆可抛吗？

自我管理是有前提的，组织的管理成熟度不够，实行自我管理就是死路一条，当然了，互联网公司的寿命目前来看都不长，如果哪家管理一团糟的公司想通过找死的方式来寻求解脱，那就一定要大力推行自我管理，我敢保证你一定会死翘翘。

通过上面的几个场景我们可以看到，控制和自由，是一对儿矛盾，过于强调控制和自由都是危险的，那平衡点到底应该在什么地方？这，是一个高管们应该慎重考虑的问题。这个平衡点如果找不准，就会一管就死、一放就乱。

第四个误区：忽视项目准备和启动阶段的意义，夸大了实施过程的价值。

就目前敏捷应用的情况来看，敏捷介入项目是从需求开始的，然后就开始多次迭代一直到最终完成交付，总体看来，敏捷是一个轻项目开始和结束两端，重项目过程的结构，也就是一个纺锤形的结构。但是，实话实说，这是一个极其危险的结构。项目管理是什么结构？项目管理和敏捷刚好相反，是重项目开始和结束两端，相对轻过程的结构，也就是类似哑铃形的结构，因为项目管理认为决定项目成败的关键在于项目的启动和启动前的准备阶段，这倒不是说中间过程控制和后面的收尾不重要，而是说如果一个项目连准备和启动阶段都做不好，后面就不要再做了，这一点也同样需要引起敏捷团队的注意，下面我大概列一下项目，当然，这里说的还是单项目，单项目在启动前需要评估什么，需要考虑哪些因素，大家可以看一下，敏捷团队有没有做这些事情，这些事情对于促进项目成功到底是不是多余的：

1. 项目的目标是什么？和组织战略有什么直接或者间接的关系？

2. 项目的来源是什么？是谁发起了项目？项目为什么会被发起？主要的利益相关方都有谁？谁支持？谁反对？谁中立？在项目里他们的利益都是什么？

3. 组织和项目环境是什么样的，项目经理能得到什么样的授权？得到的授权是否足以推动项目？如果授权不够，是否需要为项目建立恰当的治理结构？

4. 项目的需求是什么？注意，这里的需求不仅仅是软件方面的需求，而是将一个或者是多个产品从项目交付给运营整个过程的需求。

5. 项目可选的方案是什么？不同方案的工期、商业价值、成本、风险、产品、质量标准、验收标准和对运营的影响分别是什么？

6. 项目所需要的资源数量和质量是不是可以支持完成项目？如果不能支持，如何解决？

7. 项目的整体计划是什么？当然，这里的计划不仅仅是进度，也包括质量、沟通、资源、风险、配置管理等各项计划。

8. 主要利益相关方是不是已经都批准或者同意了方案和计划？

9. 为了更好地推动项目，项目的流程和控制点是什么？需不需要做项目管理培训？

10. 项目经理是谁？他有没有足够的知识、经验、技能和影响力管理和控制项目？

我就先说这10条，当然，组织环境不一样、项目情况不一样，在项目初期需要了解的内容会有一些差别，但我需要说的是，站在项目管理的角度来讲，在实际项目中，需要确定的内容要比这10条多得多。

在这里，我想问敏捷团队，在项目初期，上面列的这10条内容我们弄清楚了几条？是全部弄清楚了，还是只弄清楚了其中几个，还是说压根儿就不想考虑得那么清楚？弄清楚这10个问题对于促进项目成功是多余的吗？我们不会真的认为，敏捷倡导拥抱的那些所谓变化，和项目前期准备不充分没有关系？敏捷真的是项目管理吗？如果它真的是项目管理，那为什么如此多涉及到项目方向和成败的因素都可以忽略呢？难道敏捷真的有一种魔力，只要用了敏捷，这10个因素就可以不用考虑了？项目就会成功了？如果我说，如果敏捷使用不当，会导致更多的变化，你相信吗？

所以，如果是做项目，敏捷开发必须和项目管理相配合，否则就很容易出现一种情况，那就是项目匆忙启动，带着大量的隐患和不确定因素进入实施阶段，然后，我们在不得不拥抱所谓的变化的同时，绑架了项目，也绑架了组织。这就如同某些互联网公司正在绑架投资人一样。

第五个误区：敏捷应用于所有的项目开发

我不否认，敏捷是一个很好的思想，它可以应用于项目和产品研发中，但是，我们应该不难发现，项目的复杂程度和压力从整体上来讲是要超过产品的，敏捷和敏捷开发未必适合所有的项目，我一直认为，最适合敏捷的环境其实是产品研发。

好，我来做一个小结，就目前敏捷应用的情况来看，敏捷还只是一种软件开发方法，一种在特定组织环境、项目环境或者产品环境里可以解决瀑布模型问题的软件过程控制方法，属于软件开发的一个分支，属于技术过程，而不是管理过程。所以，敏捷和软件开发一样，从严格意义上讲都不属于项目管理，当然，项目管理可以兼容包括敏捷在内的软件开发过程，敏捷软件开发过程更适用于产品研发。

组织级的敏捷我们之前已经说过了，就是要结合扁平化、去中心化等思想在组织内部营造一个适合敏捷生存和发展的组织文化和环境，在这样一种环境里，敏捷开发才能体现出真正的价值，组织级敏捷应该怎么实现呢？这个话题比较大，我认为，敏捷化的组织级项目管理体系是一个不错的选择。具体该怎么做，以后有机会我们再展开。

前面几期节目我们聊了项目管理的组织环境、互联网思维、项目治理、产品管理和敏捷，那做为在互联网行业管理单项目的项目经理，应该具备什么样的素质才可以胜任呢？互联网行业的项目经理们未来的职业发展该如何走呢？我们下期将给大家介绍项目经理的任职资格，希望下期节目可以给互联网行业的项目经理和产品经理带来一些借鉴，下期节目也将是这个阶段的最后一期节目，我们下期节目见。