产品的质量模型和项目的交付标准.docVIP

产品的质量模型和项目的交付标准 每个项目经理都想尽可能地降低项目过程中的风险。那么项目中最大的风险是什么呢？我认为是偏离了项目最初的目标。我们很多人都有这样的经验，项目做到最后，早把进行这个项目的初衷抛到九霄云外了。因此一种有效降低项目总体风险的方法就是：预先定义项目的目标，并在项目进行过程中始终锁定目标，并不断的验证目标的达成程度。 软件产品开发项目通常有三种比较常见的目标： 在规定的时间上市（时间） 实现全部的功能特性（范围） 提供低缺陷、高质量的产品（质量） 根据本人的经验，每个项目只能从上述三者中选择一个作为项目的主要目标，而对其它两个必须根据项目的实际情况进行不同程度的折中。否则项目很难成功。这种对项目目标的优先级划分在项目进行过程中决定了项目经理在面临问题时将如何决策。 风险的传统定义是：“一种会发生的潜在的问题，它一旦发生将威胁项目的成功，甚至使项目完全失败”。 在真实的项目进行过程中，经过一段时间后，项目目标会在不知不觉中发生变化。这种焦点的飘逸对项目的成功是一种很大的威胁，是一种项目经理必须时刻关注的风险因子。本文主要讨论如何根据产品的质量模型来确定项目的目标。 产品质量模型 为了定义和评估项目完成的风险，项目经理应该首先定义如何测量和评估产品的质量。产品质量的另一种解释是“产品提供给客户的价值”，项目的目标自然就应该是“为客户提供最大的价值”。 广义的产品质量不仅仅限于产品缺陷的多少，它主要由三个要素构成： 通过缩减进度，最小化交付时间 通过为客户提供他们想要的全部功能，最大化客户满意度 使交付的产品缺陷最少 定义产品质量度量标准的关键是选择一个能够创造最大客户价值要素作为优先级最高要素，并根据项目的具体环境对其他两个进行适当的折中。 也许有人对这种观点会提出质疑，为什么不将三个要素至于同等重要的地位呢？它们都是很重要的。对此我们做个试验。 假设项目现在要求是这样的： 交付日期提前一个月 但是提前交付，缺陷的数量将比预期的高 并且一些功能也不能被充分实现 如果你是项目经理或者是公司的高层管理者，你该怎么做？一般你有三种选择： 选择按期交付，那么“交付时间”就被赋予了最高优先级。 选择等到全部功能都实现了再交付，那么“客户满意度”就有最高的优先级。 如果选择等到缺陷都被修正，缺陷率达到一个可接受的低水平再交付，那么“低缺陷率”就有最高的优先级。 除了客户的要求迫使你必须明确在产品质量要素之间确定优先级之外，产品自身的生命周期对其也有很大的影响。 也许你仍然不能说服自己只将一个因素设为最高优先级。再看看下面的例子：我们将优先级划分为 0-100，0是最低优先级，100是最高优先级。我们将交付日期的优先级设置为100，缺陷率设置为 97，功能完整设置为93。咋看起来，优先级的划分过于接近以至于不易区分。不过还有其他的问题： 是否所有的缺陷在交付之前需要被修改，或者关键缺陷在交付之前要被修改？ 所有合同规定的功能是否需要被实现，或者关键的功能在交付之前需要被实现？ 或者，交付日期需要视这些而定？ 当优先级不清晰时，就会产生更多的问题。当整个项目的目标发生漂移时，产品本身也变化了，产品交付风险就大大地增加了。 每个产品有一个生命周期：创建、修订和退出。项目成功（不管产品是销售给顾客还是自己用）的关键在于识别产品处于生命周期的什么阶段，并且使用自然的驱动来帮助确定产品质量。 表一提供了一种定义产品质量和产品生命周期之间关系的迭代观点。这是Geoffrey Moore的高科技市场模型在软件质量方面的一个应用。用户（和潜在用户）在整个生命周期的各个阶段对产品的感受和期望值是不同的。如果项目经理能够清楚的了解产品处于生命周期的哪个阶段，那么他就比较容易确定产品质量要素的优先级。 这里要注意“产品”和“项目”之间的区别和联系。在本文中，项目指的是针对产品一次释放（Release）所进行的活动，产品的每次更新换代都会开始一个新的项目。 长久以来，产品开发小组（包括开发、测试和产品管理）主要是将注意力集中在如何降低产品的缺陷率上。也就是说，将“低缺陷率”作为了产品质量要素中优先级最高的。然而今天，仅根据缺陷水平来定义产品质量是不够的。产品质量（准确地说是产品每次的交付质量）的定义应该是：尽早交付客户可以正常使用的、“足够好（good enough）”的产品。 表一 产品生命周期中的质量感受 产品生命/市场压力 引入期 接受 期 成为主流 衰退期 退出期 尽早交付 高 高 中 低 低 功能完整性 低 中 低 中 中 低缺陷率 中 低 高 高 高 引入期 这个阶段，会购买产品主要是发烧友或者技术狂。这些人喜欢摆弄新技术的那种心跳的感觉。他们希望尽早将新技术玩于掌中 （对产品尽早交付要求高）。只要产品确实能干点事情，他们就会感觉很高兴