综合管理：从项目交接看项目文档管理

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

二、《计划管理说明文档》：如果有完整的Porject计划是的，但此文档一定要注意的是其准确性，在用Project进行计划管理时，往往是项目进展时间越长，变更越多，计划维护就越困难，此时就有可能计划已经无法反应实际的项目进展情况了。计划管理文档一定要仔细研究，整个项目计划是否安排妥当，哪些任务制定了但没有完成，哪些任务取消了，这些取消的任务是否是属于预定的功能要求，哪些环节就没有进行，哪些环节多次重复，有哪些人员工作过程中发生了任务的中断变化，都可以从计划管理说明文档看出，这样更有利于评估项目的实际情况，风险情况，并可以根据前阶段未完善的内容进行后续完善。同时，很关键的一点是，这些任务中是否存在非正常情况，譬如：你认为很难的技术研发工作在短时间内却已经完成，这都需要注意，并了解实际情况。最终通过计划管理说明确文档定是否预定的目标已经全部完成。而已经完成的内容应该和以上提交的成果说明是一致的，此部分如果不存在文档，就需要根据相应的成果内容及人员对整个过程进行文档补充。此文档完成后，也可成为后续管理的一个基础，进行优化处理。
　　如果没有计划管理文档的话，补充的时候，则建议采用Project来完成，前一个成果提交文档，并且可以采用WBS来组织任务的安排，将已经提交的对应到相应的任务中。通过前一文档状态的说明，将未完成的内容做标记，并且看是否存在同样的任务不同的成果表现形式的情况，这时应该是属于重复性任务，也做标记说明。
　　三、《需求说明书》：需说明产品的最初需求内容实际对于我当前接手的这个产品，需求说明书的重要性已经大大降低了，因为产品已经研发完成，且提供了完整的用户手册，但整理需求说明书的主要目的还是有两个：
　　1、是要建立完整的项目过程追溯流程，为后续工作做准备。
　　2、通过需求验证成果的有效及可用性。
　　需求说明书是一个可简可繁的一个文档，在这个项目中，需求说明书更多的是从用户手册中来提取需求了，实际的意义并不是很大。但如果是做一个新的项目，则需求说明书应该是仅可能的对用户业务进行一种还原描述，不要掺杂个人的理解。至于是否可以实现，怎么实现是后续工作的事情，不是这个环节的内容。
　　四、《系统设计说明书》：系统设计说明书现在在这个时候已经无法在考虑设计的问题，但此时应该提供以下内容：
　　1、系统的架构设计及架构在应用过程的调整。并且可以提供架构的弊病分析说明。
　　2、接口设计说明及接口的详细规格及设计说明。现在的系统基本上都是松散的，通过接口标准从而最终实现系统的集成，所以，接口部分非常关键，这部分内容一定要非常清晰和准确。
　　3、如果现在无法再提供设计文档，则建议通过第三方工具，根据成果代码反项生成设计，并在此基础上进行文档补充，看设计总比看代码好很多，所以，这部分内容应该进行提供。如果在新项目中，此部分内容页建议考虑，主要是规划接口调用、对象职能及对象关系。
　　五、《数据库设计说明书》
　　我本人还是十分重视数据库设计的，虽然现在有很多的DAO的工具，而且也倡导对象建模，但实际在应用过程中，完全做到的却是少之又少，尤其是针对数据分析部分内容。所以此文档我认为还是非常重要的。至于文档的格式，因为此方面已经非常“标准”化了，就不在进行说明了。
六、《测试报告》
　　这个项目中是不需要了，如果是一个新的项目则建议由测试计划起进行。
　　基本上就是这么多了，应该说文档不少，但，是一个完整的流程，项目最初启动的时候，应该建立文档规范，文档不要多，但要可以对项目的每个环节都有描述说明的。我见过一个项目光需求说明就有很多份不同的文档，很头疼，而且后期的维护也会很麻烦。建议每个环节就一份统一文档。制定大家习惯的阅读方式（这点很关键，否则大家都不看），由大家共同维护完成。做一总结：
　　《需求说明文档》：建议先将需求进行分解，然后用表格进行说明。如果条件允许，那就用RequisitePro管理需求，实现跟踪。
　　《系统分析设计文档》：建议采用Rose，需求用例一定要有，哪怕颗粒度大一些，在需求用例部分进行需求分析的说明，而且要说明规格要求。组件及类图一定要有，规范接口调用规则，组织代码结构，建立良好的系统框架。其中说明组件或类职能。此部分不一定完全由设计人员完成。有可能的情况下，提供活动图。程序员对活动图的兴趣要高于时序和状态图。可以用SoDA产生相应文档（只读）供开发查询使用。不一定一个Rose文件，可以多个，如果要拆分，对应需求拆分。
　　《数据库说明书》：建议用PD，然后自动生成文档（只读），供开发查询使用。
　　《测试报告》：可以用测试报告对成果进行说明，但我个人感觉《测试计划》比《测试报告》更重要，因为没有一个好的测试计划进行指导，最终测试也就成为了一个成果描述环节了。
　　其中，建议使用Project进行项目计划管理，可以用Projectserver来进行跟踪，这样联工作日志也可以省略了。
　　采用版本工具进行文档管理，一定要，非常重要。文档在项目管理中的作用无需多言，但文档管理通常是项目管理中最容易被忽视的内容。其实对于任何一个项目来说，文档肯定是有的，但不多，只要能说明问题就行。
最近，我在接手一个项目。以这个项目为例，说说我的体会。该项目已经开发并投入运营，拥有一定的客户群。我接手这个项目的时候，这个项目只有成果，没有过程。只有一本完整的用户手册。
鉴于这种情况，需要补充以下文件:
1。“成果说明文件”:需要说明所有当前可提交的成果、成果说明和成果评价。
结果的描述至少要描述以下内容:
1)结果的存在形式和现状:对于软件项目来说，基本上结果都是以可运行代码的形式出现的，但是在这里，需要明确的陈述代码的现状，是否经过测试，如果经过测试，需要提交相关的测试报告，如果没有经过测试，是否已经完成，没有完成到什么程度。
2)成果的R&D过程描述:主要说明成果的追溯过程，这段代码从何而来，是否有相应的计划内容，如果没有，这段成果的最后一个环节是什么，以代码为例，代码的最后一个环节是否有设计，设计的最后一个环节是否有需求分析等。这部分代码是基于什么？如果某项成果没有追溯到最初的环节，就要引起重视。这部分就是风险。
3)结果的可用性:最终提交的结果不一定有效可用。可能会有很多隐藏的问题，需要任务的相关承担者来描述可用性。我们都知道，在一定的情况下，可能会采用临时方案来实现一个功能，然后在最终集成之后再进行修正，但是很多时候，这个临时方案就变成了最终方案。因此，有必要说明结果的有效性。如果没有，就要进行严格的测试和验收。
4)对成就负责人的描述:必须有，不是为了追究责任，而是为了方便沟通。
文档描述:
本文档建议使用表格进行描述。如果可以建议使用Excel，使用跟踪管理比较方便，如下:

