每个项目经理都想尽可能地降低项目过程中的风险。那么项目中最大的风险是什么呢？我认为是偏离了项目最初的目标。我们很多人都有这样的经验，项目做到最后，早把进行这个项目的初衷抛到九霄云外了。因此一种有效降低项目总体风险的方法就是：预先定义项目的目标，并在项目进行过程中始终锁定目标，并不断的验证目标的达成程度。
软件产品开发项目通常有三种比较常见的目标：
在规定的时间上市（时间）
实现全部的功能特性（范围）
提供低缺陷、高质量的产品（质量）
根据本人的经验，每个项目只能从上述三者中选择一个作为项目的主要目标，而对其它两个必须根据项目的实际情况进行不同程度的折中。否则项目很难成功。这种对项目目标的优先级划分在项目进行过程中决定了项目经理在面临问题时将如何决策。
风险的传统定义是：“一种会发生的潜在的问题，它一旦发生将威胁项目的成功，甚至使项目完全失败”。 在真实的项目进行过程中，经过一段时间后，项目目标会在不知不觉中发生变化。这种焦点的飘逸对项目的成功是一种很大的威胁，是一种项目经理必须时刻关注的风险因子。本文主要讨论如何根据产品的质量模型来确定项目的目标。
产品质量模型
为了定义和评估项目完成的风险，项目经理应该首先定义如何测量和评估产品的质量。产品质量的另一种解释是“产品提供给客户的价值”，项目的目标自然就应该是“为客户提供最大的价值”。
广义的产品质量不仅仅限于产品缺陷的多少，它主要由三个要素构成：
1、通过缩减进度，最小化交付时间
2、通过为客户提供他们想要的全部功能，最大化客户满意度
3、使交付的产品缺陷最少

定义产品质量度量标准的关键是选择一个能够创造最大客户价值要素作为优先级最高要素，并根据项目的具体环境对其他两个进行适当的折中。
也许有人对这种观点会提出质疑，为什么不将三个要素至于同等重要的地位呢？它们都是很重要的。对此我们做个试验。
假设项目现在要求是这样的：
交付日期提前一个月
但是提前交付，缺陷的数量将比预期的高
并且一些功能也不能被充分实现

如果你是项目经理或者是公司的高层管理者，你该怎么做？一般你有三种选择：
选择按期交付，那么“交付时间”就被赋予了最高优先级。
选择等到全部功能都实现了再交付，那么“客户满意度”就有最高的优先级。
如果选择等到缺陷都被修正，缺陷率达到一个可接受的低水平再交付，那么“低缺陷率”就有最高的优先级。

除了客户的要求迫使你必须明确在产品质量要素之间确定优先级之外，产品自身的生命周期对其也有很大的影响。
也许你仍然不能说服自己只将一个因素设为最高优先级。再看看下面的例子：我们将优先级划分为 0-100，0是最低优先级，100是最高优先级。我们将交付日期的优先级设置为100，缺陷率设置为 97，功能完整设置为93。咋看起来，优先级的划分过于接近以至于不易区分。不过还有其他的问题：
是否所有的缺陷在交付之前需要被修改，或者关键缺陷在交付之前要被修改？
所有合同规定的功能是否需要被实现，或者关键的功能在交付之前需要被实现？
或者，交付日期需要视这些而定？
当优先级不清晰时，就会产生更多的问题。当整个项目的目标发生漂移时，产品本身也变化了，产品交付风险就大大地增加了。
每个产品有一个生命周期：创建、修订和退出。项目成功（不管产品是销售给顾客还是自己用）的关键在于识别产品处于生命周期的什么阶段，并且使用自然的驱动来帮助确定产品质量。
表一提供了一种定义产品质量和产品生命周期之间关系的迭代观点。这是Geoffrey Moore的高科技市场模型在软件质量方面的一个应用。用户（和潜在用户）在整个生命周期的各个阶段对产品的感受和期望值是不同的。如果项目经理能够清楚的了解产品处于生命周期的哪个阶段，那么他就比较容易确定产品质量要素的优先级。
这里要注意“产品”和“项目”之间的区别和联系。在本文中，项目指的是针对产品一次释放（Release）所进行的活动，产品的每次更新换代都会开始一个新的项目。
长久以来，产品开发小组（包括开发、测试和产品管理）主要是将注意力集中在如何降低产品的缺陷率上。也就是说，将“低缺陷率”作为了产品质量要素中优先级最高的。然而今天，仅根据缺陷水平来定义产品质量是不够的。产品质量（准确地说是产品每次的交付质量）的定义应该是：尽早交付客户可以正常使用的、“足够好（good enough）”的产品。
表一 产品生命周期中的质量感受
产品生命/市场压力 引入期 接受期 成为主流 衰退期 退出期
尽早交付 高 高 中 低 低
功能完整性 低 中 低 中 中
低缺陷率 中 低 高 高 高

