在刚开始从事IT项目管理工作后不久，我就从现实工作中领会到三个真理：

　　1、 真正的需求从“眼见为实”中来
　　2、 需求变更是一定的
　　3、 大型项目，失败是常事，成功必艰辛

　　切身体会的结果，是我摒弃了传统的项目管理方式，转而尝试需要和干系人进行灵活互动的、现在叫做“敏捷”的方法论，从而彻底改变了我IT项目管理的风格和手段。下面是我关于“敏捷”的感悟，相信对读者你定有所裨益。

　　真正的需求从“眼见为实”中来

　　我曾经领导过一个web开发项目。我们花了几天和干系人周旋来获取需求，然后讨论形成完整的流程图，并梳理出所有需处理的异常。最后我们做出了一份包含所有需求的堪称完美的需求文档。

　　干系人看过后也纷纷满意并批准我们进行下一步的开发，于是我的团队就开始雄心勃勃地大干起来。不久我们就搞出了符合需求说明的软件。可当我们自信满满地交付用户测试后，他们竟然告诉我们这个软件根本就不是他们想要的。

　　这怎么回事？不是符合需求文档吗？需求文档不是用户亲自审批通过的吗？难道有什么我们没考虑到的吗？

　　因为真正需求的前提，是“眼见为实”。

　　眼见为实，就是看到了才知道是不是想要的。用户对软件的构想，和他们对需求文档的批阅，根本就是两回事。避免劳神伤财的唯一办法，是根本放弃对需求文档的崇拜，转向“所见即所得”。

　　根据敏捷的观点，我们会晤项目干系人，让他们提出最先想实现的需求。然后我们着手开发出第一个原型，让他们试用和给出反馈－不是文档型的反馈，而是实实在在的双方能看得见摸得着的东西。

　　需求变更是一定的

　　变更随时随地，无处不在。为了避免“计划赶不上变化”，我们在项目管理中必须预测变更的发生。这一点和传统型项目管理的思路更大相径庭。

　　在传统型项目管理中，我们偏好一成不变的需求，厌恶那些“善变”份子；纵使有变更，我们一定会根据事先定下的流程审批变更。这就是说，我们总是极力让变更这种真实的存在来顺应我们“纸上谈兵”形成的完美。

　　这些消灭变更的“努力”，实际上，在很多时候扼杀了真正有意义的范围变更和需求变更。从另一个角度说，变更是因，项目管理，先后关系要分清。

　　在实际中，可以通过分阶段进行项目来取得更“敏捷”的效果。在每个阶段的项目收尾过程，我们应该自问：哪些需要变更，是否要根据新技术手段重申项目计划，是否要根据市场竞争变化重申项目需求，是否要根据更改过的流程重申业务模型，等等。如果其中有需要，我们就应该为下一阶段的开发项目事先完成这些变更。

　　大型项目，失败是常事，成功必艰辛

　　多年前我读过一份有趣的报告，说IT项目规模越大，项目管理越困难（预算超支、进度超期、范围蔓延等），而且，规模大到一定程度，项目失败是必然的结果。

　　正相反的是，小型项目，则基本上一定成功。那很自然，为了追求项目成功，我决定将管理的所有IT项目转变成小型项目来管理。

　　我现在管理的项目，要么本身是小规模的，要么被我分割成了小规模。如果一个项目需要耗时9个月，我一定先把它“打碎”成2到3个月的项目单元。“打碎”项目并不像你想的那么难。譬如你有一个网络升级的项目，第一个项目单元，应该是在一个封闭的区域测试你的新网络设备，或者组建一个小型实验室来测试核心交换逻辑。下一个项目单元的涉及，则完全取决于前一个项目单元的结果。

　　对我所管理的任何项目，我都会如此来“分割”。在一个商业智能的项目中，我们首先选择一个事业单元的小部门进行测试。这样做让我们减小风险也更专注于结果。成功摸索出如何部署商业智能组件后，我们进而在事业单元的其他部门推广。又如我们要实现一个“软件即服务”（SaaS）的应用，我们先找出一小组用户进行测试，成功后再推广到整个组织中。

　　早在听说“敏捷”前很久，我就开始实践这种项目管理模式了，因为这种方法的确奏效。希望读者你能从中获益。