这是一个失败的软件项目，与很多失败的软件项目一样，在系统需求上栽了跟头。开发与定义软件系统的需求在整个软件开发过程中是最重要的一环，这是每个从事信息系统建设的项目经理都清楚的事情，但往往又因为一时的疏忽而造成需求的重大缺陷，最终导致项目的失败。案例中的项目经理张工就是既重视需求又没有控制好需求的一个例子。·

在案例中，张工接手了一个系统升级的软件项目。对于这样的项目，首先需要熟悉原有的系统，然后才能谈升级的问题。因此张工专门找到了原系统的需求调研人员李工来解决新系统的需求问题。这无疑是一个很好的办法，可以快速准确地把握新系统的需求。从这一点上来说，张工是成功的，找到了合适的资源进行需求的开发与定义。李工也没有让张工失望，很快就整理出了新系统的需求，并进入了设计和编码阶段，除了客户太忙没有时间确认需求外，一切尽在张工的掌握之中。这是一个阳光灿烂的开端，如果一切顺利的话，项目的成功也就是早晚的事情。就如同大多数经典的悲剧故事一样，故事的序幕是美好的。

晴朗的天空飘来一块乌云，李工要移民加拿大。不过仅仅是一片乌云而已，并没有下起雨来。开发出的需求都已经过设计，一些编码工作也已经开始，李工的工作已近圆满完成，毕竟，一些细枝末节的问题还可以同客户直接沟通。

经过项目组努力，项目终于完成开发，准备发布了。这时，乌云开始下雨，问题爆发了。客户不认可项目组的工作，认为很多需求没有实现，实现的功能也与需求不符。

谁是这个项目组的罪人呢？李工？还是张工？换一个思路考虑一下，如果李工没有离开项目组，结果又会是什么样呢？客户会因为李工还在项目组就认可这个系统吗？很显然，不会。至多可以在双发的协商下少一些变更，项目延期不是50%,而是30％而已。如果非要区分50％和30％的区别，也不过是五十步笑百步而已。

从项目管理的角度来说，项目范围直接决定了工作量和工作目标，所以项目经理必须管理项目的范围。在范围管理中，范围定义、范围确认和范围控制又是最核心的三项活动，缺一不可。范围定义是基础的活动，不进行范围定义就不能进行范围确认和范围控制。范围确认则是基线化已定义的范围，是范围控制的依据。范围控制的作用在于减少变更，保持项目范围的稳定性。在案例中，由于张工没有进行范围确认，最后的范围控制也就变成了无本之木，控制过程肯定变成了讨价还价，失去本身的意义。

在软件系统的开发中，系统需求就是项目的范围。从软件诞生至今的几十年中，人们探索出了很多获取系统需求的方法，但是熟悉软件开发的人都知道，无论哪种方法都不可能定义出完美无误的需求，需求中的缺陷必然存在，无法完全避免。因此需求确认或者说是范围确认就显得更为重要。

有人可能会说，很难说服客户在需求上签字，很难让客户为需求的缺陷负责。以现在软件行业的情况，这种说法是不无道理的。让客户在需求上签字很困难，但并不等于就不需要进行范围确认，而且范围确认的方法也不仅仅只有需求签字这一种方法。召集客户的业务代表对需求进行评审、详细记录最原始的调研材料，让客户确认调研报告、采用迭代开发逐步确认系统需求，都是可以采用的方法。这些方法虽然没有直接确认需求分析报告，但至少可以让现有需求在项目组和客户之间达成一致，提供范围控制的基准，一样可以达到范围确认的目的。

再回到这个案例，项目经理张工乐观认为李工开发的需求没有什么问题，也误认为双方已经有良好的合作，在不紧逼要求客户代表签字显得不近人情，于是就抱着侥幸信息进入了开发。然而最终的结果是，项目延期严重，业务代表反而更不满意，张工也要承担项目延期造成的成本增加的责任。

有了上面的分析，后面问题的答案就不难得出。首先看第一个问题，对张工的行为进行点评。前面已经提到，张工注意到了需求的问题，专门找到了原系统需求负责人李工进行需求开发，这是对项目有利的一面。但由于缺少需求评审和确认的过程，造成需求中的缺陷没有被及时发现，系统需求没有与客户确认，造成缺少需求控制的基准，最终导致需求的重大变更。

对于第二题，联系范围管理的知识，我们不难发现张工在范围确认和范围控制中都有重大的缺陷，在范围定义中也由于缺乏评审造成需求的质量问题。

在完成第二题后，第三题就水到渠成了，第三题的要点见参考答案，此处不再赘述。