引入期
这个阶段，会购买产品主要是发烧友或者技术狂。这些人喜欢摆弄新技术的那种心跳的感觉。他们希望尽早将新技术玩于掌中 （对产品尽早交付要求高）。只要产品确实能干点事情，他们就会感觉很高兴 (对产品功能完整要求低)。只要缺陷不影响他们“发烧”，他们也就满足了，甚至他们会因为发现产品的缺陷并指出来而获得更大的满足（对低缺陷率的要求是中等的）。
接受期
这个时期，购买产品的主要是爱赶时髦，理念超前的顾客，他们购买产品一方面是因为希望自己走在潮流的前面，另一方面确实需要产品为他们解决一些特殊的问题，这些问题是以前市场产品无法满足的。他们需要尽快获得产品 (对产品尽早交付要求高) ，他们对功能有大量的要求 (对功能完整性的要求是中等的)。缺陷的总体数量不是主要问题，只要他们需要的功能工作正常就行了，或者已知的缺陷有回避的方法就可以了 (对低缺陷率的要求低)。
成为主流
主流期的用户主要是实用主义者。如果希望这些顾客购买产品，产品必须能够以稳定的质量解决他们所有的问题(对低缺陷的要求高)。换句话说，存在的缺陷必须对他们每天使用这个产品进行的工作有非常小的影响。如果你准备发布一个新版本，他们通常会等你，但是不会等太久（对尽早发行要求中等）。因为这些顾客是实用主义者，他们不会去发掘任何超出你已经实现的或者宣称有的功能之外的功能 (对功能的要求低)。
衰退期
保守用户会一直等到产品达到相当的成熟才会购买。他们会追求低缺陷率，必须确保已知的缺陷对他们的使用影响小，对提高他们个人事业的成功有帮助 (对低缺陷的高要求)。他们期望功能会按你承诺的那样工作，但是他们不关心额外的功能。（对功能完整的要求中等）。他们不会很关心你何时发布新版本——他们甚至根本没有打算升级(对尽早发行的要求低)。
退出期
在这个时期才购买产品的通常是产品的怀疑者。他们对有缺陷的产品不感兴趣（对低缺陷率的要求高）。事实上，他们购买产品的唯一理由是他们需要从你的产品里获得他们在别的地方找不到的某些特殊功能（对产品功能完整要求是中等的）。因为怀疑者也关心缺陷问题，所以他们一般愿意等待产品新版本的交付(对尽早交付要求低)，但是他们希望新版本比旧版本在缺陷率方面有显著的改善。
确定项目的焦点和交付目标
根据产品质量模型，定义项目质量要素的优先级就比较容易了。之所以容易是因为项目经理可以将焦点集中在项目目标上，而不是集中在产品在整个生命周期中的目标上。项目的交付目标的具体表现形式就是：交付标准。
如果你所在的公司在项目开始之前编写需求文档（大多数公司是这样的），那么项目目标应该和项目需求是相同的。但是实际上，很多商业软件没有明确的产品规格说明，或者至少其详细程度不足以作为交付标准。
对项目的交付目标设定限制是非常关键的：要针对本次发行的设定目标，而不要针对最终的、将要退役的产品设定目标。项目经理聚焦到交付目标的一种方法是与产品经理一起合作，定义产品“从生到死”各个阶段的需求，并据此确定与每个产品版本相关的项目的目标。
例子：通讯中间件产品
在这个例子中，我们假设通讯中间件产品处在它的生命周期的接受期：只有少量的顾客愿意为产品开发付钱，因为这些客户对产品预期的功能有巨大的需求。产品必须能按时交付，它的功能必须能够让这些客户有足够的理由说服他们的高层，“这个产品就是我们需要的正确的工具”。我们根据产品质量模型来选择合适的Beta标准和交付标准。
对于Beta标准，有一个高于一切的标准——产品的Beta版本必须在四月份完成。
Beta标准
下面是一个Beta标准的例子：
1. 所有代码必须在所有平台上编译和构造；
2. 所有的开发测试必须通过；
3. Beta用户的所有测试必须进行且通过；
4. 所有当前发现的Bug必须被保存进Bug跟踪系统；
5. 第一版的文档必须能够交付给客户；
6. 冻结代码；
7. 技术支持训练计划就绪，技术支持人员就位；
8. 少于36个开放的高优先级Bug。
我们看到，这个Beta标准是围绕一个指定的交付日期制定的，不需要减少Bug或者增加功能。这要求项目组尽早的启动Beta测试，来提高按时交付的可能性。直到本次发行为止，组织还没有正式的统计或者跟踪缺陷。
注意，即使当讨论同一个产品时，上面讨论的Beta标准和后续的交付标准也存在很大的反差。对于这个产品的交付标准，高于一切的目标是在6月15日之前交付产品。
交付标准
1. 所有代码必须在所有平台上编译和构造；
2. 没有高优先级的BUG；
3. 所有开放的BUG，在发行说明中都被明确的记录，并提供了绕开的方法；
4. 所有计划的SQA测试被运行，至少90%通过；
5. 最后三周开放的BUG的数目是呈下降趋势的；
6. 所有Beta用户的报告都进行了评估，并且记录在案；
7. 可靠性标准：仿真一个星期，从各种平台上，用各种不同的服务，发送各种大小的消息，每天最少200条；
8. 完成最终文档，并提交给公司；
9. 至少2个可供推荐的Beta用户（即对产品满意的，可供潜在客户参考的客户）

