IT项目文档汇总

1、.：.；IT工程文档汇总工程按时间先后顺序会分为假设干个阶段，每个阶段会有大量的文档产生。如：工程前期会有，工程需求调研阶段有，工程设计阶段有 工程开发阶段有工程进入实施阶段后，相关的文档就更多了 工程验收阶段有等等这些较为常用的文档。一、个人觉得是方式大于内容。该文档主要谈的是工程背景，客户环境，预期建立目的，产生效益，都是些大而空 的话，对工程开发没有实践意义。这份文档的作用仅供甲乙双方的高层指点参阅，其他的工程关系人不是看不到，而是根本就不会看。这份文档普通是由公司的管理 咨询部来编制，也只需他们才干站在指点的层面上去编写非群众阅读的文档。工程管理培训二、这份文档大多时用在招标过程中，是

2、用于招标的技术方案。文档根据客户在招标方案中所规定的内容来制定相 对详细的建立方案此时由于没有经过需求调研，方案也无法过于详细。不过，我还真没见到中标之前就率队到客户现场开展需求调研的做法，客户也不允许这样 干,否那么容易产生误解。的好坏会直接影响到招标得分的高低，而且普通是由客户方的信息化的专职牵头组织，各业务部门派人配合，组成评审 小组对其评审。因此方案的编写大多情况下由管理咨询顾问来编写。另外，该方案也为工程范围划定了边境，需求调研也会遵照着划定的范围开展任务，因此该文档 在工程前期具有指点意义。注：假设工程合同附有，那么中所规定的工程范围多数与一致，但最终的工程范围应以为准。三、这份文

3、档是必需的。缘由其一：工程接下来的设计任务都将围绕它来开展，起提纲挈领的作用。缘由之二：一 大帮人风风火火的在客户处热繁华闹的折腾了大半月，总得有个书面的东西向本人老板和客户的工程担任人交代吧。印象深化的是我第一次带队到客户现场作需求， 连打印机，打印纸，笔记本，网线，小交换机装着满满一大箱一个都不少的带到现场。白天作需求，晚上联机将各自的需求整理成word文档,第二天再给客户确 认，反复修正。直到最终的需求评审会议经过后，连夜打印。厚厚的7大本文档(每个业务子系一致本)，然后乘以2，客户一份，公司一份。那一晚，一个崭新的 打印机硬是被折腾得面目全非啊。第二天大清早，还特别跑到当地的装帧店，将

4、这些文档精巧的包装一番，然后各自分头将包装好的需求文档提交给客户方对应的业 务部门的经理签名，最后汇总到客户的工程担任人手里存档，本人再带一份回公司存档并作为工程设计的根据。至此，就over了。由于工程是 客户化定制的，当工程进入到实施过程中的时候，往往需求的变卦会占到当初需求调研的30%强，而且他还不能拿当初双方签署的来说事儿，来 约束客户。除非他是行业标杆，很强势很牛叉。所以当团队将根据将编制出来后，其使命根本完成，转而束之高阁。要根据客户的描画加以分析和整理成如下要素：数据的输入、输出，业务数据量的大小及运用频率(会据此作性能的特殊设计以及负载测试)，参 与业务的角色，有无特殊的权限控制

5、，业务流程走向，能否与其他的业务相互关联等等。这些要素不是经过与客户的一次沟通交流就能获取到。要有耐心，要细致， 还要有技巧，最关键的是他要懂得客户业务。否那么，客户说的他不懂，然后他一张嘴就显外行。最后，他做出来的需求就三字：不靠谱。即使凭客户关系过了评审这 一关，报告上客户也签了字，但后等到系统实施上线的时候，他的需求变卦根本就朝着80%的比例上奔去了。那时候，先不谈老板会怎样看他，就他旁边那些个开 发的兄弟看着本人辛劳的成果一个个被客户推翻，他就知道可以杀人的眼神是神马味道了。步子迈得有些大了，扯的有些远了。我们这里只谈工程文档，关于需求如何作，如何才干做好，需求另起一篇详述。总之，这份

