企业官网建设流程全解析

简介：这是一份面向信息化项目管理者、项目经理及项目团队成员的《信息化项目建设项目章程》标准模板。文档系统梳理了章程编制所需的六大核心模块：SMART项目目标与成功标准、项目管理基本原则、项目组织架构与职责分工、项目计划与配置管理、项目沟通制度以及项目风险管理，可直接用于实际项目的章程起草与规范化管理。包内为1个doc格式文件，压缩包大小167KB，内容精炼、结构清晰，便于按目录快速套用与修改。目前已有843人学习下载，适合正在筹备信息化项目立项、需要快速建立项目章程框架的从业者参考。获取后即可获得一份包含目录式章节、配置存放目录及权限、会议与邮件制度、员工工作要求等完整要素的可编辑文档模板，帮助降低项目启动阶段文档编制门槛，提升项目管理规范化水平。

1. 项目章程模板：启动阶段最容易漏掉的几步

项目启动会前夜，最高效的一件事是把手里的信息化项目建设项目章程模板摊开，逐条核对一遍。这份文档解决的不是“要不要写章程”的问题，而是“章程里到底该写什么才不会被当成存档文件束之高阁”：目标往哪个方向定才经得起验收、六个项目组的职责边界怎么划、配置管理用什么工具、会议纪要以什么状态进入受控。做项目管理的同行都清楚，启动阶段最容易漏掉权限矩阵和变更入口，而这恰恰决定了一批需求变更涌进来时团队会不会乱。这份模板适合项目经理、执行协调人、配置管理员以及需要向甲方交底的实施团队负责人，它把“人怎么分工、文档怎么受控、事情怎么推进”的骨架一次性搭好，剩下只需要按自己的项目填空。

2. 目标与成功标准：先定“四级可验证”再写计划

项目章程里最不能被模糊处理的，就是目标和成功标准。很多人把“平台上线、系统投运”当作目标来写，结果验收时各方开始掰扯“上线”与“验收通过”之间的差距。这份模板在这一点上给了很好的示范，它把目标拆成了部署层、方案能力层、业务覆盖层三条，并用“一级部署、二级管控、三级应用”圈定了管理纵深，再用“试点单位全部通过系统管项目、集团领导能看见项目情况”把成功标准落到可见、可查、可控的颗粒度上。有了这个口径，后续做计划、排资源、定评审节点都有依据。

2.1 目标怎么写才不是口号

原文目标里三条分别是：完成某集团项目管理工具的一级部署、二级管控、三级应用；形成解决方案加通用的项目管理工具；覆盖科技及知识产权类的软件产权、科技进步奖、国际国内会议、论文等条目。这三条单独拎出来看是典型的集团级项目叙事，但如果直接照抄进自己的章程，执行层会一头雾水：谁来部署、部署到什么环境、管控哪些维度、应用范围覆盖到哪一层。

我在实际编写章程时，会把每一条目标翻译成一个可验证的检查项，和目标一一对应。常见做法是做一张“目标-证据映射表”，放进去后目标就不再是口号，而是一个个答辩时拿得出材料的条目。

这张表的好处是，它把“目标”导入了“验证动作”的语境。后续无论谁提出“系统已经上线了为什么还不验收”，直接把目标2、目标3对应的检查项拿出来，一项一项对证据，双方都没有争议空间。

写目标时还要区分项目章程的读者。给某集团领导看的目标强调管控和可视化，给项目团队看的目标强调交付物和验收条件，给试点单位用户看的目标强调操作便捷和业务覆盖。同一份章程里，三段人看到的侧重可以不同，但核心检查项必须一致，否则执行者会对“哪个目标优先”产生误解。

2.2 成功标准从“三条口号”拆成“四级可量化”

原文给出的成功标准有三条：建立项目管理工具并成功导入；选定试点单位的项目管理全部通过该系统开展；某集团领导可以通过系统看到试点单位的项目情况，实现监控。从表面看这三条已经具备基本轮廓，但“成功导入”这四个字在验收阶段有极大的解释空间：是把历史数据导入系统就算成功，还是所有流程跑通且用户真在使用才算成功？这是实际项目中常见的争议来源。

我一般会建议在原三层标准之上做一次细化，形成四级的可验证清单，每一级都给出对应的验证方法和通过条件。

