项目管理方法.doc

上海葡萄城信息技术有限公司
项目管理方法

目录
1 葡萄城通过CMMI4级 3
2 项目阶段安排 4
2.1 项目启动阶段 4
2.2 需求调研与确认阶段 4
2.3 设计阶段 5
2.4 系统客户化开发阶段 5
2.5 系统测试阶段 6
2.5.1 子系统调试及系统整体测试 6
2.5.2 用户验收测试 6
2.6 培训及知识转移 8
2.7 售后服务支持与技术转移 8
2.7.1 缺陷修复 8
2.7.2 服务支持形式 9
2.7.3 售后服务期限和收费标准 9
2.7.4 售后服务维护支持流程： 10
2.7.5 技术转移 11
3 风险管理 12
4 质量管理 14
5 沟通策略 17
6 变更管理 19

1 葡萄城通过CMMI4级
CMMI (Capability Maturity Model - Integrated，软件能力成熟度模型) 是美国国防部在1984年委托美国卡内基梅隆大学 (Carnegie Mellon University) 的软件工程学院 (Software Engineering Institute, SEI) 所进行的一项研究成果，其目的是用来评估及改善软件公司的软件开发过程及软件开发能力，并且协助软件开发者连续改善软件流程成熟架构及软件品质，进而提高软件开发项目及软件公司的软件研发实行管理能力，达成软件研发实行的功能对的、缩短开发时程、减少成本及保证品质等目的。
CMMI共分为5级，5级为最高。目前CMMI已经成为国际通行的评估软件公司软件项目研发和实行管理过程能力的最高标准。葡萄城公司于2023年通过CMMI4级评估，是迄今为止微软在中国地区唯一通过CMMI 4级评估的金牌合作伙伴。CMMI4级评估的通过也标志着葡萄城公司内部已经形成和具有了在系统工程、项目管理、供应商管理、维护服务等过程领域的完善制度和综合能力。同时，在CMMI4级水平上，公司的管理流程也实现了量化与数字化。通过量化技术来实现流程的稳定性以及管理的精度，减少项目实行在质量上的波动。

2 项目阶段安排
项目各阶段安排说明如下：
2.1 项目启动阶段
项目管理文档准备：
各种项目管理文档的格式规定与准备，涉及项目计划草案，质量管理文档，风险管理文档，交流管理文档，变化管理文档，配置管理文档，会议记录，问题记录，任务列表，开发工作制度与规定等等；
硬件环境准备：
开发环境硬件准备，系统准备，网络准备；
开发软件设备准备：
开发软件的安装与调试，涉及数据库，中间件，编程工具，测试工具，性能监测工具，备份工具等等；
辅助环境软件准备：
开发工具，数据库系统，编辑工具等等，建立内部网络系统。
在这一阶段，葡萄城信息技术有限公司项目经理与系统架构师将负责贯彻上述各项任务。
2.2 需求调研与确认阶段
在系统集成项目开始之前，业务征询小组将就公司的总体业务范围展开征询，从大的方向上确认系统的业务范围，重要征询工作涉及：
· 需求了解和建议
· 流程设计和确认
从这个阶段的工作成果将会作为下一个阶段的输入信息，为具体的系统需求提供指导。
项目经理和业务顾问整理需求说明书，明确理解需求，与行业专家、业务顾问组交流、确认，制定《需求确认书》 ，并得到客户项目小组的确认。
在这一阶段，葡萄城信息技术有限公司的项目经理与系统架构师将与客户的项目组成员密切配合以贯彻上述各项任务，客户应尽快确认项目实行的设计规范、需求分析。
2.3 设计阶段
设计阶段作为项目的另一个分支，和业务征询阶段并行进行完毕系统总体设计、逻辑设计，定义和具体描述各子系统功能和接口，完善分析与设计的成果，生成部分源代码模板，编写功能测试计划等。
在这一阶段，葡萄城公司会起主导作用，并欢迎系统未来的维护人员也参与部分的设计以便将来更好地维护该系统。
2.4 系统客户化开发阶段
各个子系统分别进行编程，实现定义的业务和管理功能，进行单元测试，开发小组内组合测试。
在这一阶段，葡萄城公司会起主导作用，并欢迎系统未来的维护人员也参与部分的开发以便将来更好地维护该系统。
2.5 系统测试阶段
2.5.1 子系统调试及系统整体测试
每一个子系统完毕后，我们会进行系统的整体测试，以保证系统可以达成最高的质量。在进行整体测试前，子系统调试计划应先行制定，涉及测试的准则、测试项目及范围。计划要保证每一个功能和每一个解决都通过严格的测试，涉及一些异常解决如数据不全，数据类别有误码率或丢失等。调试也应涉及子系统每一个程序的响应效率(即响应时间)。对子系统而言，通过测试的子系统是一个经行考验的子系统，在编码时产生的错误应在这阶段中侦察出来，并加以纠正。纠正后要反覆进行重试，以保证问题得到解决，并不影响到原先已通过的调试。这个阶段完毕时提交的是子系统及整体测试调试报告表，以证明系统通过严谨的调试。
2.5.2 用户验收测试
通过单元测试及系统测试后，用户验收测试是软件投产前最重要的一环。用户验收测试最终的目的是验证软件是否按用户需求而设计，并且功能是可以满足业务的需求。因此在这测试阶段，参与者应当是资深的业务人员和曾经参与制定用户需求的工作人员。
在用户验收测试开始之前，参与的队伍应按照功能规格书配合业务上的需要拟定测试计划及方案，以保证在测试过程中可以有系统地进行测试，并让各有关支持队伍了解职责所在和安排资源。