6、文档假设交待的不清楚，会严重影响着工程的质量与进度。说直接一点，就是关系着工程本钱或是成败。四、类似于会议纪要性质的文档，是需求评审会议后产生的结果。记录会议的时间，地点，参与的人员，会议的主 题，每一项业务需求在会议中能否得到确认这一点是整个文档的关键之处，很有能够a部门提的需求与b部门的业务发生冲突，这种事情很常见，未来会在如何做 好需求一篇中详述。总之，这份报告应作为的修正文档，将评审后的结果同步到中，也为下一次的需求评审做好预备，这样反 复几次，才最终得以客户确认。五、开发方案在需求调研需求终了后就要着手开场制定。方案书里包括设计、开发、测试、实施的详细时间，还要 注明每个阶段的关键点

7、。比如，工程第一次构建的时间点，第一次提交测试的时间点，系统发布的时间点，工程验收的时间点等等，都要在方案书中明确标明。假设 工程大、周期长，工程还要分为假设干个里程碑，每个里程碑要有详细的进度目的及质量目的阐明作为里程碑到达的检验规范。另外，每个义务都除了有详细的时间 点、优先级之外，还要有义务的责任人和需求客户配合的事项。 普通分两个版本。一份给客户，一份属于工程组内部运用。两个版本相比较而言，除了规划的粒度粗细有差别外，有时候在不得以的情况下，其时间点也不一样。至 于缘由，主要是由于客户对信息化的认知程度有限，以为开发系统是一件简单的事情，从而限定的时间要求比较苛刻。但工程合同还得签，方

8、案表还得照着客户的时 间限定来做。真正进入工程实施过程中的时候，跟客户坚持良好的沟通，让客户了解信息化建立是一个逐渐有序的过程，引导客户配合我们的步骤来实施。做好了这 一点，我想客户也不会在回头在开发方案上与我们纠结，毕竟，把工程做好才是硬道理。工程组内部的开发方案要做好版本控制。比如：一个工程周期较长，分假设干里程碑，那么在最初制定方案的时候是允许前细后粗的。也就说，第一个里程碑规划的比 较详细，后续的里程碑有意的放粗，而等到前个里程碑将近终了的时候再来细化后一个里程碑的任务内容，因此， 的每个版本都要留存，并做好文档的版本变卦阐明。还有，他一定要置信，工程的执行情况与事先安排的方案定会存在

9、差距。那么就每周召集工程组开来一次工程会 议，找出差距，分析缘由，最后将方案书完成一次同步。请记住决不是由某个人或某些人拍着脑袋弄出来的一份毫无可执行性的文档，它应该是指 引工程最终走向胜利目的的航线。工程经理圈子六、也可以叫做。模块是工程开发方案制定过程中可划分的最小粒度普通情况下如此，所以，必需等到这份文档出品后才干开场制定。的内容包括：子系统称号，模块称号，模块编号。文档由需求调研人员编制，格式简约，其目的是让阅读者毫不费力就能了解工程的本质内容以及工程规模。工程管理者联盟文章七、业内有句话：功能规格书是标杆，每日构建是心跳，里程碑是生命线。由此可见规格书的重要性。他不仅是工程开发的参照

10、，同时也作为测试的根据，所以它也是开发与测试协作的纽带。普通由富有工程阅历的开发人员编写，能迅速、准确的根据需求调研的成果转化为可编码开发的功能模块。一份好的功能规格书的规范 是让阅读文档的人可以了解系统运转的各方面细节。比如：某个模块的初始界面是什么样，初始加载的数据条件是什么，页面上有哪些按钮，其规划如何，每个按钮 如何呼应，是弹出或跳转另一个页面，遇到异常情况的提示信息是什么。不仅是初始页面，模块中的每个页面都要做如此细致的阐明，要细致到哪怕是一个下拉 框都要阐明填充其中的值从哪里获取。每个操作要阐明胜利与失败的规范,有流程的模块要画出流程图，流程的每一步注明参与的人员角色。工程经理圈子

11、功能规格书分阶段写，以划分的里程碑为准。每一阶段的功能规格书完成后，召集工程小组开规格书评审会议。测试人员必需到场，一方面是为了尽早的介入工程， 对工程的构成有更直观的认识。另一方面，也可以就前期从获得的了解来对开发人员设计的规格书提出本人的意见。评审会议由工程组长主持，每 位参与设计的人员轮番上台讲解本人设计的那部分，其他的人员主要从以下几个方面进展评审：1、功能设计能否满足客户需求。2 、面规划能否美观、合理。操作能否简单、易用。3 、据流向能否明晰，模块之间的数据关联设计能否合理。4、估计的开发时间能否合理，能否满足工程的整体开发周期要求。评审终了后，各自根据修正意见下去调整规格书。如此