• 第一级：系统部署就绪。验证方法是检查部署清单、环境配置记录、数据库初始化脚本执行结果，通过条件是核心功能模块全部在测试环境跑通并通过一轮冒烟测试。
• 第二级：历史数据迁移完整。验证方法是核对历史项目清单与系统导入记录，按项目数量、条目数量、字段完整率三个维度比对，通过条件是迁移完成率做到100%，且抽样字段无丢失。
• 第三级：试点单位全员使用。验证方法是导出系统内各试点单位的立项单、项目月报、进度更新记录，通过条件是连续一个月内，每条新建项目均有系统内操作记录。
• 第四级：领导层可视化监控。验证方法是向某集团项目管理中心展示管理层报表页面，通过条件是领导可查看项目列表、进度偏差、风险状态三类信息，且权限隔离正确。

把成功标准拆到这个程度后，整个项目团队对“什么时候可以进入验收”就有了共同的基线。更重要的是，它天然生成了一组验收证据清单，集成组准备验收材料时，只需要按这四个层级去汇集文档和系统截图，不需要临时现找。

2.3 成功标准与验收材料的关联方式

很多项目做完了才发现验收材料不够，原因是章程里的成功标准没有和文档交付物挂钩。按照这份模板的体例，我会在每个成功标准后追加一行“证据要求”。比如第二级历史数据迁移，证据要求是迁移报告加关键用户确认签字；第三级全员使用，证据要求是系统操作日志的审计导出。这样章程就不只是理念文件，它还是验收材料目录的起点。

做这一步的时候，建议把每个标准对应的“证据文件”列出清单，同时注明责任角色。实操中我还会把证据清单发给配置管理组一份，让配置管理员知道哪些文档要受控归档、归档路径在SVN的哪个目录下。这一步做完后，验收资料的整理压力会被分散到执行周期里，而不是集中在验收前两周。

3. 组织与配置管理：角色边界和SVN目录权限一起定

项目组织架构最怕画完图就完了。这份模板在4.2节把角色分成项目经理、执行项目经理、专家组、现场调研组、研发组、数据组、配置管理组七类，并给每一类分配了明确的职责关键词。单看每一段很正常，但放在一起才会发现它构建了一个循环：现场调研组把需求从客户现场带回来，研发组做出系统，数据集组跟进数据，集成组做培训和导入，配置管理组把所有文档和代码管住，最终由执行项目经理做偏差分析并向项目经理汇报。

3.1 七个角色的职责边界怎么划

实际项目中最容易出现使用权责模糊的地方，通常不是项目经理和执行项目经理的关系，而是现场调研组里的业务调研和集成培训在过渡阶段的衔接。比如前期调研时，业务调研组访谈了客户的高层和关键用户，整理了客户资料，形成项目管理模板；到了实施导入阶段，集成组接手做培训和试运行支持。如果两边对“需求确认”和“培训落地”的界面没有界定，经常出现集成组培训时才发现调研组确认的需求在实际操作层面跑不通。

行之有效的方法是团队建立“需求传递单”。业务调研组完成关键用户访谈后，不仅要把结论写进需求文档，还要把与客户确认过的关键操作流程逐条列出来，录入一处共享的模板库，同时同步给研发组和集成组。集成组在编写培训课件时，必须以这个确认结果为准；遇到不一致的时候，第一反应是回到研调整理的需求清单做联调，而不是先改培训材料。

专家组这个角色也容易被架空。项目推进过程中，如果专家只在里程碑评审会上出现一次，之后再也不参与，架构层面的偏差就要等开发完成才能暴露，返工代价极高。我的一般做法是让专家组在每个关键设计文档的评审结论中明确写“同意”或“拒绝”，而不是给出“原则同意、细节再议”这类模糊意见。签字是专家组存在价值的直接体现。

配置管理组容易被看作“管文档的”，但在信息化项目中它的边界要宽得多：源代码、数据库脚本、配置文件、需求文档、设计文档、培训材料、会议纪要、验收材料，全部属于配置项。配置管理员真正该做的是维护“什么人在什么时间对哪个配置项做了什么变更”的完整记录。如果这个角色只管着SVN账号和目录，项目到后期根本查不清基线。

3.2 SVN目录结构与权限设计