l 用户验收测试应当包含以下四大范畴：
– 验证系统的监控和保安手段符合客户业务的需求和标准
– 验证系统的功能符合功能规格书和在整个开发过程中产生的提交件所记录的细节
– 验证系统的输出，涉及屏幕上的数据、数据库的数据贮存、报表等均完整及对的
在测试过程中，还要切实执行问题管理和变更管理，以使测试出的问题及缪误得到对的的反映及跟进。而因应问题报告而修改的编码亦是通过系统测试成功后才转移至验收测试环境中测试，以保证对的的版本控制。
l 这个阶段完毕时提交的涉及：
– 验收测试计划书
– 测试案例及执行结果
– 测试报告
– 问题清单及跟进记录
– 测试所产生的输出
– 测实验收报告
这一阶段的工作需要葡萄城公司和客户积极配合完毕，客户应及时对验收测试的内容加以确认。
2.6 培训及知识转移
葡萄城在项目的进行中会采用教室培训和工作实践相结合的方式进行培训。其目的旨在使客户的人员可以有足够的知识和技能去良好的使用和维护系统。
可交付物涉及：
系统用户培训教材
管理员培训教材
培训涉及：
系统用户平常操作培训
系统管理员和维护人员培训
2.7 售后服务支持与技术转移
自签订系统验收报告之日起，系统正式进入应用系统的维护运营阶段。葡萄城将对本协议下新开发或修改的软件提供6个月的免费维护和支持服务。在免费维护期结束后，假如需要，葡萄城和客户可就维护项目签署此外的维护协议。
2.7.1 缺陷修复
GrapeCity将对交付系统的缺陷、暇辟、故障予以及时修复，以保障系统按照原先的设计方式正常地运营。GrapeCity将一方面通过电话和电子邮件了解客户碰到的问题。经客户允许，GrapeCity还可通过Terminal的方式对系统进行远程维护和监控。
2.7.2 服务支持形式
葡萄城在免费维护期内将以下面两种形式提供相应的技术支持：
热线支持
GrapeCity对下列问题提供5 X 8的热线电话支持服务：
– 系统产生的问题
– 客户在操作过程中产生的问题征询
– 客户对于系统功能的征询
– 系统平常维护涉及的技术征询
远程支持服务
在电话技术支持不能解决问题时，客户可开通远程访问方式，葡萄城支持远程服务。
现场支持服务
在电话技术支持或远程支持服务不能解决问题时，葡萄城将提供现场支持服务。
2.7.3 售后服务期限和收费标准
上述提供的售后服务在系统正式上线（从用户验收系统开始计算）后6个月内为免费，超过6个月以后按照每年度20%的实行费用进行收费。

