从项目交接看项目文档管理

1、从项目交接看项目文档管理项目文档对于项目管理的作用已经不用再讲了，但文档的管理却又通常是项目管理中最简单忽视的内容。实际对于任何一个项目而言，文档一定要有的，但不一定要多，只要可以说明问题就行了。 最近正在接手一个项目，就以此项目为例， ，说一下我的体会。这个项目已经开发完成，并且已经上线运行，具备了一定的客户群体。接手这个项目时，此项目只有成果，没有过程。仅有一份完整的用户手册。 针对此状况，提出要求，需补充以下文档： 一、成果说明文档：需说明当前全部可提交成果、成果内容描述及成果评估。 成果描述至少需要描述以下内容： 1)成果存在形式及现状：针对软件项目而言，基本上成果都是以可运行代码形式

2、存在，但在此一定要明确说明代码的现状，是否经过测试，假如经过测试，需提交相关的测试报告，假如没有经过测试，那是否已经完成，完成后，假如未完成则进行到什么程度，尤其是假如没有注释的代码，应明确交代代码实现的功能描述及接口描述。 2)成果研发过程说明：主要说明成果的追溯过程，此代码从何而来，是否具备相应的计划内容，假如没有，这成果的上一个环节是什么，以代码为例，代码上一个环节是否有设计，设计上一个环节是否有需求分析等等。这部分代码是依据什么来进行的研发。假如某个成果没有追溯到最初环节，就需要留意了，这部分内容就是风险了。 3)成果可用性说明：并不是最终提交的成果就一定是有效、可用的。或许会隐蔽许多

3、的问题，这需要任务的相关担当人进行可用性描述，我们作编码的都知道，在特定的状况下，可能会采用一种临时方案去实现一个功能，等最终集成时再去修正，但许多状况下这种临时方案都成为了最终方案。所以，一定要对成果进行有效性说明，假如没有的，就一定要进行严格的测试验收。 4)成果责任人说明：一定要有，不是追究责任，而是便于沟通。 文档制作说明： 此文档建议采用表格进行说明，假如可以建议采用Excel，这样便于使用跟踪管理，如下： 二、计划管理说明文档：假如有完整的Porject计划是最好的，但此文档一定要留意的是其精确性，在用Project进行计划管理时，往往是项目进展时间越长，变更越多，计划维护就越困难

4、，此时就有可能计划已经无法反应实际的项目进展状况了。计划管理文档一定要认真研究，整个项目计划是否支配妥当，哪些任务制定了但没有完成，哪些任务取消了，这些取消的任务是否是属于预定的功能要求，哪些环节就没有进行，哪些环节多次重复，有哪些人员工作过程中发生了任务的中断变化，都可以从计划管理说明文档看出，这样更有利于评估项目的实际状况，风险状况，并可以依据前阶段未完善的内容进行后续完善。同时，很关键的一点是，这些任务中是否存在非正常状况，譬如：你认为很难的技术研发工作在短时间内却已经完成，这都需要留意，并了解实际状况。最终通过计划管理说明确文档定是否预定的目标已经全部完成。而已经完成的内容应当和以上提

5、交的成果说明是全都的，此部分假如不存在文档，就需要依据相应的成果内容及人员对整个过程进行文档补充。此文档完成后，也可成为后续管理的一个基础，进行优化处理。 假如没有计划管理文档的话，补充的时候，则建议采用Project来完成，前一个成果提交文档，并且最好可以采用WBS来组织任务的支配，将已经提交的对应到相应的任务中。通过前一文档状态的说明，将未完成的内容做标记，并且看是否存在同样的任务不同的成果表现形式的状况，这时应当是属于重复性任务，也做标记说明。 三、需求说明书：需说明产品的最初需求内容实际对于我当前接手的这个产品，需求说明书的重要性已经大大降低了，因为产品已经研发完成，且供应了完整的用户

6、手册，但整理需求说明书的主要目的还是有两个： 1、是要建立完整的项目过程追溯流程，为后续工作做预备。 2、通过需求验证成果的有效及可用性。 需求说明书是一个可简可繁的一个文档，在这个项目中，需求说明书更多的是从用户手册中来提取需求了，实际的意义并不是很大。但假如是做一个新的项目，则需求说明书应当是仅最大可能的对用户业务进行一种还原描述，不要掺杂个人的理解。至于是否可以实现，怎么实现是后续工作的事情，不是这个环节的内容。 四、系统设计说明书：系统设计说明书现在在这个时候已经无法在考虑设计的问题，但此时应当供应以下内容： 1、系统的架构设计及架构在应用过程的调整。并且最好可以供应架构的弊病分析说明

7、。 2、接口设计说明及接口的具体规格及设计说明。现在的系统基本上都是松散的，通过接口标准从而最终实现系统的集成，所以，接口部分特别关键，这部分内容一定要特别清楚和精确。 3、假如现在无法再供应设计文档，则建议通过第三方工具，依据成果代码反项生成设计，并在此基础上进行文档补充，看设计总比看代码好许多，所以，这部分内容应当进行供应。假如在新项目中，此部分内容页建议考虑，主要是规划接口调用、对象职能及对象关系。 五、数据库设计说明书 我本人还是非常重视数据库设计的，虽 虑，主要是规划接口调用、对象职能及对象关系。 五、数据库设计说明书 我本人还是非常重视数据库设计的，虽然现在有许多的DAO的工具，而

8、且也倡导对象建模，但实际在应用过程中，完全做到的 的却是少之又少，尤其是针对数据分析部分内容。所以此文档我认为还是特别重要的。至于文档的格式，因为此方面已经特别“标准”化了，就不在进行说明白。 六、测试报告 这个项目中是不需要了，假如是一个新的项目则建议由测试计划起进行。 基本上就是这么多了，应当说文档不少，但，是一个完整的流程，项目最初启动的时候，应当建立文档规范，文档不要多，但要可以对项目的每个环节都有描述说明的。我见过一个项目光需求说明就有许多份不同的文档，很头疼，而且后期的维护也会很麻烦。建议每个环节就一份统一文档。制定大家习惯的阅读方式（这点很关键，否则大家都不看），由大家共同维护完

9、成。做一总结： 需求说明文档：建议先将需求进行分解，然后用表格进行说明。假如条件允许，那就用RequisitePro管理需求，实现跟踪。 系统分析设计文档：建议采用Rose，需求用例一定要有，哪怕颗粒度大一些，在需求用例部分进行需求分析的说明，而且要说明规格要求。组件及类图一定要有，规范接口调用规则，组织代码结构，建立良好的系统框架。其中说明组件或类职能。此部分不一定完全由设计人员完成。有可能的状况下，供应活动图。程序员对活动图的兴趣要高于时序和状态图。可以用SoDA产生相应文档（只读）供开发查询使用。不一定一个Rose文件，可以多个，假如要拆分，对应需求拆分。 数据库说明书：建议用PD，然后自动生成文档（只读），供开发查询使用。 测试报告：可以用测试报告对成果进行说