模板6.1节写得很明确：采用SVN做配置管理工具，配置管理统一归口执行。结合信息化项目的通用做法，我建议在SVN仓库里采用如下目录结构，把文档和代码分区存放，避免互相干扰。

这个结构有几个关键设计逻辑：代码与文档分离，避免开发提交时把文档目录搞乱；配置模板单独立目录，防止敏感配置项被开发者随手修改；tags目录只允许配置管理员写入，保证发布版本的基线不被污染；临时分支独立于主干，新框架验证、测试数据准备都在分支上进行。

权限落到人头上，防止研发人员遇到权限不足时突破规定绕过问题。配置管理组应在项目启动后第一时间生成一份权限登记表，逐人列出SVN账号、所属组、可读写路径、开通日期，该表作为配置管理计划附件由项目经理审批后发布。A地、B地两地协同的场景下，把权限表的维护做成周更制度，新人进场一周内就能开好账号，不需要反复催。

3.3 异地协同的配置管理约束

模板提到项目分两地同时开展、配置管理统一归口执行。异地协同场景下，配置管理最容易出现的问题是“文件访问慢、权限分散、版本不一致”。实践上要提前做三件事：其一，配置库物理上只放一处，其他地点的项目成员通过网络授权访问文件服务器；其二，访问权限由配置管理员统一开通，账号准入按权限登记表执行，新需求统一走申请流程；其三，对tags目录的访问尽量收紧为只读，发布版本的复盘必须基于基线目录进行。

配置管理还必须定义基线状态。信息化项目至少需要定义四条基线：需求基线（需求规格说明书评审通过后建立）、设计基线（详细设计评审通过后建立）、测试基线（测试报告输出后建立）、发布基线（试运行通过后建立）。每一次基线建立都必须在SVN的tags目录打标签，并同步一条变更记录到配置管理台账。基线建立后如需变更，必须走变更控制流程：由提出人填写变更申请，执行项目经理评估影响面，专家组与项目经理审批后，配置管理员在分支上实施变更，并重新走测试与发布。

4. 计划与沟通制度：会议和邮件响应时效落地成节奏

项目章程里写计划，最忌讳的是只画一张甘特图，没有里程碑和检查点。原文第5章给出了按“一级部署、二级管控、三级应用”的要求结合实际情况制定计划的框架，但真正把计划变成可执行节奏的，是配置管理手段、沟通制度与会议制度三者的配合。计划不是某一个人在启动会上排出来的，它是整个团队从目标拆解、任务分解到责任落实的一次集体动作。

4.1 里程碑和检查点怎么拆

基于模板的项目目标，信息化项目的进度计划至少要包含以下几个里程碑：需求调研完成与需求基线确立、系统设计与评审完成、开发完成并进入测试、数据迁移完成、试运行启动、试运行报告输出、验收评审。每个里程碑都要挂一个“产出物”，也就是验收证据，而不仅是“完成某事”的描述。

在计划编制时，要留意信息化项目的两个常见偏差：一是把“开发完成”当作唯一节点，忽略了与数据迁移并行的时间窗口；二是没有把“验收资料编制”写进计划，导致验收阶段材料缺失。这条经验值得强调：验收资料应与其他交付物同步生成，而不是在验收前临时突击。章程里集成组“配合甲方进行项目验收工作”这一条，实际执行时要前置到试运行阶段，即边试运行边归档材料，包括用户签字确认单、培训签到表、月报样例、问题反馈处理记录。

4.2 会议制度要和产出物绑定

模板第7.1节给出了一张沟通机制表，包括项目工作例会、项目沟通评审会议、小组内部讨论、电子邮件、项目成果报告会五类渠道。表格本身不复杂，实施时真正起作用的是给每一类沟通定义一个明确的产出物，并约定产出物的受控状态。

会议纪要管理的细节决定了沟通是否闭环。每次例会后形成的纪要，要明确列出“待办事项清单”，包括事项名称、责任人、计划完成时间、优先级。待办事项的跟踪责任落在执行项目经理身上，每次例会先过一遍上一期的待办，没完成的说明原因并重新确定时限。某导师带项目时常说一句话：没有待办清单的会议纪要等于白开。这句经验放在信息化项目里尤其成立，开发和数据迁移阶段杂事多，口头答应的事转头就忘。

