IT项目文档汇总.docx

IT项目文档汇总.docx

《IT项目文档汇总.docx》由会员分享，可在线阅读，更多相关《IT项目文档汇总.docx（17页珍藏版）》请在冰点文库上搜索。

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 种，一种

是给客户公司领导〔中、高层〕看的。

由于领导在系统中多数时