商业持续运营管理/商业持续运营管理/项目管理

第3章：定义IT项目

概述

许多项目都是以探索者的原则进行管理：“让我们行动起来，看看会发生什么。”虽然这种方法可能令人兴奋，特别是在凌晨两点临近里程碑交付期限的时候，但它很少能产生客户想要的东西。定义项目就是找出客户想要的东西。指出为了满足客户，你需要确定什么才能做到这一点，这似乎是令人反感的初级问题，但是，客户的需求往往在实施阶段才最终明朗。那时候就太晚了。

你可能会好奇为什么很多项目一开始没有明确定义最终产品，但更有效的问题是，什么指标会告诉你你的项目可能没有关注客户需求？有一些指标。

你的团队（包括你自己）有一种“以前做过”的态度。因此，你可能会被误导，以为因为你了解应用程序（比如库存），所以你了解客户的需求，而且没有必要浪费宝贵的时间去问一些愚蠢的问题。

当你和你的团队解决问题时，你专注于技术解决方案而不是客户需求。如果你要以客户为中心，那么你和你团队讨论的所有问题都必须通过考虑什么对客户最好来解决，而不是依赖于技术上的创造力。

项目在一开始就匆忙进行。你面临着几乎不可能完成的期限，以及夜间和周末工作的迫切性。如果是这样，你将被施加压力去“继续”，去尽快生产出一些东西——任何东西——你会认为放慢速度与客户交谈是阻碍职业发展的行为。

你的客户或你的管理层（或你）认为，计算机系统项目中唯一有价值的产品是代码，其他一切都只是序言——成本高昂、耗时且价值有限。如果是这样，任何延迟“真正”工作开始的行动都是浪费的，不受欢迎的。

如果这些条件中的任何一个成立，那么你就拥有了一些力量，这些力量使你偏离了打好必要基础的工作。针对这些力量的对策是坚持尽可能清晰明了地定义项目的必要要求。

对交付成果的清晰定义，还有一个新出现的威胁。许多项目现在围绕某种形式的迭代开发进行结构化，其中准备原型、进行审查，并逐步完善，直到原型演变成最终系统。在这种系统开发方法中，原型通常用于识别业务规则和程序，这会导致人们倾向于忽略定义需求的必要性，因为“随着原型的演变，它们会变得清晰。”如果你听到这种论点，指出迭代开发是达到期望结果的一种方式，但结果仍然需要定义。事实上，这种项目方法更需要对最终目标有更清晰的定义。

为了定义一个项目，你必须定义、记录并获得客户对两件事的认可：交付成果和范围。这些内容将在本章后面讨论。

然而，定义项目不仅仅是定义交付成果和范围。你还需要定义如何进行项目。具体来说，你需要建立以下内容：

如何管理对范围的变更请求

客户将如何审核和批准交付成果

对于开发项目，项目将采用哪种方法

这些是第3章的主题。最后有一个清单，可以帮助你确保你和客户在项目的重要问题上达成一致。