4.3 邮件响应时效的设计

模板第7.2节给出的邮件制度非常实战，上午发的邮件当天回复，下午发的邮件第二天中午前回复；一天之内不能解决的问题升级到上一级，三天不能解决直接报管理班子。这套时效机制是把沟通成本显性化，让问题不会在某个邮箱角落里躺一周。

实际操作中有个常见误用，就是把邮件制度当成“所有沟通以邮件为准”。邮件适合传递信息和留痕，但不适合做复杂问题的讨论，一来一回耗时长且容易产生误解。正确姿势是：邮件做正式通知和结果确认，过程讨论放在站会或小组内部讨论里，讨论结论再回到邮件里做通知和签字。模板里明确“电子邮件是辅助渠道”，就是这个意思。

要把邮件制度真正执行下去，还得定义好收件人和抄送规则。涉及客户资料的需求确认类邮件，收件人写客户对接人，抄送执行项目经理和现场调研组负责人；涉及管理文件的周报月报，收件人写执行项目经理，抄送项目经理和配置管理组，方便归档；涉及变更申请的邮件，收件人写配置管理组，抄送项目经理和专家组。明确抄送规则，信息不出圈，责任人也不会漏。

5. 避坑：四类常见翻车点与风险对策

章程第10章写了两类风险：技术风险，用新框架、开发人员不熟悉、周期短来描述；配合风险，由多个单位人员组成、工作方式差异导致。这两类风险放在绝大多数信息化项目里都成立。但结合这一类管理系统的实施实践，真正导致项目失控的坑还有不少没被写进章程，这里把最高频的四类列出来，按现象、原因、解决的顺序说明，都是我经历过或者见过别人踩过的。

5.1 新框架在短周期里翻车

现象：开发启动后两周，第一轮功能联调时发现框架的权限组件与甲方的组织架构模型不匹配，原计划一周的模块联调拖了三周，开发团队被迫绕过框架封装一层适配层，额外产生大量返工。

原因：团队对新框架的了解停留在“之前培训过”的层面，没有在正式开发前做一次完整的技术验证。章程里写了“邀请培训”，但培训只能解决知识点普及，解决不了真实业务场景下的适配问题。

解决：在任何使用新框架的项目里，正式开发前先安排一个短周期的技术预研迭代。选取一个最小的业务功能模块作为试点，比如组织架构管理中的“部门新增”功能，用新框架从建表、服务、接口到前端页面临摹一遍完整链路。预研结束时输出一份框架验证报告，列明可用的功能清单、不可用的部分、临时绕行方案。这份报告作为设计评审的输入，让专家组和研发组都清楚新框架的边界在哪。我一般会把技术预研的时间留出总项目工期的8%到10%，短周期项目不要抱有“边做边摸框架”的幻想。

5.2 多单位配合时的口径不一致

现象：章程里明确了“开诚布公、坦诚合作、紧密配合”，但实际推进时，各配合单位的项目经理每周例会都来，会上都表态支持，回去后各自的内部排期却和项目计划对不上，关键数据的提供时间一拖再拖。

原因：多单位协作时，各方都有自己的内部项目优先级。章程里的配合原则是态度层面的，没有落到操作层面的强约束；项目组只依赖工作例会做协调，会议结束后缺乏对配合单位内部计划的影响力。

解决：项目组的对策是建立一页纸的“协作共识单”，内容包含验收标准、里程碑时间、数据提供清单、例会时间和文档模板库入口。这份共识单在启动会上由项目经理向各个配合单位负责人逐条宣贯，并让每一位负责人在打印版上签字确认。执行过程中每周五刷新一版，标出未按计划提供数据的单位名称和下一条关键路径上的影响。把“配合”从口号变成一个周更的追踪表，配合单位就没办法装作不知道。

5.3 会议纪要不签字不归档

现象：评审会上专家提出若干条修改意见，开发人员当场理解成“按大家说的意思改就行”，没有形成受控纪要；两周后开发完成提交评审，甲方不认，理由是“当时同意的是另一个方案”。

原因：会议结论没有进入配置管理流程。沟通产生的结果停留在口头层面，未形成文件，也就没有进入“受控”状态。项目章程里写了“重要决议由项目经理或项目经理授权人签字后发送执行”，但团队往往只在重大项目节点才这么做，日常评审会直接跳过签字步骤。

