项目管理中文档管理的重要性.doc

这么些年来，大大小小经历了一些信息系统的实施项目，有一部分是协助别人进行项目的实施工作，有一部分是自己负责管理项目的实施工作，另外还有一部分是通过各种渠道了解的别人的项目实施工作，在这个过程中也在不断地思索一些管理方面的问题。信息系统的实施工作是纷繁复杂的，走过了这么些年，令自己欣慰的是积累了一些成功的经验，另外一个感触就是一次次发现可改进之处的欣喜和感悟，现在就将项目管理过程中本人关于文档管理的一些潜质拙见通过本文进行一个分享。在此前的关于信息系统的项目实施管理整个过程的文章中也提到过一些文档管理的内容，撰写此文的目的在于更加详实的表达我对项目管理过程中的文档管理的一些理解。文档管理的重要性一直以来，有很多的人都在说文档管理的重要性，最耳熟能详的莫过于软件项目中的人员变动以后后面的人无法识别之前的代码，或者识别的成本较高。事实情况是，就算人员不变动，时间长了，当时的编写者也不会记得当时的思路是什么，因为时间会消磨一些东西，另外每个人的想法和思维方式也在发生变化。一个项目组织在进行一些想法的沟通时，由于个人知识结构的不同、所处的地位立场不同等原因也会导致对一个想法的最终实现方案的认知上存在差异，最终落实到方案上也会有所不同，通过一个书面的文档可以将每个人的认知形成一个统一的认知，减少不必要的沟通障碍。同时明确的文档也可以给参与者更多思考的空间。为了达到一个好的沟通交流方式，我们需要各式各样的文档，在现实的项目管理过程中也确实存在了大量的文档，每个人都认为文档是重要的，但是当真正文档到来的时候又开始困扰了，会不自觉的有些厌烦和无从下手。做文档的过程是辛苦的，更是麻烦的，原来几句话的事情在有了文档以后变得异常麻烦，需要对应好格式，需要不同人员的审核和认可，难免就会觉得麻烦；而在自己做完文档以后发现可用性并不如想象中的那么高，真正想要的文档不知道到哪里去找，不同的文档说法不统一，等等诸如此类的问题让使用者有点无从下手。或许是印证了一句话，叫做事情做的没有头绪的时候就想到了管理，对于那些各式各样的文档同样不会例外。文档管理的方式 在文档管理的过程中，需要把握住一些重要的原则和方法，这样可以让我们的文档真正达到我们预期的目的。文档模板的管理面对各类纷繁复杂的文档，如果各式各样，每个人一个风格，不论从美观性和可读性上都会有影响，所以在文档管理中的过程中需要建议一套文档的模板。在建立文档模板时，需要对一些格式进行要求，需要将一些基本的要素固化到文档模板中，确保文档需要的内容能够在文档中体现，例如文档的页眉页脚、文档变更历史、文档的目录方式、文档的字体等。在建立文档时，要注意做好文档的分类，各种分类有一个清晰的定义，使用者可以清楚地知道实际使用时要采用哪种模板。如果是使用共享目录方式管理文档，需要在一个相对容易找到的文件夹目录中存放模板，如果是使用信息系统方式进行模板管理，最好能够在首页进行一个连接，或者是让使用者可以快速的搜索到。在建立分类时，需要含有一个共同类，或者叫做公用类，因为在实际的使用过程中总是会有一些新的类别出现，也会有一些无法进行分类的文档，这个时候就可以通过共同类进行管理。对于文档模板的变更需要能够做到及时告知使用者，并做好版本管理。 从项目交接看项目文档管理二级建造师考试 2008/12/3 保存本文 免费试听课程 收藏本页 Ads by Google 讯鸟-提高客户满意度助中小企业学习阿里巴巴,构建客户 满意中心,从客户电话中获取更大价值！专业制作各类标语-博尔生产制作5S,6S,7S,8S生产标语,管理 标语,欢迎订购翰纬提供ITSM专业服务经验翰纬供ITIL,ISO20000培训和咨询业务 咨询电话:400-886-8806,02133932855项目文档对于项目管理的作用已经不用再讲了，但文档的管理却又通常是项目管理中最容易忽略的内容。实际对于任何一个项目而言，文档一定要有的，但不一定要多，只要可以说明问题就行了。 最近正在接手一个项目，就以此项目为例，说一下我的体会。这个项目已经开发完成，并且已经上线运行，具备了一定的客户群体。接手这个项目时，此项目只有成果，没有过程。仅有一份完整的用户手册。 针对此情况，提出要求，需补充以下文档：一、成果说明文档：需说明当前所有可提交成果、成果内容描述及成果评估。 成果描述至少需要描述以下内容：1）成果存在形式及现状：针对软件项目而言，基本上成果都是以可运行代码形式存在，但在此一定要明确说明代码的现状，是否经过测试，如果经过测试，需提交相关的测试报告，如果没有经过测试，那是否已经完成，完成后，如果未完成则进行到什么程度，尤其是如果没有注释的代码，应明确交代代码实现的功能描述及接口描述。 2）成果研发过程说明：主要说明成果的追溯过程，此代码从何而来，是否具备相应的计划内容，如果没有，这成果的上一个环节是什么，以代码为例，代码上一个环节是否有设计，设计上一个环节是否有需求分析等等。这部分代码是根据什么来进行的研发。如果某个成果没有追溯到最初环节，就需要注意了，这部分内容就是风险了。 3）成果可用性说明：并不是最终提交的成果就一定是有效、可用的。也许会隐藏很多的问题，这需要任务的相关承担人进行可用性描述，我们作编码的都知道，在特定的情况下，可能会采用一种临时方案去实现一个功能，等最终集成时再去修正，但很多情况下这种临时方案都成为了最终方案。所以，一定要对成果进行有效性说明，如果没有的，就一定要进行严格的测试验收。 4）成果责任人说明：一定要有，不是追究责任，而是便于沟通。 文档制作说明：此文档建议采用表格进行说明，如果可以建议采用Excel，这样便于使用跟踪管理，如下：二、计划管理说明文档：如果有完整的Porject计划是最好的，但此文档一定要注意的是其准确性，在用Project进行计划管理时，往往是项目进展时间越长，变更越多，计划维护就越困难，此时就有可能计划已经无法反应实际的项目进展情况了。计划管理文档一定要仔细研究，整个项目计划是否安排妥当，哪些任务制定了但没有完成，哪些任务取消了，这些取消的任务是否是属于预定的功能要求，哪些环节就没有进行，哪些环节多次重复，有哪些人员工作过程中发生了任务的中断变化，都可以从计划管理说明文档看出，这样更有利于评估项目的实际情况，风险情况，并可以根据前阶段未完善的内容进行后续完善。同时，很关键的一点是，这些任务中是否存在非正常情况，譬如：你认为很难的技术研发工作在短时间内却已经完成，这都需要注意，并了解实际情况。最终通过计划管理说明确文档定是否预定的目标已经全部完成。而已经完成的内容应该和以上提交的成果说明是一致的，此部分如果不存在文档，就需要根据相应的成果内容及人员对整个过程进行文档补充。此文档完成后，也可成为后续管理的一个基础，进行优化处理。 如果没有计划管理文档的话，补充的时候，则建议采用Project来完成，前一个成果提交文档，并且最好可以采用WBS来组织任务的安排，将已经提交的对应到相的任务中。通过前一文档状态的说明，将未完成的内容做标记，并且看是否存在同样的任务不同的成果表现形式的情况，这时应该是属于重复性任务，也做标记说明。 转贴于：二级建造师考试_考试大【责编:sf纠错】三、需求说明书：需说明产品的最初需求内容实际对于我当前接手的这个产品，需求说明书的重要性已经大大降低了，因为产品已经研发完成，且提供了完整的用户手册，但整理需求说明书的主要目的还是有两个：1、是要建立完整的项目过程追溯流程，为后续工作做准备。 2、通过需求验证成果的有效及可用性。 需求说明书是一个可简可繁的一个文档，在这个项目中，需求说明书更多的是从用户手册中来提取需求了，实际的意义并不是很大。但如果是做一个新的项目，则需求说明书应该是仅最大可能的对用户业务进行一种还原描述，不要掺杂个人的理解。至于是否可以实现，怎么实现是后续工作的事情，不是这个环节的内容。 四、系统设计说明书：系统设计说明书现在在这个时候已经无法在考虑设计的问题，但此时应该提供以下内容：1、系统的架构设计及架构在应用过程的调整。并且最好可以提供架构的弊病分析说明。 2、接口设计说明及接口的详细规格及设计说明。现在的系统基本上都是松散的，通过接口标准从而最终实现系统的集成，所以，接口部分非常关键，这部分内容一定要非常清晰和准确。 3、如果现在无法再提供设计文档，则建议通过第三方工具，根据成果代码反项生成设计，并在此基础上进行文档补充，看设计总比看代码好很多，所以，这部分内容应该进行提供。如果在新项目中，此部分内容页建议考虑，主要是规划接口调用、对象职能及对象关系。 五、数据库设计说明书我本人还是十分重视数据库设计的，虽虑，主要是规划接口调用、对象职能及对象关系。数据库设计说明书我本人还是十分重视数据库设计的，虽然现在有很多的DAO的工具，而且也倡导对象建模，但实际在应用过程中，完全做到的的却是少之又少，尤其是针对数据分析部分内容。所以此文档我认为还是非常重要的。至于文档的格式，因为此方面已经非常“标准”化了，就不在进行说明了。 六、测试报告这个项目中是不需要了，如果是一个新的项目则建议由测试计划起进行。 基本上就是这么多了，应该说文档不少，但，是一个完整的流程，项目最初启动的时候，应该建立文档规范，文档不要多，但要可以对项目的每个环节都有描述说明的。我见过一个项目光需求说明就有很多份不同的文档，很头疼，而且后期的维护也会很麻烦。建议每个环节就一份统一文档。制定大家习惯的阅读方式（这点很关键，否则大家都不看），由大家共同维护完成。做一总结：需求说明文档：建议先将需求进行分解，然后用表格进行说明。如果条件允许，那就用RequisitePro管理需求，实现跟踪。 系统分析设计文档：建议采用Rose，需求用例一定要有，哪怕|考|试大|颗粒度大一些，在需求用例部分进行需求分析的说明，而且要说明规格要求。组件及类图一定要有，规范接口调用规则，组织代码结构，建立良好的系统框架。其中说明组件或类职能。此部分不一定完全由设计人员完成。有可能的情况下，提供活动图。程序员对活动图的兴趣要高于时序和状态图。可以用SoDA产生相应文档（只读）供开发查询使用。不一定一个Rose文件，可以多个，如果要拆分，对应需求拆分。 数据库说明书：建议用PD，然后自动生成文档（只读），供开发查询使用。 测试报告：可以用测试报告对成果进行说明，但我个人感觉测试计划比测试报告更重要，因为没有一个好的测试计划进行指导，最终测试也就成为了一个成果描述环节了。 其中，建议使用Project进行项目计划管理，最好可以用Projectserver来进行跟踪，这样联工作日志也可以省略了。 采用版本工具进行文档管理，一定要，非常重要。请不要忽视项目文档管理2008-11-14 9:06:07作者：陆大春 这么些年来，大大小小经历了一些信息系统的实施项目，有一部分是协助别人进行项目的实施工作，有一部分是自己负责管理项目的实施工作，另外还有一部分是通过各种渠道了解的别人的项目实施工作，在这个过程中也在不断地思索一些管理方面的问题。信息系统的实施工作是纷繁复杂的，走过了这么些年，令自己欣慰的是积累了一些成功的经验，另外一个感触就是一次次发现可改进之处的欣喜和感悟，现在就将项目管理过程中本人关于文档管理的一些潜质拙见通过本文进行一个分享。 在此前的关于信息系统的项目实施管理整个过程的文章中也提到过一些文档管理的内容，撰写此文的目的在于更加详实的表达我对项目管理过程中的文档管理的一些理解。 文档管理的重要性 一直以来，有很多的人都在说文档管理的重要性，最耳熟能详的莫过于软件项目中的人员变动以后后面的人无法识别之前的代码，或者识别的成本较高。事实情况是，就算人员不变动，时间长了，当时的编写者也不会记得当时的思路是什么，因为时间会消磨一些东西，另外每个人的想法和思维方式也在发生变化。 一个项目组织在进行一些想法的沟通时，由于个人知识结构的不同、所处的地位立场不同等原因也会导致对一个想法的最终实现方案的认知上存在差异，最终落实到方案上也会有所不同，通过一个书面的文档可以将每个人的认知形成一个统一的认知，减少不必要的沟通障碍。同时明确的文档也可以给参与者更多思考的空间。 为了达到一个好的沟通交流方式，我们需要各式各样的文档，在现实的项目管理过程中也确实存在了大量的文档，每个人都认为文档是重要的，但是当真正文档到来的时候又开始困扰了，会不自觉的有些厌烦和无从下手。做文档的过程是辛苦的，更是麻烦的，原来几句话的事情在有了文档以后变得异常麻烦，需要对应好格式，需要不同人员的审核和认可，难免就会觉得麻烦；而在自己做完文档以后发现可用性并不如想象中的那么高，真正想要的文档不知道到哪里去找，不同的文档说法不统一，等等诸如此类的问题让使用者有点无从下手。 或许是印证了一句话，叫做事情做的没有头绪的时候就想到了管理，对于那些各式各样的文档同样不会例外。 文档管理的方式在文档管理的过程中，需要把握住一些重要的原则和方法，这样可以让我们的文档真正达到我们预期的目的。 文档模板的管理 面对各类纷繁复杂的文档，如果各式各样，每个人一个风格，不论从美观性和可读性上都会有影响，所以在文档管理中的过程中需要建议一套文档的模板。 在建立文档模板时，需要对一些格式进行要求，需要将一些基本的要素固化到文档模板中，确保文档需要的内容能够在文档中体现，例如文档的页眉页脚、文档变更历史、文档的目录方式、文档的字体等。 在建立文档时，要注意做好文档的分类，各种分类有一个清晰的定义，使用者可以清楚地知道实际使用时要采用哪种模板。如果是使用共享目录方式管理文档，需要在一个相对容易找到的文件夹目录中存放模板，如果是使用信息系统方式进行模板管理，最好能够在首页进行一个连接，或者是让使用者可以快速的搜索到。在建立分类时，需要含有一个共同类，或者叫做公用类，因为在实际的使用过程中总是会有一些新的类别出现，也会有一些无法进行分类的文档，这个时候就可以通过共同类进行管理。对于文档模板的变更需要能够做到及时告知使用者，并做好版本管理。文档目录的管理为了能够在纷繁复杂的文档中找到需要的文档，需要在进行文档管理时建立一套完整的文档目录体系，主要包括文档的索引管理和文档的分类管理。在进行文档管理前，需要对不同的文档建立一个分类，建议不同的分类可以便于文档的查找，也可以针对不同的分类制定不同的管理要求。如果是文件夹方式管理，还需要分别不同的文件夹内容的安排以及权限的控制，因为文件夹管理的特殊性，需要注意其权限管理的简洁化；如果是采用信息系统管理，需要注意类型的编码体系的建立。一个好的文档分类体系可以让使用者方便地进行文档的归类和查找，文档的分类在一些管理过程中还需要注意归档管理的需求。 对于文档，需要建立一套索引机制，这里之所以特别提出索引机制，是因为在日常的文档使用中，会发现一些很多类似的文档，或者类似的内容说明，由于不同的撰写者会对一些基本的概念或者原则的说明会存在一些差异，这个时候就需要能够有一个索引来明确什么是最准确的，这一点在项目管理过程中特别重要，因为一个项目组往往会不时的发生一些变动，后来人面对多个说法时很难知道什么是对的，同时一些实际情况也会发生变动，一些说法也需要进行修正，而之前的一些文档也无法进行更正，所以这个时候也需要有一个索引来明确正确的说法，这一点问题也可以通过文档版本的管理加以改善。另外对于那些纷繁复杂的文档，有些只是事务性的，通过一个索引的方式，可以将一些重点的内容放在一个突出的位置，便于进行检索和阅览。不论是文件夹方式还是信息系统方式，都需要注意对文档的权限管理，特别是对一些归档的文档，避免归档的文档被不正确的修改或者删除。文档的命名规范各种文档，如果名称多样，或者名称含义模糊将会造成使用和交流上的不便，需要建立一套有效的命名规范体系。 对于文档的名称，首先需要名称能够容易识别，有些使用者不是很注意文档的名称，经常直接用文件的默认名称，或者就是一个自己的姓名、项目的名称等，其他的使用者很难识别是什么类型的文档。在文档的使用过程中，可以规定在文档的某些部位必须放置文档的类型或者某些其他关键字，例如将要求将文档的类别放在文件名的头部，对于月度性的文档，规定头部必须放某年某月，等等。 对于一些分不同版本的文档，可以要求分不同的版本进行管理，文件名称中注明版本号，对于终稿等一些标志性的内容可以加一些特殊的标识，这样可以明确其重要性和权威性。 这些方式将有助于文档的文件名的整洁和清晰，使用者在查找时也较为方便。在进行文档的交互调整过程中，也可以增加一些日期或者修改者的标识来进行传递，主要的目的在于能够唯一识别一个文档，减少互相沟通的障碍。 文档的变更管理 文档在使用过程中发生变更是很常见的现象，对于发生变更的文档，需要通过手段加以约束，最常用的方法就是版本的管理，对于形成的文档及时进行归档保存。 文档发生变更时，需要能够做到两点：第一，文档有清晰的变更记录，主要是针对变化的部分，不能让每个使用者在文档发生变化后都需要把文件通篇读一遍；第二，文档的最终版本要能方便的阅览，如果出现只能看变更历史才知道最终版本的话将大大提高使用成本。 在文档发生变更时，需要能够通过必要的途径通知相关人，例如通过邮件通知或者公告通知的方式，避免新的文档产生后还有大量的使用者使用旧的文档，在实际操作环境中，ISO9000管理使用的签字回收重要文档的方式很值得借鉴，当然对一些电子文档需要采用一些其他变通的方式来处理。文档的审核制度很多文档作为一种指导性文件，需要有一定的严肃性和权威性，因而对文档进行必要的审核是必须的。文档的审核时机一般为文档建立时和文档发生变更时，对于文档的适用范围的变更也应该进行必要的审核。通过文档的审核，可以检查是否存在错误的事项或者一些不合理的事项，撰写者和审核者所处的岗位不同、知识结构不同，对于一个文档如何撰写的角度和看法也会不同，在后续的审核过程中能够很好的进行文档的校正。同时，文档的审核机制也可以明确各自岗位的责任。 后记 信息系统的实施是一个负责的管理过程，需要方方面面的管理工作配合到位，文档作为一种日常交流的重要依据和工作成果的总结显得尤为重要，在文档管理的过程中既要注意严肃性，又要能兼顾灵活性，要本着在达到正常的规范性的基础上尽可能地方便使用者的使用和交流，提高使用效率。 文档管理工作在其他的一些管理工作中同样是一个重要的内容，很多大型企业都会有一个专门的档案管理部门进行文档的归档管理，这些都能充分体现文档管理的重要性之所在。一、 项目文档的重要性 在每个项目的实际运作中，不可避免地会产生大量的文档资料，仅以一个简易的软件系统开发为例，其就包含需求分析报告、开发管理计划、过程管理记录、测试报告、用户手册等多种项目文档。因此从某种程度上讲，项目管理的核心其实就是文档管理，具体说来，项目文档的功能可以从宏观、中观、微观三个层面进行阐述： 首先，从宏观角度上讲，项目文档不仅是重要的工作成果，其更加有助于组织项目管理水平的提高。 从内容上进行区分，项目文档大致可以分为成果文档和过程文档两大类，成果文档作为项目可交付物的一个组成部分，其重要性自然不言而喻。过程文档主要记录了项目管理进程中的各种信息，为项目管理人员进行工作安排提供科学的决策依据，以保证项目目标的顺利实现；另一方面，过程文档也是组织最为宝贵的文化资产，通过对过程文档进行归纳和分析，管理者可以对本次项目的成功经验和失败教训了然于胸，从而使后续同类项目的运作更加有的放矢。 其次，从中观角度上分析，项目文档是项目管理目标属性的良好诠释。 众所周知，项目管理的最大特点在于事先的计划性，管理方通过与客户进行广泛深入的交流，同时结合各种资源情况（成本、时间、人员）等，方能制定项目的整体目标体系，同时还要在此基础上对整体目标体系进行分解，以明确项目的各个阶段性目标（里程碑），而在很多情况下，项目的阶段性成果是以文档形式体现的，如新产品研发项目前期的市场调查报告，中期的产品研发计划，后期的产品市场满意度调查，等等。由此可见，项目的运作在一定程度上是由文档驱动的。 再次，从微观角度来看，项目文档对于项目管理人员的素质提升也是大有裨益的，目前国内的不少企业在进行项目管理时，都会出现一个通病：由于管理人员素质有限，许多的决定只凭口头叙述，缺少足够的文字记录，以至在项目出现问题时往往显得无所适从。从本质上讲，项目文档强调的是一种规范化管理，要求项目管理人员利用书面语言进行沟通表达，以指引项目运作，对于一个成功的项目管理人士来说，他不仅仅是项目各利益方的良好协调者，更应该是一名出色的项目文档管理者。 综上所述，项目文档对于项目的平稳运行和组织管理能力的提升都起着举足轻重的推动作用。 二、国内研究现状 笔者发现，目前国内关于介绍项目文档管理的文献数量并不是很多，且叙述的内容大体集中在如下两个方面：1、介绍特定项目的文档管理指南和规范，提供相关的项目文档模板；2、项目文档的管理工具，例如软件配置管理中所使用的PVCS等；总之，现今国内在项目文档管理的研究上还存在较多的空白点，因此很有必要对相应问题展开深入探讨，通过提高项目文档管理的有效性来提升组织的整体项目管理水平。 三、如何提高项目文档管理的有效性 面对浩如烟海的项目文档?如何才能提高对其管理的有效性呢?笔者认为,至少应该把握住以下几个