12、反复几个回合，确定了功能规格书作为了工程的标杆。这个时候，工程组的一切成员包括测试都一致了对 工程的认识，规格书进入了冻结阶段，任何人无法修正。接下来，开发人员开场按照规格书中的设计进展编码，测试人员开场根据规格书编写测试用例。工程经理博客编写功能规格书其实是设计的过程是一项繁复的任务，尤其是进入工程实施阶段。用户的需求变卦会不可防止的导致系统与规格书的不同步。按照正规的流程， 变卦首先会导致设计的变卦规格书，设计的变卦指点代码的变卦。但实践上，工程进入实施阶段后，留给工程组处置反响的时间往往并不多，再者，一些细微的 调整比如界面的改动，控件的初始值假设遵照正规的流程会使开发人员怨声载道，士气

13、低下。因此，我采用了折中的方法：第一次设计一气呵成，必需保证明际 运转的系统与设计同步。这一点由测试部担任监控。系统上线后，同步的任务可以专门抽个时间来完成。即，前期是系统参照规格书开发，后期是规格书参照系统来 同步。在频繁的修正下必需保证一周内至少同步一次，并且将文档提交给测试部检查，出现问题，以bug论处。那有朋友会问，既然规格书在后期失去了标杆的作 用，那还费时费力的同步它有何意义?1、对工程后期维护起至关重要作用，完好的设计文档在加上良好的代码注释，会让维护人员迅速的进入工程形状。2、让新进入工程组的成员能尽快的对工程有整体的印象，从而担任任务。另外还可以减少工程培训的本钱。然而，后期

14、的同步又引发了另一个棘手问题：测试人员对需求变卦的测试规范从哪里获取呢?于是我们又做了改良，当需求变卦到工程组手里后，召开会议，测试人 员参与。会议上，对小的、简单的修正当即提出处理方案，测试人员记录，以此作为测试根据。对于大的改动有能够会添加功能模块，那么还是采用先设计后开发 的原那么。八、 作为的一份补充文档，主要处理如何编码的问题，测试人员普通不看。开发人员在编码之前或编码过程中假设遇到了复杂的算、业务逻辑，可以在该文档中详细的阐明处理思绪，也可以用一段伪代码来阐明。九、该文档与配套。规格书中关于数据库设计的阐明直接援用该文档。另外，工程验收时，客户也常要求开发方提供数据库设计报告，作为

15、日后其他系统与本系统做接口的根听阐明。工程管实际坛记录的内容有：模块名，数据表名，英文字段名，中文阐明，主键，外键，索引，约束注明关联的表及字段，数据类型，长度，能否为空以 及对整张数据表的备注信息。对于某些关键字段还要对他的值所表示的含义做详细阐明。另外，也会面临后期同步的棘手问题，其同步的战略是 做了修正就立刻同步数据库的改动较少，且简单。这一点与规格书还有所不同。数据库设计报告的评审与规格书一样，评审根据有如下几点：1、能否留有适当的冗余便于系统的扩展。工程管理者联盟文章2、性能能否能达标。索引能否合理。转自工程管理者联盟3、数据字段描画能否明晰易懂。评审经过的数据库设计报告交给测试一份

16、，测试人员会针对具有特殊性能要求的模块编写脚本做压力测试十、工程管理者联盟文章这个文档不常用，我普通会在两种情况下要求工程做业务模型设计：1、 业务相当复杂的时候。功能规格书更多的是从模块界面，操作方式上去论述模块的功能，至于底层的数据模型还得用uml图来辅助阐明。uml图有很多种，我们普通也只常用几种，包括：用例图，类图，时序图，其中类图又最为重要。2、 对原有系统进展重构的时候。原有系统由于种种缘由业务了解不透，工期紧张，人员才干不具备在做开发之前没有对复杂的业务进展模型设计，开发出来的系统虽然能用，但破绽百出，开发 人员时常处于救火的形状。随着时间推移，开发人员对业务有了更深化的了解，渐