解决：把所有评审会统一套用一套最小化纪要模板，无论大小会议都要求包含：会议时间地点、参会人员、讨论议题、达成结论、待办事项及责任人和时限。会议结束后24小时内发送纪要，相关人员在一天内确认。凡涉及方案选择和范围调整的决议，必须打印签字后扫描归档到SVN的01-项目管理目录。对于没有签字的纪要，执行项目经理可以拒绝纳入下一周期的工作安排。这条规则坚持执行两轮后，团队成员就会形成“开会必出签字纪要”的条件反射。

5.4 验收材料滞后导致项目延期

现象：试运行已经稳定了，系统功能也都正常，但验收申请提交后，甲方发现缺少数据迁移确认单、用户培训签到表、月报样例等过程性文档，验收会被迫延后。

原因：章程里写了集成组“配合甲方进行项目验收工作”，但没有把验收材料的准备工作拆解成日常动作，导致项目组默认“验收资料验收前再准备就行”。文档型配置项都是在过程中产生的东西，事后补签不仅耗时，真实性还会被质疑。

解决：我的习惯是把“验收材料清单”作为一项独立配置项，在项目启动第一周就由配置管理组结合章程的成功标准拟出来，放到SVN的01-项目管理目录。清单按照第2章的验收证据要求去建，试运行开始后每周更新一次证据文件，同步标注已完成、待补、待签三种状态。执行项目经理每周例会抽出五分钟过一遍材料状态，保证验收材料与试运行同步收口。从那以后，我每次启动项目都强制把验收证据清单放在项目计划的第一屏位置，因为它才是整个章程真正落地到每一天的地方。

6. 把章程模板裁剪成自己的版本：五个回收动作

拿到这份模板文档后，最忌讳的做法是改个项目名称和日期就发布。章程的价值在于它成为项目后续所有决策的统一入口，而要做到这一点，必须让模板里的内容对齐自己的组织结构和验收语境。我的做法是组织一次启动会后的“章程裁剪会”，大约半天时间，把模板逐节过一遍，完成五个动作。

第一个动作是替换标题里的组织域。“某集团”改成甲方实际名称，“某公司”改成实施方名称，涉及两地协同的描述改成自己项目实际涉及的地点代号。替换的同时，把适用范围一节里“所有的项目组成员均应按照规范要求开展相关工作”这句话保留，增加一句“新进入项目组人员应在进场后两日内完成章程阅读并签字确认”，让适用范围具备强制力。

第二个动作是把第2章的“目标与成功标准”扩展为一张验收证据表。逐条对照原模板的三条成功标准，按第2章的四级拆法写出自己的可验证检查项、验证方法和证据文件名，然后发给集成组和配置管理组联合确认。证据表一旦定稿，就直接成为验收工作的底座。

第三个动作是拉通角色职责表。把原模板的七个角色名称列出来，旁边写上自己项目对应的人员姓名或角色代号，同时确认每个角色至少有一名主要负责人和一名替补。关键成员联系清单这页必须真实填写，不能空着。执行阶段一旦出现人员变动，更新后的清单要在一个工作日内重新发布。

第四个动作是建立配置管理目录。参考第3章的目录结构，在SVN中创建trunk、branches、tags三个一级目录以及docs、code下的二级目录，再放两份初始文件进去：一份是配置管理计划模板，一份是权限登记表。目录和初始文件都建立后，让每个成员完成一次SVN检出操作才算完成配置管理启动。

第五个动作是约定变更入口。在章程里补一段话：涉及范围、进度、质量、需求、设计的任何变更，必须以变更申请单形式提交配置管理组，评估影响后由执行项目经理和项目经理审批。变更获批后，相关文档和代码统一在分支上实施，完成后合并回主干。不管项目周期多紧，这条入口不能省。

模板只是起点，真正让章程生效的是你愿意把它当成变更入口来用，而不是存档文件。从我的个人习惯来说，现在每次做信息化项目管理系统的启动，都会先花半天把章程拉通，先填上验收证据表和角色清单，再谈甘特图。这个过程重复几次后，你会发现自己对项目的判断力明显比过去只盯进度时强得多，希望帮到你。

本文还有配套的精品资源，点击获取