2.7.4 售后服务维护支持流程：
l 应用系统出现故障；
客户维护人员进行初步故障定位，在拟定为本项目开发的应用系统故障后，立即电话联系葡萄城公司的项目维护负责人；
当接受到客户关于故障报告的电话请求后，葡萄城将立即开始评估和调查问题因素，并根据事件的严重限度，决定技术支持形式。假如的确需要远程访问支持，将尽快向客户提出远程支持请求，获得统一后，安排维护人员进行问题调查。
l 应用系统维护范围涉及：
– 系统应用故障分析
– 系统应用故障更正
l 应用系统维护范围不涉及以下内容：
– 用户自备的软、硬件的维护
– 系统软件（如操作系统、防病毒软件）维护
– 数据库维护、备份和恢复
– 平常系统管理
– 平常备份和恢复
– 应用系统以外的其它任务
2.7.5 技术转移
GrapeCity将采用如下几种方法进行技术转移：
l 在项目实行过程中，客户的IT技术人员可以全程参与技术设计、客户化和部署的过程，以便对系统的技术细节有全面把握
l 项目部署后，GrapeCity将提供具体的系统用户手册和管理员手册，帮助客户IT技术人员掌握系统使用和管理方法
l 在培训过程中，GrapeCity可以提供具体的管理员培训和客户化培训，帮助客户IT技术人员进一步了解和掌握系统管理和客户化所需要的技术

3 风险管理
l 目的
风险管理的目的是最大限度地减少项目中各方面也许出现的负面影响，从而尽也许地减小项目的风险。项目的风险管理是通过以下一系列环节来实现的：一方面，找出项目中也许引起风险的因素；然后，估计出也许引起的影响的限度；最后制定出相应的防止措施。
基于对客户需求的理解、以及GrapeCity在OA方案实行方面长期积累的经验，我们认为该项目也许存在以下风险：
l 需求变更
– 在项目过程中出现频繁的需求变更，从而导致项目范围蔓延、打击双方项目团队的士气；
– 应对措施：在项目需求调研阶段，需要客户关键用户参与、积极配合，双方约定需求变更控制流程，记录、归档需求变更申请，减少需求变更的随意性；
l 沟通不佳
– 项目组与项目各干系人沟通不佳是影响项目顺利进展的一个非常重要的因素。
– 应对措施：项目建设之初就和项目各方约定好沟通的渠道和方式、项目建设过程中多和项目各干系方交流和沟通，具体沟通策略见下文描述；
l 缺少高层领导支持
– 公司高层对项目的足够重视，以及在项目中连续的支持；
– 应对措施：积极争取领导对项目的重视、保证和领导的沟通渠道畅通、经常向领导报告工作进展。

4 质量管理
l 概述
本系统项目涉及多方面技术和产品，质量管理和控制是关系到项目能否成功实行且顺利交付的重要保证手段，是对每一个参与厂商和集成商的必要规定。
以下定义了每个部件及文档的质量规定。此外，我们也同时进行质量监控以保证质量规定的实现。
l 质量管理涉及以下方面：
Ø 成本
对客户来说，成本控制极其重要。协议的条件和条款对成本控制的范围与限度起到了决定性的作用。成本控制的范围与限度将在以后的项目计划中具体说明。
Ø 时间
对客户来说，进度控制极其重要。协议的条件和条款对进度控制的范围与限度起到了决定性的作用。进度控制的范围与限度将在以后的项目计划中具体说明
Ø 质量规定
质量规定将在以后的项目计划中具体说明。
Ø 质量标准
所有项目文档与项目成果的质量标准将在以后的项目计划中具体说明。
Ø 质量控制
质量控制的范围与限度将在以后的项目计划中具体说明
质量管理由项目组中独立的质量控制小组控制实行。所有提交结果必须符合质量管理原则，必须通过质量控制小组审查；如提交成果不能满足质量规定，则由相应负责人负责返工；如提交成果多次返工后仍不能满足质量规定，则问题升级，由高级管理人员负责解决。
l 质量管理类型小结：
– 自检
– 同事互检
– 流程检查
– 分角色流程检查
– 正规审查
– 集中审查
– 反馈
– 提交前审查
l 测试
– 产品实行测试
– 软件开发测试
– 性能测试
– 安全性测试
– 整体系统测试
开发组完毕的软件必须通过测试组的测试，测试计划由开发组与测试组共同制定。
测试中出现的所有问题将由相应的负责小组完毕修改，并且重新进行测试。
所开发软件的每一个版本在试运营之前必须通过测试小组的彻底的系统测试，测试计划有开发组与测试组共同制定。
l 进度控制
项目经理定期提交一份项目进度安排，经管理委员会批准。
项目组成员每周提交个人工作进度报告。
在每次项目例会上，项目经理需要与小组长讨论项目进度情况，对不能准时完毕的部分要及时制定方案，及时解决。
在每次客户例会上，项目经理必须向客户报告项目进度情况，假如有严重的延时，则需要向项目管理委员会报告，以便寻求解决办法。
更改后的项目计划必须经管理委员会通过方可实行。
l 质量保证
项目整体质量的检查将会周期性地进行。质量保证经理负责在每个阶段的中期和后期进行正规的质量审查。

