IT优质项目文档汇总样本

IT项目文档汇总项目准时间先后顺序会分为若干个阶段，每个阶段会有大量文档产生。如：项当前期会有《项当前景阐明书》《项目建设 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 》，项目需求调研阶段有《需求调研报告》《需求评审报告》，项目设计阶段有《项目开发筹划》《功能特性列表》《功能规格书》《详细设计报阐明》《数据库设计报告》《uml设计阐明》项目开发阶段有《项目开发进度报告》《项目版本阐明》《项目会议纪要》项目进入实行阶段后，有关文档就更多了《现场实行筹划》《项目安装手册》《系统管理员手册》《顾客手册》《客户联系人表》《客户服务器环境配备表》《硬件签收单》《顾客反馈阐明》《需求变更阐明》《客户培训筹划》《客户培训签到表》《项目试运营申请》《现场工作备忘录》《现场人员 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 表》项目验收阶段有《项目阶段验收报告》《项目整体验收报》等等这些较为惯用文档。　　一、《项当前景阐明》　　个人感觉是形式不不大于内容。该文档重要谈是项目背景，客户环境，预期建设目的，产生效益，都是些大而空话，对项目开发没有实际意义。这份文档作用仅供甲乙双方高层领导参阅，其她项目关系人不是看不到，而是主线就不会看。这份文档普通是由公司管理征询部来编制，也只有她们才干站在领导层面上去编写非大众阅读文档。项目管理培训　　二、《项目建设方案》　　这份文档大多时用在投标过程中，是用于投标技术方案。文档依照客户在招标方案中所规定内容来制定相对详细建设方案〔此时由于没有通过需求调研，方案也无法过于详细。但是，我还真没见到中标之前就率队到客户现场开展需求调研做法，客户也不容许这样干,否则容易产生误会〕。《项目建设方案》好坏会直接影响到投标得分高低，并且普通是由客户方信息化专职牵头组织，各业务部门派人配合，构成评审小组对其评审。因而方案编写大多状况下由管理征询顾问来编写。此外，该方案也为项目范畴划定了边界，需求调研也会遵循着划定范畴开展工作，因而该文档在项当前期具备指引意义。　　注：如果项目合同附有《技术 合同书 印刷合同书下载家教网家教中介合同家教中介合同书搬运合同书搬家公司合同书 》，那么《技术合同书》中所规定项目范畴多数与《项目建设方案》一致，但最后项目范畴应以《技术合同书》为准。training.mypm.net　　三、《需求调研报告》　　这份文档是必要。因素其一：项目接下来设计工作都将环绕它来开展，起提纲挈领作用。因素之二：一大帮人风风火火在客户处热热闹闹折腾了大半月，总得有个书面东西向自己老板和客户项目负责人交代吧。印象深刻是我第一次带队到客户现场作需求，连打印机，打印纸，笔记本，网线，小互换机装着满满一大箱一种都不少带到现场。白天作需求，晚上联机将各自需求整顿成word文档,第二天再给客户确认，重复修改。直到最后需求评审会议通过后，连夜打印。厚厚7大本文档(每个业务子系统一本)，然后乘以2，客户一份，公司一份。那一晚，一种崭新打印机硬是被折腾得面目全非啊。第二天大清早，还特地跑到本地装帧店，将这些文档精美包装一番，然后各自分头将包装好需求文档提交给客户方相应业务部门经理签名，最后汇总到客户项目负责人手里存档，自己再带一份回公司存档并作为项目设计根据。至此，《需求调研报告》就over了。由于项目是客户化定制，当项目进入到实行过程中时候，往往需求变更会占到当时需求调研30%强，并且你还不能拿当时双方订立《需求调研报告》来说事儿，来约束客户。除非你是行业标杆，很强势很牛叉。因此当团队将根据《需求调研报告》将《功能规格书》编制出来后，其使命基本完毕，转而束之高阁。　　《需求调研报告》要依照客户描述加以分析和整顿成如下要素：数据输入、输出，业务数据量大小及使用频率(会据此作性能特殊设计以及负载测试)，参与业务角色，有无特殊权限控制，业务流程走向，与否与其她业务互有关联等等。这些要素不是通过与客户一次沟通交流就能获取到。要有耐心，要细致，还要有技巧，最核心是你要懂得客户业务。否则，客户说你不懂，然后你一张嘴就显外行。最后，你做出来需求就三字：不靠谱。虽然凭客户关系过了评审这一关，报告上客户也签了字，但后等到系统实行上线时候，你需求变更基本就朝着80%比例上奔去了。那时候，先不谈老板会如何看你，就你旁边那些个开发兄弟看着自己辛苦成果一种个被客户推翻，你就懂得可以杀人眼神是神马味道了。　　步子迈得有些大了，扯有些远了。咱们这里只谈项目文档，关于需求如何作，如何才干做好，需要另起一篇详述。总之，这份文档如果交待不清晰，会严重影响着项目质量与进度。说直接一点，就是关系着项目成本或是成败。　　四、《需求评审报告》bbs.mypm.net　　类似于会议纪要性质文档，是需求评审会议后产生成果。记录会议时间，地点，参加人员，会议主题，每一项业务需求在会议中与否得到确认〔这一点是整个文档核心之处，很有也许a部门提需求与b部门业务发生冲突，这种事情很常用，将来会在如何做好需求一篇中详述〕。总之，这份报告应作为《需求调研报告》修正文档，将评审后成果同步到《需求调研报告》中，也为下一次需求评审做好准备，这样反复几次，《需求调研报告》才最后得以客户确认。　　五、《项目开发筹划》　　开发筹划在需求调研需求完毕后就要着手开始制定。筹划书里涉及设计、开发、测试、实行详细时间，还要注明每个阶段核心点。例如，项目第一次构建时间点，第一次提交测试时间点，系统发布时间点，项目验收时间点等等，都要在筹划书中明确标明。如果项目大、周期长，项目还要分为若干个里程碑，每个里程碑要有详细进度目的及质量目的阐明作为里程碑到达检查原则。此外，每个任务都除了有详细时间点、优先级之外，还要有任务负责人和需要客户配合事项。　　《项目开发筹划》普通分两个版本。一份给客户，一份属于项目组内部使用。两个版本相比较而言，除了规划粒度粗细有差别外，有时候在不得以状况下，其时间点也不相似。至于因素，重要是由于客户对信息化认知限度有限，以为开发系统是一件简朴事情，从而限定期间规定比较苛刻。但项目合同还得签，筹划表还得照着客户时间限定来做。真正进入项目实行过程中时候，跟客户保持良好沟通，让客户理解信息化建设是一种逐渐有序过程，引导客户配合咱们环节来实行。做好了这一点，我想客户也不会在回头在开发筹划上与咱们纠结，毕竟，把项目做好才是硬道理。.net项目组内部开发筹划要做好版本控制。例如：一种项目周期较长，分若干里程碑，那么在最初制定筹划时候是容许前细后粗。也就说，第一种里程碑规划比较详细，后续里程碑故意放粗，而等到前个里程碑将近结束时候再来细化后一种里程碑工作内容，因而，《项目开发筹划》每个版本都要留存，并做好文档版本变更阐明。尚有，你一定要相信，项目执行状况与事先安排筹划定会存在差距。那么就每周召集项目组开来一次项目会议，找出差距，分析因素，最后将筹划书完毕一次同步。请记住《项目开发筹划》决不是由某个人或某些人拍着脑袋弄出来一份毫无可执行性文档，它应当是指引项目最后走向胜利目的航线。项目经理圈子　　六、《功能特性列表》blog.mypm.net　　也可以叫做《功能模块列表》。模块是项目开发筹划制定过程中可划分最小粒度〔普通状况下如此〕，因此，《项目开发筹划》必要等到这份文档出品后才干开始制定。　　《功能特性列表》内容涉及：子系统名称，模块名称，模块编号。文档由需求调研人员编制，格式简洁，其目是让阅读者毫不费劲就能理解项目实质内容以及项目规模。项目管理者联盟文章　　七、《功能规格书》blog.mypm.net　　业内有句话：功能规格书是标杆，每日构建是心跳，里程碑是生命线。由此可见规格书重要性。她不但是项目开发参照，同步也作为测试根据，因此它也是开发与测试协作纽带。　　《功能规格书》普通由富有项目经验开发人员编写，能迅速、精确依照需求调研成果转化为可编码开发功能模块。一份好功能规格书原则是让阅读文档人可以理解系统运转各方面细节。例如：某个模块初始界面是什么样，初始加载数据条件是什么，页面上有哪些按钮，其布局如何，每个按钮如何响应，是弹出〔或跳转〕另一种页面，遇到异常状况提示信息是什么。不但是初始页面，模块中每个页面都要做如此细致阐明，要细致到哪怕是一种下拉框都要阐明填充其中值从哪里获取。每个操作要阐明成功与失败原则,有流程模块要画出流程图，流程每一步注明参加人员〔角色〕。项目经理圈子　　功能规格书分阶段写，以划分里程碑为准。每一阶段功能规格书完毕后，召集项目小组开规格书评审会议。测试人员必要到场，一方面是为了尽早介入项目，对项目构成有更直观结识。另一方面，也可以就前期从《需求调研报告》获得理解来对开发人员设计规格书提出自己意见。评审会议由项目组长主持，每位参加设计人员轮流上台解说自己设计那某些，别的人员重要从如下几种方面进行评审：　　1、功能设计与否满足客户需求。.net　　2、面布局与否美观、合理。操作与否简朴、易用。.net　　3、据流向与否清晰，模块之间数据关联设计与否合理。　　4、预测开发时间与否合理，与否满足项目整体开发周期规定。　　评审完毕后，各自依照修改意见下去调节规格书。如此重复几种回合，拟定了功能规格书作为了项目的杆。这个时候，项目组所有成员〔涉及测试〕都统一了对项目结识，规格书进入了冻结阶段，任何人无法修改。接下来，开发人员开始按照规格书中设计进行编码，测试人员开始依照规格书编写测试用例。项目经理博客　　编写功能规格书〔其实是设计过程〕是一项繁复工作，特别是进入项目实行阶段。顾客需求变更会不可避免导致系统与规格书不同步。按照正规流程，变更一方面会导致设计变更〔规格书〕，设计变更指引代码变更。但事实上，项目进入实行阶段后，留给项目组解决反馈时间往往并不多，再者，某些细微调节〔例如界面改动，控件初始值〕如果遵循正规流程会使开发人员怨声载道，士气低下。因而，我采用了折中办法：第一次设计一气呵成，必要保证明际运营系统与设计同步。这一点由测试部负责监控。系统上线后，同步工作可以专门抽个时间来完毕。即，前期是系统参照规格书开发，后期是规格书参照系统来同步。在频繁修改下必要保证一周内至少同步一次，并且将文档提交给测试部检查，浮现问题，以bug论处。那有朋友会问，既然规格书在后期失去了标杆作用，那还费时费劲同步它有何意义?　　1、对项目后期维护起至关重要作用，完整设计文档在加上良好代码注释，会让维护人员迅速进入项目状态。2、让新进入项目构成员能尽快对项目有整体印象，从而担任工作。此外还可以减少项目培训成本。　　然而，后期同步又引起了另一种棘手问题：测试人员对需求变更测试原则从哪里获取呢?于是咱们又做了改进，当需求变更到项目组手里后，召开会议，测试人员参加。会议上，对小、简朴修改当即提出解决方案，测试人员记录，以此作为测试根据。对于大改动〔有也许会增长功能模块〕，则还是采用先设计后开发原则。　　八、《详细设计报阐明》bbs.mypm.net　　作为《功能规格书》一份补充文档，重要解决如何编码问题，测试人员普通不看。开发人员在编码之前或编码过程中如果遇到了复杂算、业务逻辑，可以在该文档中详细阐明解决思路，也可以用一段伪代码来阐明。　　九、《数据库设计报告》　　该文档与《功能规格书》配套。规格书中关于数据库设计阐明直接引用该文档。此外，项目验收时，客户也常规定开发方提供数据库设计报告，作为日后其她系统与本系统做接口根据阐明。项目管理论坛　　《数据库设计报告》记录内容有：模块名，数据表名，英文字段名，中文阐明，主键，外键，索引，约束〔注明关联表及字段〕，数据类型，长度，能否为空以及对整张数据表备注信息。对于某些核心字段还要对她值所示含义做详细阐明。此外，《数据库设计报告》也会晤临后期同步棘手问题，其同步方略是做了修改就及时同步〔数据库改动较少，且简朴。这一点与规格书尚有所不同〕。　　数据库设计报告评审与规格书相似，评审根据有如下几点：　　1、与否留有恰当冗余便于系统扩展。项目管理者联盟文章　　2、性能与否能达标。索引与否合理。转自项目管理者联盟　　3、数据字段描述与否清晰易懂。.net　　评审通过数据库设计报告交给测试一份，测试人员会针对具备特殊性能规定模块编写脚本做压力测试　　十、《uml设计阐明》项目管理者联盟文章　　这个文档不惯用，我普通会在两种状况下规定项目做业务模型设计：　　1、业务相称复杂时候。功能规格书更多是从模块界面，操作方式上去阐述模块功能，至于底层数据模型还得用uml图来辅助阐明。uml图有诸各种，咱们普通也只惯用几种，涉及：用例图，类图，时序图，其中类图又最为重要。　　2、对原有系统进行重构时候。　　原有系统由于种种因素〔业务理解不透，工期紧张，人员能力不具备〕在做开发之前没有对复杂业务进行模型设计，开发出来系统虽然能用，但漏洞百出，开发人员时常处在救火状态。随着时间推移，开发人员对业务有了更进一步理解，慢慢不满足在既有代码基本上修补，产生了强烈重构愿望。就这样，再作第二个类似系统时候，很自然就操起uml工具对既有代码进行重构。　　有诸多朋友不理解为什么要建模，直接用代码说话不是更好么?我举个项目中例子：我曾经带队实行过一种有人公司信息管理系统，有14个子系统，600来个功能模块。其中有一种物资子系统，做过类似项目朋友应当懂得，物资子系统流程复杂还要嵌套〔大流程中嵌套小流程〕，模块众多。刚开始没有进行业务建模，功能规格书设计完毕后，直接数据库设计报告，然后上手编码。整个子系统设计花了2人月，编码用了4人月。等进入到测试阶段后，bug满天飞，真是按下葫芦起来瓢，原定与1个月稳定期最后又延迟了1个月才总算表面上稳定下来。在客户那里上线后，需求一旦发生变更，开发人员就心惊胆颤，生怕浮现牵一发而动全身。究其主线因素就是在面对如此复杂业务系统面前，没有用建模手段将业务逻辑全局勾勒出来，每个人只关注自己一块，导致数据交互出了诸多问题。最后，在项目总结会上，人们一致以为下一种物资系统，要想办法从主线上解决这些问题。成果，下一种物资系统，咱们做了充分设计，用uml对业务建模，使每个开发人员既能清晰看到业务整体轮廓，又能进一步细致理解到每个类之间交互以及提供接口。这样开发出来系统才有底气，面对客户需求变更咱们也能懂得动哪个位置、影响到哪个地方，做到心中有数。.net　　因此，在后来项目里，只要是碰见业务复杂系统，都会规定进行建模。多花些功夫在前面，背面肯才不会被连累。　　十一、《项目开发进度报告》　　这份文档由项目经理编制，作为项目定期〔一周一份〕文档提交给公司领导审视。文档重要涉及如下几方面内容：　　1、总体开发进度项目管理论坛　　2、现场实行进度　　3、项目组既有人员　　4、本周工作完毕状况　　5、下周工作筹划项目管理者联盟文章　　6、项目存在问题及解决方案　　7、需要协调资源项目经理圈子　　8、功能特性变更阐明9、重大缺陷列表项目经理圈子　　有数字，有比例，有详情，能让领导迅速掌握项目目迈进展。blog.mypm.net　　我做开发部经理时，部门经常会同步开展各种项目。我规定每周五上午，每个项目经理在11点之前向我提交《项目进度报告》。我会在11点到12点这一种小时内去浏览这些进度报告，从中发现问题。下午两点准时召开周项目会议，人员不要太多，由每个项目组长及测试部所有人员〔测试开发比例是1:5〕参加。会议重要目其一是让各小组之间对所有项目进展都互相有所理解，便于资源调配。其二是由测试人员强调当前项目中存在问题，对共性问题制定统一解决方案，达到知识共享。其三，拟定下周任务重点及难点，与否需要协调其她外部资源。　　会议时间控制在1小时内，由于事先都提交了项目进度报告，各项目组长都是带着思考来，因而沟通比较顺畅。在会议上对需要、属于我职责范围内事情拍板，超过能力范畴，请示公司领导后再作决策。会议结束后，我会综合项目组长提交进度报告内容，同步也会附上自己某些思考编写一份开发部本周工作状况报告提交给公司领导审查。转自项目管理者联盟　　十二、《项目版本阐明》blog.mypm.net　　在项目进展过程中，咱们规定了一旦项目进入实际代码阶段必要执行每日构建〔每日构建是心跳〕，然后直到项目处在非活动状态为止。咱们用版本控制工具是cvs。项目构成员每日下午5点之前提交代码，5点钟开始构建代码，构建成功就给项目打上标签，并将标签信息登记在《版本控制阐明》文档里。重要记录信息有：打标人，打标时间，标签名称，标签类型〔普通标签，内部测试标签，客户发布标签，补丁标〕，标签阐明〔该标签中新增了哪些内容，解决了哪些bug等等〕。测试部每天6点依照《版本控制阐明》下最新标签执行自动化构建，第二天早上针对昨晚构建好系统进行测试。　　每日构建工作由项目组长安排成员轮流构建。在项目多状况下，由于都规定在5点钟从服务器上下载代码执行构建会导致服务器负载过大，相应较慢现象。日后，咱们做了制度上调节不再硬性规定必要5点构建，处在活动状态项目只要每天构建一次，有一种标签就行了。倘若6点钟某个测试人员来告诉我某个项目没有标签，那么项目组长必要有一种非常适当理由对我解释，当天负责构建人员会受到考核，很显然，这样问题会导致测试人员第二天只能在旧版本上工作，测试任务无法完毕，影响项目进度。项目经理圈子　　十三、《项目会议纪要》　　分内部和客户。项目组内部开会时必要要有会议纪要，现场实行人员与客户在一起开会同样也需要会议纪要，打印出来双方各执一份，以便日后好对会议中所做决策能有所追溯。如在会议中做了对项目影响重大决定，还需要客户负责人签名确认。最后，临项目验收时，整顿所有会议纪要作为验收文档一某些提交给客户。.net　　十四、《现场实行筹划》.net　　是临去客户现场之前编制现场工作筹划。由于涉及到出差费用，一方面要通过部门批准，再上报公司核准，然后再电邮给客户，获取客户对筹划承认后才干到现场工作。　　文档内容涉及：目的，现场负责人，预测工作时间，现场工作内容〔安装布置，数据初始化，顾客培训，需求调研，现场跟踪使用状况等等〕，每项内容预测工作时间，需客户配合事项等等。最后还要留有双方签名承认位置。到现场后，第一件事就是找客户订立该文档〔前期要电话沟通好〕。　　刚开始我项目中是没有这份文档，成果浮现多次现场实行效果不抱负状况。有客户引起因素，固然也有咱们自身因素。有客户火急火燎让咱们派实行人员到现场去，等咱们人到现场后，客户反而把咱们晾在那里好多天开始配合咱们做实行工作。咱们自己实行人员在去现场实行之前心里也没有一种明确目标：要达到什么目，做哪些事情，需要提前准备，找哪些人协助，每天安排是什么，什么时候返程等等这些都从没有认真考虑，一到现场就被客户牵着鼻子走，实行工作非常被动。为此，我需要制定一份实行筹划，我规定实行人员每次将出差申请单给我审批时必要附带实行筹划，实行筹划经我承认后，再提交给客户确认。客户一看正正规规文档提交过来了，还带有公司电子签章，自然也就认真对待了〔对此仍旧毫不在乎，我行我素客户还真有，但不多。咱们规规矩矩做事，客户也不好经常出尔反尔〕。双方确认了筹划后，实行人员到现场开展工作就顺利多了，筹划执行偏差率能控制在10%以内，节约了出差费用成本，项目进度也大步提高。其实咱们也遇到过由于客户因素〔客观因素，突发事件〕现场实行条件不具备了，咱们会及时和客户商定终结筹划，返回公司，等客户现场条件具备后再续实行。因此说，这份文档有她灵活性，它更多被以为是双方一种商定，至少看上去很正规。.net　　十五、《系统安装手册》　　在项目发布之前，这份文档就应当准备好。虽然你或者你客户也许从来不会总到它，但你如果在验收时候由于没有这份文档而惨遭顾客回绝签字，那我向你深表同情，由于我曾经就这样同情过自己。不要在简朴事情上出错误，或许它只是疏忽而已。安装手册要有有环节，有截图，还要有安装过程中易浮现问题解决办法。最后，把客服电话留在文档中最醒目位置。项目管理培训　　十六、《系统管理员手册》bbs.mypm.net　　每个系统都会有管理员，负责系统正常运营。除此之外，她要能运用开发方提供工具对系统做出灵活配备以适应业务部门需求变更。最基本配备涉及部门人员组织构造设定，权限分派，工作流调节，字典设立，日记审计。较高档就涉及到表单自定义，报表自定义等。这些操作都不是三言两语，或通过几次培训就能让管理员能实际操作，更谈不上理解。如果有一份系统管理员手册摆在管理员案前，能随时指引她如何操作，如何能达到目的，那不是很以便。〔如果要做得更贴近顾客，还可以将用文字难以描述、理解地方做成视频演示。但是，系统在设计时候应尽量做到功能强大，操作简化。〕在系统上线时候，如果系统管理员能顺利拟定下来〔往往这一点还不太容易〕，就该把操作手册交给系统管理员，一份电子档，一份包装精美纸质档。　　在咱们公司，管理员操作手册由测试人员编制，涉及前面提到《系统安装手册》以及背面将要提到《顾客手册》都是由测试人员完毕，事实上她们兼着文档工作。至于对文档质量检测，我普通会选用一种对该系统不太理解实行人员，模仿为系统管理员，根据管理员手册中阐明，完毕我提出任务。如果能比较顺利操作下来，ok，那就证明这文档还不错。如果在操作过程中多次发生疑问，那我会仔细查看这些疑问点是由于文档没描述清晰呢，还是依托文字和截图实在难以描述，还是参加检测实行人员能力或态度浮现问题。总之，这份文档好坏，之于管理员有用还是无用，直接影响到客服人员能否减少2/3电话接听量，你懂得，我指是系统操作方面问题。　　十七《顾客手册》bbs.mypm.net　　拆分到各功能模块中就成了模块协助文献，合并起来就成为系统顾客手册。顾客手册中大某些内容可以取自功能规格书，但是要将规格书里界面图〔也许是用viso绘制〕换为系统实际截图，再配上常用问题qa,就可以交付给顾客了。由于规格书是由开发人员编制，其语言风格偏向与技术型，因而测试人员要依照详细状况将其转换为顾客易于理解语言风格。　　此外，顾客手册有也许还要会依照不同岗位顾客编制不同手册，也就是咱们常说细分。举个例子：咱们曾经给某公司做过一套物资管理系统。系统上线前夕，有一位成员对顾客手册提出了建议，建议将手册分为2种，一种是给客户公司领导〔中、高层〕看。由于领导在系统中多数时候仅进行查询，比对和最后审批操作，因而这本手册很薄。第二种是给操作人员〔筹划员，采购员，库管员，记录员〕看，涉及系统使用各方面，因此这本手册就比较厚。在实际使用过程中，客户看到咱们对顾客手册都做了精心设计，考虑如此周到，一方面就对咱们系统报以期待印象。特别是客户领导，工作很忙，时间精力有限，咱们就将她最需要了解东西呈现给她，隐去无关内容，减少学习使用系统难度，节约她时间，从而受到领导好评。项目管理培训　　十八《客户联系人表》　　这份文档重要作用是留给客服人员做回访。另一方面是项目组人员流动〔离职〕后，客户关系不至于丢失。一种项目在实行过程中会接触诸多人。有客户高层，有中层领导，有项目负责人也有最后顾客。这些人员姓名，性别，部门职务、办公电话、手机、qq、email等等有关信息要记录在文档中便于查询。此外还要用备注阐明该顾客在系统中承担角色。例如说，人力资源部主任不一定就是人力资源系统最理解顾客，倒是下面某位详细办事人员反而是系统最熟悉人员，所有需求都由她来提出。那么咱们就要将这个信息录入到备注中，客服在回访时才干抓住核心人物，获取有价值信息。项目经理博客　　项目联系人表由项目实行人员编制，依照现场状况随时补充更新。项目经理博客　　十九《客户环境配备表》　　咱们做项目大多是b/s架构，客户端零安装系统。因此这份文档记录是服务器配备信息，涉及：服务器类型〔应用服务器，数据库服务器，中间件服务器，文档服务器，备份服务器〕，双机热备还是负载均衡，服务器名和ip,登录名和密码，数据库顾客名和密码，服务器硬件配备，软件配备，应用系统安装目录等。由于咱们项目普通都附带着硬件采购和布置安装，因而这些信息在系统安装完毕、正常运营后，都要记录在该文档中提交给顾客签字。该顾客不一定是系统管理员，也不一定是最后顾客〔普通是公司负责信息化部门，掌管所有服务器运营和维护〕，但系统验收流程中有她签名一种环节。　　写到这里，我想起了不久前一件事。咱们实行人员到现场做完了项目实行，款也回了90%。等到销售人员再去现场回10%尾款时，却遇到了客户信息部门投诉。那老哥显然憋了好久一肚子火全撒在销售人员身上，意识是说前几次回款找我签名我都没为难你们，但这一次质保金验收我不能签名，你们服务器虽然托管在我这里，但所有信息我都不懂得，那个是数据库服务器，哪个是应用服务器，顾客名和密码，系统安装途径所有都没有。系统出了问题，业务部门全都找我，当前有质保金在这，你们还会帮着解决，我这个字一签，出了问题我先谁去。很显然，咱们实行人员怠慢了这位老哥。这也难怪，什么东西都没留下就让别人验收，搁谁谁都不乐意啊。我理解到这个状况后，及时派那位实行人员赶赴现场与销售人员汇合，补交了该文档并请那老哥吃餐饭，赔个礼，字总算是签上了。等实行人员回来后，我在部门内树了典型，以示警戒。我还列出了现场实行所需要文档，并强制规定此后出差报销找我签字必要附带着实行文档，否则就准备找一种很充分理由向我解释。blog.mypm.net　　二十《客户培训筹划》　　在现场实行过程中，培训是必要。有面向个人单独培训，有面向部门大规模培训。在遇到大规模哺育时，咱们都会先和客户沟通，制定培训目的、理解大概多少人参加培训，属于哪些部门，是什么级别，分多少轮次，什么时间开展，培训地点在哪里，现场有无投影仪……然后咱们依照理解状况来制作有关培训资料，涉及ppt,演示数据，纸质资料〔人手一份〕，考试试卷。这些培训资料要依照面向培训人员不同而准备不同内容，以获得更好培训效果。培训筹划制定完毕后，再次和顾客确认，双方承认后在筹划上签名，接下来就是开始准备培训资料了。二十一《客户培训签到表》blog.mypm.net　　等到开始培训了，就要准备签到表了，每个参加培训人都要签上自己大名。目其一是有实际在数据向客户领导报告培训效果，其二是让各位培训人员能严肃认真对待培训，其三是可以依照签到表来下发考试试卷，也可以得到参加培训但未考试数据。项目管理者联盟　　有人跟我抱怨过，说培训做得这样正规很难，一方面是自己要有充分准备，另一方面还得客户配合。对于是自己问题那没得说，咱们必要得做好，否则系统上线后麻烦很多，并且客户会把所有 责任 安全质量包保责任状安全管理目标责任状8安全事故责任追究制幼儿园安全责任状占有损害赔偿请求权 推向咱们。此外，客户与否配合，这一某些取决于项目经理现场掌控能力，一某些在于咱们是不是自始至终都体现很正规。只有我们自身正规做事，才干引导客户正规开展培训，让咱们系统能顺利上线。　　《系统试运营申请》：系统布置好了，数据初始化工作也完毕了，培训也大规模开展并获得了不错效果，接下来就该进入系统试运营阶段了。与客户做好沟通，向客户提交一份试运营申请，阐明前期所做工作，列出系统具备试运条件，系统当前存在问题以及上线后保证办法，后续工作安排。这份文档是系统进入到运营阶段重要标志，是客户对咱们系统承认，对咱们工作承认，也为后期项目验收奠定基本。项目管理培训　　文档中要对自己所做工作进行量化。例如做了多少次培训，有哪些部门参加，共计多少人，数据初始化工作涉及到哪些方面等，一定要有详实数据辅征，给客户以系统能顺利上线信心。项目管理者联盟　　二十二《现场工作备忘录》　　实行人员在现场做了哪些工作，很难为公司界定，甚至连客户有时只懂得人到现场了，但详细做了哪些事情不清晰，反而有时候会投诉公司派来人员不得力，没解决什么问题。究竟是现场实行人员悲观怠工，还是由于没有沟通好引起客户误会，咱们需要有一份文档记录现场工作状况。这份文档规定实行人员每天将工作内容详细记录，涉及本次现场实行人员姓名，实行时间，每天什么时间做了什么事情，接触了哪些人，解决了什么问题，本次实行还遗留什么问题，下阶段工作安排。最后在临走之前提交给客户，一方面让顾客知晓咱们工作成果，另一方面让给客户留有反馈渠道，订立自己意见。咱们在诸多项目中就采用这样工作方式，客户承认这种做法，公司内部对外地出差人员工作也有检查根据。到验收时候，这些文档咱们也会作为项目过程文档提交给客户。blog.mypm.net　　二十三《项目阶段验收申请》项目管理者联盟文章　　这份文档要依照项目规模大小以及订立合同步所商定付款方式来决定与否需要。普通小项目都采用是3:6:1付款方式，那就不存在项目阶段验收情况。如果是大项目，咱们普通会力求付款方式是3:3:3:1，那么在申请第二个30%款项时，就必要向客户提交《项目阶段验收申请》了。该文档要详细描述前阶段项目进展状况，能量化地方一定要用数字说话，例如项目历时多长，完毕了哪些功能模块，有哪些模块上线运营了，没有投运营模块是出于什么原因。到现场工作了多长时间，做了多少次培训等等，最后还要列出下阶段工作安排，需要客户配合工作。除了这些有据可查数据描述外，某些宏观，客套，应景话也要作为总结信语言放在最后。例如：项目为客户信息化获得什么成果，给客户解决了什么问题、带来什么好处，还要重点感谢客户配合等。这份文档终极目的是让参加验收客户人员能在上面签字盖章，因此这份虚实结合、讲求方略〔面对一塌糊涂项目这是必要〕文档普通由项目经理亲自操刀。　　二十四《项目整体验收申请》　　基本上和阶段验收报告类似——虚实结合、讲求方略。但阶段验收申请中下阶段筹划安排要改为项目后期维护服务，算是在这里做个小小承诺〔一定要依照合同条款来〕。此外，在提交整体验收申请时，要附上项目过程文档。除了涉及到公司机密文献之外，可以给所有复印一份交给客户，不要让客户在文档方面挑我们毛病。固然，能否顺利通过验收，绝不是文档做好就能搞定事情，更多是咱们要用项目文档来管理〔 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 〕咱们项目过程，毕竟，项目做得好才是通过验收坚实基本。　　终于写完了项目文档知多少这一系列博客，也是自己第一篇博客。在上下班途中，在出差火车上用手机一种字，一种字码出来。回顾自己从业it行业8年，从程序员，项目经理，部门经理一步步走开，始终坚持在一线上。既要进一步到现场与各种类型客户打交道、协调关系，又要在部门内部深抓项目管理、平衡人力资源。在完毕公司任务之外还要考虑团队建设，技术走向，产品创新。面对公司发展，还得从公司层面上去和高层保持思想统一，带领部门人员贯彻执行，虽然是以牺牲部门利益为代价。　　这样近年忙与累，成功与失败，经验与教训，责难与勉励，技术与管理，点点滴滴、积累于心。写博客既是表达心中所想一种渠道，更是自我梳理项目管理经验过程。之因此选取项目文档之多少作为开篇博客，其理由是由于我所列文档贯穿于项目整个过程，涉及项当前期投标，项目进行中需求，设计，开发，测试，实行以及项目后期验收及维护。通过这样些个文档一方面将项目流程梳理清晰，至于流程每个环节那都需要单独篇章来回顾和总结。　　有公司规模小，项目用不上这样些文档。有公司规模大，管理更为规范，文档不止我列这样某些〔例如：代码复查报告，风险分析报告等〕，尚有公司走是敏捷开发之路，遵循简朴文档、面对面沟通原则。总之，文档在项目管理过程中起着工具、手段作用，是沟通桥梁，是约束规范，是产出成果。　　咱们公司做得是行业应用软件，技术门槛不高，因此在招聘人员时候，我大多数都会考察应聘人员项目经历，团队合伙经验及现场应对能力。在问到项目经历时候，我普通会问应聘者在项目过程中会留下哪些文档。从她对文档描述细节中我大都能看出她参加过项目哪些阶段。然后再依照文档把问题延伸下去。我发现，看文档人和写文档人主线是两回事。看文档人多是在别人成果上进行工作，而写文档人才真正参加到工作其中。因而，从文档角度来考察个人项目经历具备一定说服力。写到最后，我还想再强调一下。文档只是工具，是需要灵活运用工具，是需要依照项目规模，人员素质来匹配组合。如果一味遵守某些Iso或cmmi规定为了文档而文档，其成果将会适得其反，不但项目质量与进度没有明显改进，还会弄得怨声四起，士气低落。只有弄清每个文档背后所要解决问题〔文档只是成果〕，才干有效运用文档这个工具去解决自己问题。training.mypm.net