17、渐的不满足在现有的代码根底上修补，产生了剧烈的重构的愿望。就这样，再作第 二个类似系统的时候，很自然的就操起uml工具对现有的代码进展重构。有很多的朋友不了解为什么要建模，直接用代码说话不是更好么?我举个工程中的例子：我曾经带队实施过一个有2000人企业的信息管理系统， 有14个子系统，600来个功能模块。其中有一个物资子系统，做过类似工程的朋友应该知道，物资子系统流程复杂还要嵌套大流程中嵌套小流程，模块众 多。刚开场没有进展业务建模，功能规格书设计终了后，直接数据库设计报告，然后上手编码。整个子系统设计花了2人月，编码用了4人月。等进入到测试阶段 后，bug满天飞，真是按下葫芦起来瓢，原定与

18、1个月的稳定期最后又延迟了1个月才总算外表上稳定下来。在客户那里上线后，需求一旦发生变卦，开发人员就 心惊胆颤，生怕出现牵一发而动全身。究其根本缘由就是在面对如此复杂的业务系统面前，没有用建模的手段将业务逻辑的全局勾勒出来，每个人只关注本人的一 块，导致数据的交互出了很多的问题。最后，在工程总结会上，大家一致以为下一个物资系统，要想方法从根本上处理这些问题。结果，下一个物资系统，我们做了 充分的设计，用uml对业务建模，使每个开发人员既能明晰的看到业务的整体轮廓，又能深化细致的了解到每个类之间的交互以及提供的接口。这样开发出来的系 统才有底气，面对客户的需求变卦我们也能知道动哪个位置、影响到哪

19、个地方，做到心中有数。所以，在以后的工程里，只需是碰见业务复杂的系统，都会要求进展建模。多花些功夫在前面，后面肯才不会被拖累。十一、这份文档由工程经理编制，作为工程的定期一周一份文档提交给公司指点审阅。文档主要包括以下几方面的内容：1、总体开发进度工程管实际坛2、现场实施进度3、工程组现有人员4、本周任务完成情况5、下周的任务方案工程管理者联盟文章6、工程存在的问题及处理方案7、需求协调的资源工程经理圈子8、功能特性变卦阐明9、艰苦缺陷列表工程经理圈子有数字，有比例，有概略，能让指点快速的掌握工程目前的进展。我做开发部经理时，部门经常会同时开展多个工程。我要求每周五上午，每个工程经理在11点之

20、前向我提交。我会在11点到 12点这一个小时内去阅读这些进度报告，从中发现问题。下午两点准时召开周工程会议，人员不要太多，由每个工程组长及测试部一切人员测试开发比例是 1:5参与。会议的主要目的其一是让各小组之间对一切的工程进展都相互有所了解，便于资源的调配。其二是由测试人员强调目前工程中存在的问题，对共性问 题制定一致的处理方案，到达知识共享。其三，确定下周义务的重点及难点，能否需求协调其他的外部资源。会议时间控制在1小时内，由于事先都提交了工程进度报告，各工程组长都是带着思索来的，因此沟通比较顺畅。在会议上对需求的、属于我职责范 围内的事情点头，超出才干范围的，请示公司指点后再作决策。会议

21、终了后，我会综合工程组长提交的进度报告的内容，同时也会附上本人的一些思索编写一份开发 部本周任务情况汇报提交给公司指点审查。转自工程管理者联盟十二、在工程进展的过程中，我们规定了一旦工程进入实践代码阶段必需执行每日构建每日构建是心跳，然后直到工程处于非活动形状为止。我们用的 版本控制工具是cvs。工程组成员每日下午5点之前提交代码，5点钟开场构建代码，构建胜利就给工程打上标签，并将标签的信息登记在文档 里。主要记录的信息有：打标的人，打标时间，标签称号，标签类型普通标签，内部测试标签，客户发布标签，补丁标，标签阐明该标签中新增了哪些内容， 处理了哪些bug等等。测试部每天6点根据下最新的标签执

22、行自动化构建，第二天早上针对昨晚构建好的系统进展测试。每日构建的任务由工程组长安排组员轮番构建。在工程多的情况下，由于都规定在5点钟从效力器上下载代码执行构建会导致效力器负载过大，相应 较慢的景象。后来，我们做了制度上的调整不再硬性规定必需5点构建，处在活动形状的工程只需每天构建一次，有一个标签就行了。倘假设6点钟某个测试人员来告 诉我某个工程没有标签，那么工程组长必需有一个非常适宜的理由对我解释，当日担任构建的人员会遭到考核，很显然，这样的问题会导致测试人员第二天只能在旧 版本上任务，测试义务无法完成，影响工程进度。工程经理圈子十三、分内部和客户的。工程组内部开会时必需求有会议纪要，现场实施

