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

作/转载者:一孑(feiw)  

  项目文档对于项目管理的作用已经不用再讲了,但文档的管理却又通常是项目管理中最容易忽略的内容。实际对于任何一个项目而言,文档一定要有的,但不一定要多,只要可以说明问题就行了。

  最近正在接手一个项目,就以此项目为例,说一下我的体会。这个项目已经开发完成,并且已经上线运行,具备了一定的客户群体。接手这个项目时,此项目只有成果,没有过程。仅有一份完整的用户手册。

  针对此情况,提出要求,需补充以下文档:
  一、《成果说明文档》:
  需说明当前所有可提交成果、成果内容描述及成果评估。
  成果描述至少需要描述以下内容:

  1) 成果存在形式及现状:针对软件项目而言,基本上成果都是以可运行代码形式存在,但在此一定要明确说明代码的现状,是否经过测试,如果经过测试,需提交相关的测试报告,如果没有经过测试,那是否已经完成,完成后,如果未完成则进行到什么程度,尤其是如果没有注释的代码,应明确交代代码实现的功能描述及接口描述。

  2) 成果研发过程说明:主要说明成果的追溯过程,此代码从何而来,是否具备相应的计划内容,如果没有,这成果的上一个环节是什么,以代码为例,代码上一个环节是否有设计,设计上一个环节是否有需求分析等等。这部分代码是根据什么来进行的研发。如果某个成果没有追溯到最初环节,就需要注意了,这部分内容就是风险了。

  3) 成果可用性说明:并不是最终提交的成果就一定是有效、可用的。也许会隐藏很多的问题,这需要任务的相关承担人进行可用性描述,我们作编码的都知道,在特定的情况下,可能会采用一种临时方案去实现一个功能,等最终集成时再去修正,但很多情况下这种临时方案都成为了最终方案。所以,一定要对成果进行有效性说明,如果没有的,就一定要进行严格的测试验收。

  4) 成果责任人说明:一定要有,不是追究责任,而是便于沟通。

  文档制作说明:

  此文档建议采用表格进行说明,如果可以建议采用Excel,这样便于使用跟踪管理,如下:


  二、《计划管理说明文档》:
  如果有完整的Porject计划是最好的,但此文档一定要注意的是其准确性,在用Project进行计划管理时,往往是项目进展时间越长,变更越多,计划维护就越困难,此时就有可能计划已经无法反应实际的项目进展情况了。计划管理文档一定要仔细研究,整个项目计划是否安排妥当,哪些任务制定了但没有完成,哪些任务取消了,这些取消的任务是否是属于预定的功能要求,哪些环节就没有进行,哪些环节多次重复,有哪些人员工作过程中发生了任务的中断变化,都可以从计划管理说明文档看出,这样更有利于评估项目的实际情况,风险情况,并可以根据前阶段未完善的内容进行后续完善。同时,很关键的一点是,这些任务中是否存在非正常情况,譬如:你认为很难的技术研发工作在短时间内却已经完成,这都需要注意,并了解实际情况。最终通过计划管理说明确文档定是否预定的目标已经全部完成。而已经完成的内容应该和以上提交的成果说明是一致的,此部分如果不存在文档,就需要根据相应的成果内容及人员对整个过程进行文档补充。此文档完成后,也可成为后续管理的一个基础,进行优化处理。

  如果没有计划管理文档的话,补充的时候,则建议采用Project来完成,前一个成果提交文档,并且最好可以采用WBS来组织任务的安排,将已经提交的对应到相应的任务中。通过前一文档状态的说明,将未完成的内容做标记,并且看是否存在同样的任务不同的成果表现形式的情况,这时应该是属于重复性任务,也做标记说明。
  三、《需求说明书》:
  需说明产品的最初需求内容实际对于我当前接手的这个产品,需求说明书的重要性已经大大降低了,因为产品已经研发完成,且提供了完整的用户手册,但整理需求说明书的主要目的还是有两个:

  1、是要建立完整的项目过程追溯流程,为后续工作做准备。

  2、通过需求验证成果的有效及可用性。

  需求说明书是一个可简可繁的一个文档,在这个项目中,需求说明书更多的是从用户手册中来提取需求了,实际的意义并不是很大。但如果是做一个新的项目,则需求说明书应该是仅最大可能的对用户业务进行一种还原描述,不要掺杂个人的理解。至于是否可以实现,怎么实现是后续工作的事情,不是这个环节的内容。
  四、《系统设计说明书》:
  系统设计说明书现在在这个时候已经无法在考虑设计的问题,但此时应该提供以下内容:

  1、系统的架构设计及架构在应用过程的调整。并且最好可以提供架构的弊病分析说明。

  2、接口设计说明及接口的详细规格及设计说明。现在的系统基本上都是松散的,通过接口标准从而最终实现系统的集成,所以,接口部分非常关键,这部分内容一定要非常清晰和准确。

  3、如果现在无法再提供设计文档,则建议通过第三方工具,根据成果代码反项生成设计,并在此基础上进行文档补充,看设计总比看代码好很多,所以,这部分内容应该进行提供。如果在新项目中,此部分内容页建议考虑,主要是规划接口调用、对象职能及对象关系。
  五、《数据库设计说明书》
  我本人还是十分重视数据库设计的,虽然现在有很多的DAO的工具,而且也倡导对象建模,但实际在应用过程中,完全做到的却是少之又少,尤其是针对数据分析部分内容。所以此文档我认为还是非常重要的。至于文档的格式,因为此方面已经非常“标准”化了,就不在进行说明了。
  六、《测试报告》
  这个项目中是不需要了,如果是一个新的项目则建议由测试计划起进行。

  基本上就是这么多了,应该说文档不少,但,是一个完整的流程,项目最初启动的时候,应该建立文档规范,文档不要多,但要可以对项目的每个环节都有描述说明的。我见过一个项目光需求说明就有很多份不同的文档,很头疼,而且后期的维护也会很麻烦。建议每个环节就一份统一文档。制定大家习惯的阅读方式(这点很关键,否则大家都不看),由大家共同维护完成。做一总结:

  《需求说明文档》:建议先将需求进行分解,然后用表格进行说明。如果条件允许,那就用RequisitePro管理需求,实现跟踪。

  《系统分析设计文档》:建议采用Rose,需求用例一定要有,哪怕颗粒度大一些,在需求用例部分进行需求分析的说明,而且要说明规格要求。组件及类图一定要有,规范接口调用规则,组织代码结构,建立良好的系统框架。其中说明组件或类职能。此部分不一定完全由设计人员完成。有可能的情况下,提供活动图。程序员对活动图的兴趣要高于时序和状态图。可以用SoDA产生相应文档(只读)供开发查询使用。不一定一个Rose文件,可以多个,如果要拆分,对应需求拆分。

  《数据库说明书》:建议用PD,然后自动生成文档(只读),供开发查询使用。

  《测试报告》:可以用测试报告对成果进行说明,但我个人感觉《测试计划》比《测试报告》更重要,因为没有一个好的测试计划进行指导,最终测试也就成为了一个成果描述环节了。

  其中,建议使用Project进行项目计划管理,最好可以用Projectserver来进行跟踪,这样联工作日志也可以省略了。

  采用版本工具进行文档管理,一定要,非常重要。