二。计划管理的文档化描述:如果有完整的项目计划，那是真的，但是这个文档一定要注意它的准确性。当使用项目进行计划管理时，通常必须仔细研究管理文档。整个项目计划安排是否得当，哪些任务已经制定但没有完成，哪些任务被取消，这些取消的任务是否属于预定的功能需求，哪些环节没有进行，哪些环节重复了多次，哪些人员在工作过程中中断了任务，这些都可以从计划管理说明文件中看到。这样更有利于评估项目的实际情况和风险情况，并可以根据前一阶段不完整的内容进行后续改进。同时，了解这些任务中是否存在异常情况也是至关重要的，比如短时间内完成了你认为很难的技术研发，这就需要关注和了解实际情况。通过最终计划管理，明确文件设定的预定目标是否全部完成。并且完成的内容应与上述结果一致。如果这部分没有文档，需要根据相应的结果和人员进行全过程的补充。这个文档完成后，也可以作为后续管理的基础，进行优化。
如果没有计划管理文档，建议使用Project完成补充。之前的成果要提交文档，可以用WBS来组织任务安排，提交的要对应相应的任务。通过对之前文档状态的描述，标注未完成的内容，看看同样的任务是否有不同的结果。这个时候应该是一个重复性的任务，也要做标记。
三。需求手册:需要解释产品的初始需求。其实对于我目前接手的产品来说，需求手册的重要性已经大大降低了，因为产品已经开发出来，提供了完整的用户手册。但是整理需求手册还是有两个主要目的:
1。建立完整的项目过程跟踪流程，为后续工作做准备。
2。通过需求验证结果的有效性和可用性。
需求规格说明书是一个可以简化但又很复杂的文档。在这个项目中，需求说明书更多的是从用户手册中提取需求，实际意义并不大。但如果是新项目，需求说明书应该只是对用户业务可能的描述，没有个人理解。至于能不能实现，怎么实现是后续工作的事情，不是这个环节的内容。
四。系统设计手册:系统设计手册此时不能考虑设计问题，但此时应提供以下内容:
1。系统架构设计和应用过程中架构的调整。并且可以解释该体系结构的缺点。
2。接口的设计说明，接口的详细规格和设计说明。现在的系统基本都是松散的，系统的集成最终是通过接口标准来实现的。所以界面部分非常关键，这部分一定要非常清晰准确。
3。如果现在无法提供设计文档，建议使用第三方工具根据产品代码生成设计，并在此基础上补充文档。看设计比看代码好多了，所以这部分要提供。如果是新项目，这部分内容页建议考虑，主要是规划接口调用、对象函数和对象关系。
五、数据库设计说明
我还是很重视数据库设计的。虽然有许多DAO工具，并且提倡对象建模，但在实践中，很少能完全实现，尤其是对于数据分析。所以我觉得这个文件还是很重要的。至于文件的格式，因为这方面已经很“规范”了，就不解释了。六。“测试报告”
在本项目中是不必要的。如果是新项目，建议从测试计划开始。
基本上就这些了。应该说文件不少，但是是一个完整的流程。当项目开始时，应该建立文档规范。文档不多，但应该能描述项目的每个环节。我见过一个项目，光是需求规格就有很多不同的文档，很头疼，后期维护也会很麻烦。建议每个环节都要有统一的文件。做出大家都习惯的阅读风格(这个很关键，不然大家都不看)，大家一起维持。做个总结:
“需求描述文档”:建议先分解需求，再用表格解释。如果条件允许，那么使用RequisitePro来管理需求，实现跟踪。
系统分析与设计文档:推荐Rose，一定要有需求案例，哪怕粒度再大。需求案例部分要解释需求分析，要陈述规格需求。必须有组件图，标准的接口调用规则，组织代码结构，建立良好的系统框架。其中描述了组件或类功能。这部分不一定是设计师完成的。如果可能，提供活动图。程序员对活动图比对时序和状态图更感兴趣。您可以使用SoDA为开发查询生成相应的文档(只读)。玫瑰档案不一定只有一个，可以不止一个。要拆就按要求拆。
数据库说明:建议使用PD，然后自动生成一个文档(只读)用于开发和查询。
测试报告:可以用测试报告来说明结果，但是个人感觉测试计划比测试报告更重要，因为没有一个好的测试计划来指导，最终的测试就变成了描述结果的一部分。
其中，项目计划管理建议使用Project，跟踪可以使用Projectserver，这样关联的工作日志也可以省略。
使用版本工具进行文档管理是必要的，也是非常重要的。