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