23、人员与客户在一同开会同样也需求会议纪要，打印出来双方各执一份，以便日后好对会议中所做的 决议能有所追溯。如在会议中做了对工程影响艰苦的决议，还需求客户担任人签名确认。最后，临工程验收时，整理一切的会议纪要作为验收文档的一部分提交给客 户。十四、是临去客户现场之前编制的现场任务方案。由于涉及到出差费用，首先要经过部门同意，再上报公司核准，然后再电邮给客户，获取客户对方案的认可后才干到现场任务。文档内容包括：目的，现场担任人，估计任务时间，现场任务内容安装部署，数据初始化，用户培训，需求调研，现场跟踪运用情况等等，每项内容估计任务时 间，需客户配合事项等等。最后还要留有双方签名认可的位置。到现场后

24、，第一件事就是找客户签署该文档前期要沟通好。刚开场我的工程中是没有这份文档的，结果出现多次现场实施效果不理想的情况。有客户引起的缘由，当然也有我们本身的缘由。有的客户火急火燎的让我们派实施 人员到现场去，等我们的人到现场后，客户反而把我们晾在那里好多天开场配合我们做实施的任务。我们本人的实施人员在去现场实施之前心里也没有一个明确的目 标：要到达什么目的，做哪些事情，需求提早预备，找哪些人协助，每天的安排是什么，什么时候返程等等这些都从没有仔细的思索，一到现场就被客户牵着鼻子 走，实施任务非常被动。为此，我需求制定一份实施方案，我要务虚施人员每次将出差恳求单给我审批时必需附带实施方案，实施方案经

25、我认可后，再提交给客户确 认。客户一看正正规规的文档提交过来了，还带有公司电子签章，自然也就仔细对待了对此照旧毫不在意，我行我素的客户还真有，但不多。我们规规矩矩的做 事，客户也不好经常出尔反尔。双方确认了方案后，实施人员到现场开展任务就顺利多了，方案执行的偏向率能控制在10%以内，节省了出差费用本钱，工程进 度也大步提高。其实我们也碰到过由于客户缘由客观要素，突发事件现场实施条件不具备了，我们会立刻和客户商定终止方案，前往公司，等客户现场条件具备 后再续实施。所以说，这份文档有他的灵敏性，它更多的被以为的是双方的一种商定，至少看上去很正规。十五、在工程发布之前，这份文档就应该预备好。虽然他或

26、者他的客户能够从来不会总到它，但他假设在验收的时候由于没有这份文档而惨遭用户回绝签字，那我向他深表同情，由于我曾经就这样同情过本人。不要在简单的事情上犯错误，或许它只是忽略而已。安装手册要有有步骤，有截图，还要有安装过程中易出现问题的处理方法。最后，把客服的留在文档中最醒目的位置。工程管理培训十六、每个系统都会有管理员，担任系统的正常运转。除此之外，他要能运用开发方提供的工具对系统做出灵敏的配置 以顺应业务部门需求的变卦。最根本配置包括部门人员组织构造的设定，权限的分配，任务流的调整，字典的设置，日志的审计。较高级的就涉及到表单的自定义， 报表自定义等。这些操作都不是三言两语，或经过几次培训就

27、能让管理员能实践操作，更谈不上了解。假设有一份系统管理员手册摆在管理员的案前，能随时指点他 如何操作，如何能到达目的，那不是很方便。假设要做得更贴近用户，还可以将用文字难以描画、了解的地方做成视频演示。不过，系统在设计的时候应尽能够的 做到功能强大，操作简化。在系统上线的时候，假设系统管理员能顺利确定下来往往这一点还不太容易，就该把操作手册交给系统管理员，一份电子档，一份 包装精巧的纸质档。在我们公司，管理员操作手册由测试人员编制，包括前面提到的以及后面将要提到的都是由测试人员完成，实践上他们兼着文档工 作。至于对文档质量的检测，我普通会选取一个对该系统不太了解的实施人员，模拟为系统管理员，根

