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

文档在项目管理中的作用无需多言，但文档管理通常是项目管理中最容易被忽视的内容。其实对于任何一个项目来说，文档肯定是有的，但不多，只要能说明问题就行。
最近，我在接手一个项目。以这个项目为例，说说我的体会。该项目已经开发并投入运营，拥有一定的客户群。我接手这个项目的时候，这个项目只有成果，没有过程。只有一本完整的用户手册。
鉴于这种情况，需要补充以下文件:
1。“成果说明文件”:需要说明所有当前可提交的成果、成果说明和成果评价。
结果的描述至少要描述以下内容:
1)结果的存在形式和现状:对于软件项目来说，基本上结果都是以可运行代码的形式出现的，但是在这里，需要明确的陈述代码的现状，是否经过测试，如果经过测试，需要提交相关的测试报告，如果没有经过测试，是否已经完成，没有完成到什么程度。
2)成果的R&D过程描述:主要说明成果的追溯过程，这段代码从何而来，是否有相应的计划内容，如果没有，这段成果的最后一个环节是什么，以代码为例，代码的最后一个环节是否有设计，设计的最后一个环节是否有需求分析等。这部分代码是基于什么？如果某项成果没有追溯到最初的环节，就要引起重视。这部分就是风险。
3)结果的可用性:最终提交的结果不一定有效可用。可能会有很多隐藏的问题，需要任务的相关承担者来描述可用性。我们都知道，在一定的情况下，可能会采用临时方案来实现一个功能，然后在最终集成之后再进行修正，但是很多时候，这个临时方案就变成了最终方案。因此，有必要说明结果的有效性。如果没有，就要进行严格的测试和验收。
4)对成就负责人的描述:必须有，不是为了追究责任，而是为了方便沟通。
文档描述:本文档建议使用表格进行描述。如果能使用Excel，使用跟踪管理很方便，如下:

二。计划管理的文档化:如果有完整的项目计划，就要注意其准确性。当使用Project进行计划管理时，项目进行的时间越长，更改就越多。
必须认真学习计划管理文件。整个项目计划是否安排得当，哪些任务已经做了但没有完成，哪些任务被取消了，这些取消的任务是否属于预定的功能需求，哪些环节没有进行，哪些环节重复了很多次，哪些人员在工作过程中被打断和变更，这些都可以从计划管理指令文件中看到，更有利于评估项目的实际情况和风险情况，可以基于前一阶段不完整的信息，同时，了解这些任务中是否存在异常情况也是至关重要的，比如短时间内完成了你认为很难的技术研发，这就需要关注和了解实际情况。通过最终计划管理，明确文件设定的预定目标是否全部完成。并且完成的内容应与上述结果一致。如果这部分没有文档，需要根据相应的结果和人员进行全过程的补充。这个文档完成后，也可以作为后续管理的基础，进行优化。
如果没有计划管理文档，建议使用Project完成补充。之前的成果要提交到文档中，可以用WBS来组织任务安排，将提交的任务映射到相应的任务上。通过对之前文档状态的描述，标注未完成的内容，看看同样的任务是否有不同的结果。这个时候应该是一个重复性的任务，也要做标记。