7. 发布阶段
7.1 培训准备检查表
如果有培训，工程部人员出《培训准备检查表》，它确保培训所需的硬件、软件、材料、人员都准备就绪，以免误漏。例子见表9：
类型 |
事项 |
实施者 |
是否到位 |
硬件 |
Web服务器 |
[姓名] |
□是 □否 □不需要 |
外部硬件设备（紫光笔、加密狗等等） |
[姓名] |
□是 □否 □不需要 |
讲师笔记本/电脑 |
[姓名] |
□是 □否 □不需要 |
投影仪 |
[姓名] |
□是 □否 □不需要 |
软件 |
系统软件代码部署 |
[姓名] |
□是 □否 □不需要 |
外部软件插件1 |
[姓名] |
□是 □否 □不需要 |
材料 |
主讲师 |
[姓名] |
□是 □否 □不需要 |
培训文档 |
[姓名] |
□是 □否 □不需要 |
培训过程速记员 |
[姓名] |
□是 □否 □不需要 |
系统调查反馈表 |
[姓名] |
□是 □否 □不需要 |
表 9
7.2 验收报告
较多公司的验收报告是市场部或管理层处理，项目经理只需关注项目是否被验收，并积极听取客户的反馈，这个时期的反馈量是一个高峰期，较多人对于负面意见有反抗或找理由解释的心理，一段时间后，回头看这些反馈，有些是很有道理和建设性的——尽管它们跟技术人员的想法、逻辑和习惯相逆；整理这些反馈，应用于软件的再升级或以后的类似项目中，将会加强项目管理水平、增进软件竞争力、提高客户满意度、用户界面更加友好、模块的商业逻辑更加合理和完善等等。有用的反馈要记录下来，写入《项目经验教训》。
7.3 项目经验教训
项目经理抽出一段时间，专用于重新阅读项目的所有文档，回顾整个项目行为，列出哪些地方做对了、哪些地方尚欠缺、哪些地方考虑不周或被忽略到而产生怎样的影响（后果）等等，这对于以后的项目是珍贵和必要的。组织要将每个项目的经验教训按类别归放，在组织内公开（除机密资料外）。
8. 维护阶段
软件正式被客户使用后，就进入维护阶段，除了定期监看软件的运行状态外，组织还需要对软件进行升级维护或者接受客户的维护请求（含软硬件的修改），维护需要以下两样交付物。
8.1 整理维护文档
软件维护管理员不一定是项目经理，维护需要用到的文档有：《沟通计划》、《需求说明书》（若有《产品规格说明书》一并参考）、《系统设计》、《测试案例》；如果这些文档不足以支持维护，项目经理有责任丰富和修改这些文档。
8.2 维护版本管理
维护版本号应该是有规律编制的，组织在这方面要有规范。维护管理员根据资源的使用情况确定维护完成时间，由此得到维护版本号，让版本管理员创建。
8.3 维护步骤
跟测试阶段一样，这里假定组织有缺陷管理和跟踪系统，维护跟bug一起在该系统中处理，步骤是：
- 维护管理员在缺陷管理系统中新建维护。
- 管理层审批新维护，状态有：审批通过、取消。
- 维护管理员把已审批的维护分配给维护人员并告知版本号。
- 维护人员修复后，维护管理员做文件检查、测试（方式雷同4.3和5.2）；不合格的，通知维护人员再修改；合格的，维护人员把文件放入版本控制器。
- 维护管理员把维护版本号中的文件并入主干中，安排人员到客户处实施最新修改。
后记
以上交付物是最基本的项目保证，如果项目要做得更好更顺，交付物不止这些。概括言之是，基于历史项目、组织和客户特征，把一切可预见的事情提前规划和准备资源，这样项目就会水到渠成，无惊无险。
借用Lord Kelvin的一段话作为本文的结束语：“当你能够测度你所说的并将其用数字表达出来，你就对它有了一些了解，但当你不能测度，不能用数字表达它时，你对它的了解就很贫乏、很不令人满意：它可能是知识的开始，但你在思想上还远没有进入科学的阶段。”
（完）
作者：林佩雯