28、据管理员手册中的阐明，完成我提出的义务。假设能比较顺利 的操作下来，ok，那就证明这文档还不错。假设在操作过程中多次发生疑问，那我会仔细的查看这些疑问点是由于文档没描画清楚呢，还是依托文字和截图真实难 以描画，还是参与检测的实施人员的才干或态度出现问题。总之，这份文档的好坏，之于管理员的有用还是无用，直接影响到客服人员能否减少2/3的接听 量，他知道，我指的是系统操作方面的问题。十七拆分到各功能模块中就成了模块的协助 文件，合并起来就成为系统的用户手册。用户手册中的大部分内容可以取自功能规格书，但是要将规格书里的界面图能够是 用viso绘制的换为系统实践的截图，再配上常见问题的qa,就可以交付

29、给用户了。由于规格书是由开发人员编制的，其言语风格偏向与技术型，因此测试人 员要根据详细的情况将其转换为用户易于了解的言语风格。另外，用户手册有能够还要会根据不同岗位的用户编制不同的手册，也就是我们常说的细分。举个例子：我们曾经给某企业做过一套物资管理系统。系统上线前夕， 有一位组员对用户手册提出了建议，建议将手册分为2种，一种是给客户公司指点中、高层看的。由于指点在系统中多数时候仅进展查询，比对和最终审批的操 作，因此这本手册很薄。第二种是给操作人员方案员，采购员，库管员，统计员看的，涉及系统运用的各方面，所以这本手册就比较厚。在实践运用过程中，客 户看到我们对用户手册都做了精心的设计，思索

30、如此周到，首先就对我们的系统报以等待的印象。特别是客户指点，任务很忙，时间精神有限，我们就将他最需求了 解的东西呈现给他，隐去无关的内容，降低学习运用系统的难度，节省他的时间，从而遭到指点好评。工程管理培训十八这份文档的主要作用是留给客服人员做回访。其次是工程组人员流动离任后，客户关系不至于丧失。一个工程在实施的过程中会接触很多的人。有客户高层，有 中层指点，有工程担任人也有最终用户。这些人员的姓名，性别，部门职务、办公、手机、email等等相关信息要记录在文档中便于查询。另外还要 用备注阐明该用户在系统中承当的角色。比如说，人力资源部的主任不一定就是人力资源系统的最了解的用户，倒是下面的某位

31、详细办事的人员反而是系统最熟习的 人员，一切的需求都由他来提出。那么我们就要将这个信息录入到备注中，客服在回访时才干抓住关键人物，获取有价值的信息。工程经理博客工程联络人表由工程实施人员编制，根据现场情况随时补充更新。工程经理博客十九我们做的工程大多是b/s架构，客户端零安装的系统。所以这份文档记录的是效力器配置的信息，包括：效力器的类型运用效力器，数据库效力器，中间件效力 器，文档效力器，备份效力器，双机热备还是负载平衡，效力器名和ip,登录名和密码，数据库用户名和密码，效力器硬件配置，软件配置，运用系统安装目录 等。由于我们的工程普通都附带着硬件的采购和部署安装，因此这些信息在系统安装终了

32、、正常运转后，都要记录在该文档中提交给用户签字。该用户不一定是系统 管理员，也不一定是最终用户 普通是企业担任信息化的部门，掌管一切的效力器的运转和维护，但系统验收的流程中有他签名的一个环节。写到这里，我想起了不久前的一件事。我们实施人员到现场做完了工程实施，款也回了90%。等到销售人员再去现场回10%的尾款时，却遇到了客户信息部门的 赞扬。那老哥显然憋了很久一肚子火全撒在销售人员身上，认识是说前几次回款找我签名我都没为难他们，但这一次质保金的验收我不能签名，他们的效力器虽然托 管在我这里，但一切的信息我都不知道，那个是数据库效力器，哪个是运用效力器，用户名和密码，系统安装途径全部都没有。系统

33、出了问题，业务部门全都找我， 如今有质保金在这，他们还会帮着处置，我这个字一签，出了问题我先谁去。很显然，我们实施人员怠慢了这位老哥。这也难怪，什么东西都没留下就让他人验收， 搁谁谁都不乐意啊。我了解到这个情况后，立刻派那位实施人员赶赴现场与销售人员集合，补交了该文档并请那老哥吃餐饭，赔个礼，字总算是签上了。等实施人员 回来后，我在部门内树了典型，以示警戒。我还列出了现场实施所需求的文档，并强迫规定今后出差报销找我签字必需附带着实施文档，否那么就预备找一个很充分的 理由向我解释。二十在现场实施过程中，培训是必需的。有面向个人单独的培训，有面向部门的大规模培训。在遇到大规模培育时，我们都会先和客

