标准项目实施方法论(内部参考)_V2.5.doc

项目实施规范V2.0：总纲

保密程度：仅限内部使用

vTradEx项目实施
实施方法论
Project Implementation
Methodology

唯智信息技术有限公司
2003年10月

目录索引

1. 概述 2
1.1. 总原则 2
1.2. 项目实施阶段工作目标定义 2
2. 项目实施规范 3
2.1. 团队确定（Project Team Setup） 3
2.2. 项目会议（Meeting） 3
2.3. 项目进度报告（Status Report） 4
2.4. 会议纪要（Meeting Minutes） 4
2.5. 变更控制（Meeting Minutes） 4
2.6. 报修控制（Bug Report） 5
2.7. APMS使用（Control Your Project） 5
2.8. 三人制设计模式（Treble Design） 5

1. 概述
成功的项目实施是一个复杂的工程问题，存在一定风险的；为了最大程度降低风险，唯智公司在长期的项目实践中总结出（逐步完善）一套能避免或把风险降为最低的方法：项目实施方法论。同时按照规范进行项目管理，能够保证不同能力的项目经理能够在面对客户的时候，提供同样的专业服务，能够提高客户满意程度。
各种类型的项目实施有其特点， 都有自己的一套规范和文档模版。本规范中规定的各项内容和模版是所有项目都需要的共性问题。 本规范是所有其他规范的基础，必须得到切实执行。
实施方法论保证了分析人员能够按照一种比较和的方法有条不紊的进行分析设计工作，同时留下足够的文档，帮助后期开发小组工作。 但是必须注意，实施方法论无法取代分析设计人员对于客户业务的直观理解和创造性的思维。不动脑筋的进行文档填写工作是不能满足公司要求的。也会对于项目造成严重损害。

1.1. 总原则
l 项目尽可能采用迭代方式实施
l 尽可能引入客户参与项目的各个阶段，让客户项目小组的人员成为帮助项目成功的战友，而不是站在相反方向，防止甲方利益受损的敌人
l 对于项目进行严格的过程控制
l 项目文档需要简明扼要，多使用表格，清单的方式，避免大段的描述性文档，各种会议纪要，进度报告等过程性文档原则性不应该超过2-3页

1.2. 项目实施阶段工作目标定义
阶 段
目 标
业务需求分析阶段
获取详细的用户需求
客户充分参与，对于需要开发或者实施系统的功能有足够的了解
建立和客户的良好关系
保护公司利益，排除不合理需求
设计阶段

设计实现需求的技术方案
制定测试方案
开发阶段
根据设计，进行迭代开发
开发阶段包含单元测试和功能测试
测试验收阶段
对系统进行全方位测试
通过客户验收测试
实施阶段
将系统交给客户使用
充分培训客户，帮助客户成功使用系统
维护与扩展阶段
解决客户发现的问题
提供客户提出的新的功能修改服务

2. 项目实施规范
2.1. 团队确定（Project Team Setup）
项目启动后，首要任务是成立一个由乙方，甲方信息部，甲方业务部门人员构成的项目小组。把人员的联系方式整理成一个清单是一个不错的主意。
[ 附属文档 ] 项目小组成员表.doc

2.2. 项目整体计划制定（Milestone Schedule）
项目启动后在合同SOW中规定的项目进度就需要进行进一步细化成为项目计划， 该计划是比SOW计划略细的大计划，侧重点还是对于Milestone检查点的计划。 采用MS Project 编写。 编写完成后和客户确定计划，并发给技术部经理留档。 此文件将作为项目重要的控制文件， 项目经理必须确保每个里程碑都按时完成，如果无法及时完成，需要提前知会客户和技术部经理，调整计划。

2.3. 需求定义（Requirement Definition）
项目启动后，需要根据合同中的SOW进行细化，将客户大块的需求细化为可以开发的详细功能定义。项目小组需要填写此文档，并通过公内部审核，以及获得客户签字确认，此文档将取代合同的SOW作为项目验收的标准。对于一些特殊项目，项目小组可以考虑引入一些流程图等方式，增强需求定义文档的表现力和说明力。
[ 附属文档 ] 需求定义文档.doc

2.4. 项目会议（Meeting）

成功会议要点：
l 所有会议需要简短，目的明确。
l 会议不是进行重要问题的讨论和争论的场合，所有重要决定需要事先和客户关键人物达成共识，在会上仅作为汇报和正式确认，逼迫部分问题客户就范
l 主动控制会议进程，不要被客户牵着鼻子走。 会议上，谁的准备充分，谁就会占主导地位，更加容易达成自己的目的