通讯中间件产品的交付标准聚焦在以合理的软件功能在规定日期交付，但是缺陷率不一定很低。产品的功能集中在性能和可靠性领域以保证客户能够成功的使用产品。
机器视觉产品的例子
与上面的例子对比一下在维护期的机器视觉产品的交付标准：
交付标准
1. 所有系统测试被执行，90%以上通过；
2. 任何的“启动”序列执行成功；
3. 被执行的测试的结果已经和产品管理小组进行讨论；
4. 对所有合适的平台能够成功生成可执行图像；
5. 代码完全冻结；
6. 文档复审完成；
7. 没有可能造成停机的BUG；
8. 严重的BUG少于4个，轻微的BUG少于15个；
这些聚焦缺陷的标准（尤其是第7和第8条）将产品质量的核心定义为低缺陷率。这些数字的选择一般是根据产品的前一个发行做出的，并且假设每个已知存在的缺陷的严重程度都能被评估。交付日期仍然是重要的，否则缺陷水平可以更低，系统测试通过率也应该更高一些。
使用交付标准来管理产品交付风险
有风险意识的项目经理采用这些产品交付标准，并且不断测量项目的进展。聚焦于产品交付标准使在问题产生时进行项目折中和权衡变得容易了许多。
总结
产品在其生命周期中不断进化。最有效的产品发行既能够推进公司的目标，又能够满足客户的要求。为一个给定的项目定义产品交付标准，可以使项目组澄清当前产品和特定项目的目标。如果公司有明确的长期产品目标（遗憾的是很多公司没有），对项目组定义当前项目的目标是非常有帮助的，因为项目组知道当前他们需要解决的主要问题，同时可以预见到产品的下一站在何处。
一旦每个人对公司和客户对产品的期望都能非常清楚， 质量要素的优先级选择就是水到渠成的事情了。项目经理必须选择正确的质量标准和交付标准，用可测量的目标定义这些标准，并在在项目进行过程中持续的测量目标的实现情况。
在项目开始的时候，根据产品当前所在生命周期的阶段，决定产品质量因素的优先级是必要的。项目经理必须根据能够创造最大客户价值来设定交付需求，包括功能特性、承诺的交付日期和产品的缺陷水平。一旦项目经理将注意力聚焦到项目目标上，就有可能保证项目始终沿着正确的方向稳步前进