34、户沟通，制定培训目的、了解大约多 少人参与培训，属于哪些部门，是什么级别，分多少轮次，什么时间开展，培训地点在哪里，现场有没有投影仪然后我们根据了解的情况来制造相关的培训资 料，包括ppt,演示数据，纸质资料人手一份，考试试卷。这些培训资料要根据面向的培训人员的不同而预备不同的内容，以获得更好的培训效果。培训方案 制定终了后，再次和用户确认，双方认可后在方案上签名，接下来就是开场预备培训资料了。二十一等到开场培训了，就要预备签到表了，每个参与培训的人都要签上本人的大名。目的其一是有实践在的数据向客户指点汇报培训的效果，其二是让各位培训人员能严肃仔细的对待培训，其三是可以根据签到表来下发考试试卷

35、，也可以得到参与培训但未考试的数据。工程管理者联盟有人跟我埋怨过，说培训做得这么正规很难，首先是本人要有充分预备，其次还得客户配合。对于是本人的问题那没得说，我们必需得做好，否那么系统上线后费事很 多，而且客户会把一切的责任推向我们。另外，客户能否配合，这一部分取决于工程经理的现场掌控才干，一部分在于我们是不是自始至终都表现的很正规。只需我 们本身正规做事，才干引导客户正规的开展培训，让我们的系统能顺利上线。：系统部署好了，数据初始化的任务也完成了，培训也大 规模开展并获得了不错的效果，接下来就该进入系统试运转的阶段了。与客户做好沟通，向客户提交一份试运转恳求，阐明前期所做的任务，列出系统具备

36、试运的条 件，系统目前存在的问题以及上线后的保证措施，后续的任务安排。这份文档是系统进入到运转阶段的重要标志，是客户对我们系统的认可，对我们任务的认可，也 为后期工程验收奠定根底。工程管理培训文档中要对本人所做的任务进展量化。比如做了多少次培训，有哪些部门参与，合计多少人，数据初始化的任务涉及到哪些方面等，一定要有详实的数据辅征，给客户以系统能顺利上线的自信心。工程管理者联盟二十二实施人员在现场做了哪些任务，很难为公司界定，甚至连客户有时只知道人到现场了，但详细做了哪些事情不清楚，反而有时候会赞扬公司派来的人员不得力，没解 决什么问题。究竟是现场实施的人员消极怠工，还是由于没有沟通好引起客户的

37、误解，我们需求有一份文档记录现场任务情况。这份文档要务虚施人员每天将任务内 容详细记录，包括本次现场实施人员的姓名，实施时间，每天什么时间做了什么事情，接触了哪些人，处理了什么问题，此次实施还遗留什么问题，下阶段的任务安 排。最后在临走之前提交给客户，一方面让用户知晓我们的任务成果，另一方面让给客户留有反响渠道，签署本人的意见。我们在很多的工程中就采取这样的任务方 式，客户认可这种做法，公司内部对外地出差人员的任务也有检验的根据。到验收时候，这些文档我们也会作为工程过程文档提交给客户。二十三工程管理者联盟文章这份文档要根据工程规模的大小以及签署合同时所商定的付款方式来决议能否需求。普通的小工程

38、都采用是3:6:1的付款方式，那就不存在工程阶段验收的情 况。假设是大工程，我们普通会力争的付款方式是3:3:3:1，那么在恳求第二个30%的款项时，就必需向客户提交了。该文档要详细 描画前阶段的工程进展情况，能量化的地方一定要用数字说话，比如工程历时多长，完成了哪些功能模块，有哪些模块上线运转了，没有投运转的模块是出于什么原 因。到现场任务了多长时间，做了多少次培训等等，最后还要列出下阶段的任务安排，需求客户配合的任务。除了这些有据可查的数据描画外，一些宏观的，客套 的，应景的话也要作为总结信的言语放在最后。比如：工程为客户信息化获得什么成果，给客户处理了什么问题、带来什么益处，还要重点赞赏客户的配合等。这份 文档的终极目的是让