Kick Off Meeting: 项目开始的时候，大家在一起开一个简短的会议，会议上主要介绍项目的工作目标，各方的责任，以及下一阶段的详细工作安排。 通过Kick Off 会议能够让大家意识到项目已经开始，及早进入状态。 Kick Off 会议也是大家认识的一个很好的机会。 如有可能尽可能要求该项目销售，公司高层参与。 会议要简短，开完会最好安排一起吃饭。
项目例会: 项目开始后，和客户确定每周一次的项目会议的时间。 一般安排在周五下午或者周一上午。 由客户根据自己方便的时间选择一个。 项目例会的需要准备项目进度报告，提前发给客户，在会上讨论。会后需要整理会议纪要。如果会议上涉及重要决策，需要让客户签字确认。
里程碑验收会议: 当项目达到里程碑阶段的时候，如有可能组织双方高层参与会议。 主要是总结前期工作成果，以及下一阶段的安排。 里程碑验收会议对于收款和改进客户高层（往往平时根本不知道项目情况）的满意度有很重大的作用。 里程碑验收会议如有可能让客户项目经理和主要参与的用户负责汇报。 我方项目经理仅作为主持人，控制会议进程。需要事先准备PPT。

2.5. 项目进度报告（Status Report）
项目例会前，需要准备项目进度报告。项目进度报告反映了前期工作进展情况， 下一阶段工作计划，会上需要讨论的议题，以及风险分析。进度报告是帮助客户了解项目进程，以及安排客户协同工作的有效工具。
[ 附属文档 ] 项目进度报告模版.doc

2.6. 会议纪要（Meeting Minutes）
项目会议，或者某些突发性的讨论会议后，项目经理必须准备会议纪要。会议纪要要求精简，能够反映问题。 特别是对于项目有很大影响的决议必须在会议纪要上得到反映。 会议纪要是逐步影响客户，向有利于我方的方向发展的重要工具。 会议纪要的措辞和写法非常重要。 会议纪要中不要出现谁发言，谈了什么的流水帐， 而要记录会议中决定了什么（某些情况下可以有选择的纪录会议纪要）。用户签过字的会议纪要需要归档保存。
[ 附属文档 ] 会议纪要模版.doc

2.7. 变更控制（Change Control）
项目中一定会发生客户要求变更需求的情况。任何变更无论大小，项目经理必须要求客户填写（或者帮助客户填写）变更控制表。 变更控制文档包含变更原因， 变更内容，实现方案，估算工作量和对于项目进度影响的内容。
[ 附属文档 ] 变更确认书模版.doc

对于需要向客户收费的变更，需要在完成变更确认书后，交由技术部经理填写项目服务协议，并由销售人员填写服务收费后和客户负责人进行签署。
[ 附属文档 ] 服务协议.doc

2.8. 报修控制（Bug Report）
客户发现软件质量问题，需要填写（或者项目经理帮助填写）故障报修文档。
[ 附属文档 ] 故障报修模版.doc

2.9. 上线通知（Release Notice）
当系统上线后，无论是bug修改还是迭代的功能更新之前都需要编写上线通知文档，让客户知道本次软件更新的目的，需要提前准备的内容以及对于业务操作的影响。
[ 附属文档 ] 系统上线通知模版.doc

2.10. 公司周末例会（Internal Weekly Meeting）

参加人员：
l 当前承担某项目的管理工作的项目经理；
主要内容：
l review 所有apms 中需要本周完成的工作的情况， 确定周末是否需要加班；
l 提出下周工作的清单， 便于公司统一安排人力资源（建议提前建入apms 系统， 可以不安排人员由公司统一安排， 也可以指定人员， 视情况而定）
时间安排：
l 周五下午 5：00 -- 6：00
l 外地项目经理通过电话提前进行会议，时间大概在 4：00 -- 5：00 左右。
l 如果会议时间和项目其他安排（例如已经安排的客户会议）冲突， 请提前通知技术部经理，提前单独review。

2.11. APMS使用（Control Your Project）
公司所有项目都必须采用APMS进行项目管理。
l 提前安排计划
l 细粒度过程控制

2.12. 三人制设计模式（Treble Design）
项目设计过程原则上需要有三个人参与
l 项目经理
l 开发负责人或者指定的SA
l 项目助理（从项目团终挑选一人）
6
唯智信息技术有限公司 2024/12/30 周一