项目文档对于项目管理的作用已经不用再讲了,但文档的管理却又通常是项目管理中最容易忽略的内容。实际对于任何一个项目而言,文档一定要有的,但不一定要多,只要可以说明问题就行了。
最近正在接手一个项目,就以此项目为例,说一下我的体会。这个项目已经开发完成,并且已经上线运行,具备了一定的客户群体。接手这个项目时,此项目只有成果,没有过程。仅有一份完整的用户手册。
针对此情况,提出要求,需补充以下文档:
一、《成果说明文档》:需说明当前所有可提交成果,、成果内容描述及成果评估。成果描述至少需要描述以下内容:
1) 成果存在形式及现状:针对软件项目而言,基本上成果都是以可运行代码形式存在,但在此一定要明确说明代码的现状,是否经过测试,如果经过测试,需提交相关的测试报告,如果没有经过测试,那是否已经完成,完成后,如果未完成则进行到什么程度,尤其是如果没有注释的代码,应明确交代代码实现的功能描述及接口描述。
2) 成果研发过程说明:主要说明成果的追溯过程,此代码从何而来,是否具备相应的计划内容,如果没有,这成果的上一个环节是什么,以代码为例,代码上一个环节是否有设计,设计上一个环节是否有需求分析等等。这部分代码是根据什么来进行的研发。如果某个成果没有追溯到最初环节,就需要注意了,这部分内容就是风险了。
3) 成果可用性说明:并不是最终提交的成果就一定是有效、可用的。也许会隐藏很多的问题,这需要任务的相关承担人进行可用性描述,我们作编码的都知道,在特定的情况下,可能会采用一种临时方案去实现一个功能,等最终集成时再去修正,但很多情况下这种临时方案都成为了最终方案。所以,一定要对成果进行有效性说明,如果没有的,就一定要进行严格的测试验收。
4) 成果责任人说明:一定要有,不是追究责任,而是便于沟通。
文档制作说明:
此文档建议采用表格进行说明,如果可以建议采用Excel,这样便于使用跟踪管理,如下:
提交成果 | 类型 | 存在地址 | 当前状态 | 最终评估 |
描述可提交成果内容 譬如:××单元设计文档 ××模块源代码 | 代码 文档 设计文件 | 当前存放地址 | 完成且使用 完成未使用 未完成 取消 | 可用且过程完整 可用仅成果 可用部分过程 提交不可用 未提交 未完成 |
订单自动生成模块 | VB代码 | VSS\sourcecontrol\Order | 完成且使用 | 可用部分成果 具备需求文档无设计文档 |
订单表单 | 文档(需求原始资料) | 无电子版,保管人员:××× | 完成且使用 | 可用且过程完整 |