5 沟通策略
l 项目状态报告
– 发送人：实行方项目经理
– 接受人：客户方项目经理
– 抄送：双方项目组成员、实行经理
– 发送时间：每周五下午（法定假期，如5.1等除外）
– 内容：本周项目进度、人力资源、风险、问题介绍
– 目的：向客户方、项目重要干系人报告项目状态
l 项目组周会
– 会议发起人：实行方项目经理
– 会议参与人：实行方项目组全体成员
– 会议时间：每周五上午11:00 --- 12:00
– 会议议题：(1)本周项目状态回顾；(2)项目问题、风险检查；(3)下周工作安排；
– 说明：(1)PM会后整理<项目会议纪要>，发送给与会人员；(2)对于会议形成的行动项，将其完善到项目进度表中，进行跟踪、管理；
l 里程碑会议
– 会议发起人：实行方项目经理
– 会议参与人：实行方项目组全体成员
– 会议时间：某个项目里程碑实现之后两个工作日之内
– 会议议题：(1)前一项目里程碑完毕情况、经验教训总结；(2)下一里程碑工作计划；
– 说明：若里程碑会议时间与项目组周会时间比较接近，考虑将两者合并；
l 不定期交流
– 交流方式：电话、电子邮件、网络会议等；
– 议题：根据项目需要临时拟定；
– 说明：对于重要的会议，由实行方项目经理在会后形成<项目会议纪要>，发送给与会人员；

6 变更管理
变更控制概述
很多方面的因素都会导致变化，从内部环境来讲，客户需求的变化，技术方法的变化，未知因素的出现，节省资金、减少风险、缩短时限或提高工程的质量等都是项目实行过程中的变化因素。这些变化会使得方案在功能上有些增长或减少，因而需要在设计和实行过程中严格控制。
变更控制流程
由用户和葡萄城的人员共同组成变化控制小组，组长由葡萄城项目经理担任。
对变化的审核和确认可依据下面的流程进行控制：
当一方发现有进行改变的需要时，应先非正式地以书面或口头方式告知另一方；假如时间允许，双方应对此进行讨论或互换备忘录。
在讨论或互换备忘录之后，双方应就是否正式地解决该变化及由哪方实行变化控制这些问题达成共识。对没有得到非正式的讨论或备忘录的互换结果之前，由单方开始实行变化控制的情况，随时记录下来。
申请变更方应填写一份变更申请表，在5个工作日以内，假如情况紧急的话，也许在更短的时间内，负责变更反映：
告知申请变更方是无条件还是有条件地（根据申请变更方的确认）正式接受该变更申请，及其对项目进度和财务的潜在影响；或告知变更申请方拒绝该变化申请，并说明拒绝理由；或告知变更申请方需附加信息
假如是以无条件或经确认的条件方式接受正式的变化申请，且变化相对较小、无太大的经济影响或进度影响，双方在申请和确认书上签字，那么无需正式的书面说明，双方即可继续下面的工作。
假如一方任务必需要有正式的书面说明，那么在实行工作开展之前，必需拟定说明并由双方签字。
变化控制小组由用户和GrapeCity双方共同组成，其职责是评估正式的变化申请，并对任何变化的实行授权。在变化申请的调查阶段，应重点分析变化对项目进度的影响和资金的影响，并在申请表的相应部分记录下来。同样重要的是，必须通过变化控制小组才干批准这些在时间和资金上的变化，并且必须为变化的实行提供书面的说明。