在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。检查清单用于确认作业或工程是否存在遗漏。模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。

软件开发项目管理检查清单：天气晴雨表

检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。

需求式样晴雨表

• 是否存在稳定的、完整的、书面的需求式样？

• 是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？

• 是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？

• 是否为了确认顾客的需求而对“需求式样书”进行了审查？

• 是否根据顾客提供的产品式样书而直接进入了设计作业？

• 是否在作业途中不断变更或追加需求式样？

• 是否按照项目编号规则对每项需求赋予了惟一的编号？

• 是否已经明确顾客方的项目推进体制以及最终决策者？

• 是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？

• 是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？

• 是否在作业已经进入测试阶段后还发现需求式样理解有误？

• 是否以单一窗口接收顾客的需求，确保一窗口输入？

• 项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？

项目计划晴雨表

• 是否将估算视为一种特殊的技能，并将估算当作一个小项目？

• 是否定期对项目计划实施重新估算并根据实际情况加以调整？

• 是否对作业文档等成果物的“量”进行了估计？

• 是否以适当的单位进行了作业量的估计？

• 项目作业是否具有详细的日程表？

• 日程表确定之后，如果和实际情况出入较大，是否进行了调整？

• 是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？

• “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？

• 是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？

团队管理晴雨表

• 是否存在明确的软件开发行动单位：团队？

• 是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？
• 管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？

• 项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？

• 项目管理者是否总是认为项目没有什么值得注意的问题？

• 团队成员是否知道项目作业内容的相互关系及其优先级？

• 是否在项目启动之后仍然还有项目组成员感到无所事事？

• 是否经常有特定的项目组成员总是加班到深夜？

• 团队成员是否知道并遵守统一的作业规范？

• 是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？

• 团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？

• 当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？

• 项目组成员的出勤时间是否经常相差很大而不寻找原因？

• 项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？

• 项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？

作业流程晴雨表

• 是否存在专注于组织整体的开发作业和项目流程的人或者小组？

• 是否存在项目开发作业的标准作业流程？

• 是否存在记述顾客需求式样的文档标准？

• 是否存在设计书的文档标准？

• 是否不经过设计阶段而直接进入编码阶段？

• 设计阶段是否实施了以设计为对象的审查？

• 编码阶段是否实施了以代码为对象的审查？

• 中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？

• 是否未经单体测试就直接开始综合测试？

• 是否时至最后才发现此前隐藏的诸多问题？

• 是否无视已经发现的问题而继续推进作业？

• 是否多次重复出现以前相同的错误而没有吸取教训？

• 是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？

• 对式样需求是否确立了适当的测试项目？

• 测试是否几乎没有自动化手段？

• 过程改善方面是否存在可以商量和咨询的人员？

• 是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？

【 发表评论 0条 】