7.2验收报告

较多公司的验收报告是市场部或管理层处理，项目经理只需关注项目是否被验收，并积极听取客户的反馈，这个时期的反馈量是一个高峰期，较多人对于负面意见有反抗或找理由解释的心理，一段时间后，回头看这些反馈，有些是很有道理和建设性的尽管它们跟技术人员的想法、逻辑和习惯相逆；整理这些反馈，应用于软件的再升级或以后的类似项目中，将会加强项目管理水平、增进软件竞争力、提高客户满意度、用户界面更加友好、模块的商业逻辑更加合理和完善等等。有用的反馈要记录下来，写入《项目经验教训》。

7.3项目经验教训

项目经理抽出一段时间，专用于重新阅读项目的所有文档，回顾整个项目行为，列出哪些地方做对了、哪些地方尚欠缺、哪些地方考虑不周或被忽略到而产生怎样的影响（后果）等等，这对于以后的项目是珍贵和必要的。组织要将每个项目的经验教训按类别归放，在组织内公开（除机密资料外）。

8.维护阶段

软件正式被客户使用后，就进入维护阶段，除了定期监看软件的运行状态外，组织还需要对软件进行升级维护或者接受客户的维护请求（含软硬件的修改），维护需要以下两样交付物。

8.1整理维护文档

软件维护管理员不一定是项目经理，维护需要用到的文档有：《沟通计划》、《需求说明书》（若有《产品规格说明书》一并参考）、《系统设计》、《测试案例》；如果这些文档不足以支持维护，项目经理有责任丰富和修改这些文档。

8.2维护版本管理

维护版本号应该是有规律编制的，组织在这方面要有规范。维护管理员根据资源的使用情况确定维护完成时间，由此得到维护版本号，让版本管理员创建。

8.3维护步骤

跟测试阶段一样，这里假定组织有缺陷管理和跟踪系统，维护跟bug一起在该系统中处理，步骤是：

• 维护管理员在缺陷管理系统中新建维护。
• 管理层审批新维护，状态有：审批通过、取消。
• 维护管理员把已审批的维护分配给维护人员并告知版本号。
• 维护人员修复后，维护管理员做文件检查、测试（方式雷同4.3和5.2）；不合格的，通知维护人员再修改；合格的，维护人员把文件放入版本控制器。
• 维护管理员把维护版本号中的文件并入主干中，安排人员到客户处实施最新修改。

• 后记

  以上交付物是最基本的项目保证，如果项目要做得更好更顺，交付物不止这些。概括言之是，基于历史项目、组织和客户特征，把一切可预见的事情提前规划和准备资源，这样项目就会水到渠成，无惊无险。

  借用LordKelvin的一段话作为本文的结束语：当你能够测度你所说的并将其用数字表达出来，你就对它有了一些了解，但当你不能测度，不能用数字表达它时，你对它的了解就很贫乏、很不令人满意：它可能是知识的开始，但你在思想上还远没有进入科学的阶段。

  （完）

  作者：林佩雯

  • 
  • 
  • 
  •