项目实施过程

 

• 项目立项

1. 业务不成熟的情况下（包括业务部门对新的管理标准，业务流程不熟悉），采购专业的课程、培训和咨询。
2. 如果涉及的系统改造点较多，可能影响到未来的测试工作，需要在合同中注明需要增加测试人员。
3. 招标需求调研环节，需求室参与和后期项目需求调研的人员不一致问题。
4. 项目招标时，能够驻场后按照CMMI3的标准实施的问题需要和公司方前期进行交流。
5. 项目调研后，形成的业务需求书的详细程度问题（便于后期做工作量和进度估算）。

• 项目启动

1. 项目启动，项目经理做项目生命周期选择，过程裁剪，报给EPG组审核。
2. 项目经理组织开发人员做工作量估算，做项目总体工作量的估计，估计里程碑进度和人力、软件、硬件、网络资源。其中人力资源需要根据估算的假设条件，对人员的素质和能力进行规定。
3. 项目经理根据风险库识别早期的风险。
4. 启动签报。
5. 项目经理根据项目的实际情况，准备好《项目章程》（可以是PPT），召开项目启动会议。

• 软件需求开发

1. 框架性需求不够仔细，需要在项目启动前后重新做需求调研，项目经理在不能确定完整的项目进度计划时，需要初拟一份《需求调研计划》指导业务组人员进行需求调研（后期可以回溯需求调研是否有人员遗漏，需求到底是谁提出的，便于验收）。
2. 调研没有针对性和方法，所以需要整理调研问题清单和业务人员深入交流。
3. 业务不成熟的情况下，如何理清各个需求责任人的工作边界。梳理业务需求的清单，标记需求的成熟度，然后采取不同的管理策略（该学习的学习，该讨论的讨论）。
4. 购买软件产品做定制化开发的项目，需要理清购买软件产品和本地化需求之间的差异，比如合同上的功能清单与用户需求说明书的功能清单不一致时，要以用户需求说明书为基准，因此不一致的地方需要说明，做还是不做。梳理系统功能需求清单，标记需求的状态，然后采取不同的管理策略。
5. 瀑布式和增量式开发需求的评审和确认可以分多次组内评审，降低评审的难度，然后最后做一次正式评审（解决专家邀请困难的问题）。
6. 迭代开发时需求的评审和确认需要注意在迭代过程中的需求变更问题。第二次的需求评审应该涵盖对第一次评审后提出的需求变更。

• 项目计划

1. 在需求调研清楚以后，项目经理做WBS分解（每个工作包不要超过40人时），然后按照启动签报安排的资源进行每项活动的资源分配，调整活动间的依赖关系，编排进度，进度计划的主要目的是可以指导每个人干自己的活。
2. 进度计划编制好后，项目经理可以着手编制《项目总体计划》。项目总体计划中的里程碑应该和进度计划保持一致，可以与估算的里程碑截止日期有偏差，但是需要获得项目发起人的同意。
3. 《项目总体计划》要规定项目的组织结构，人员的技能要求。通过分析人员技能要求，从而推导出项目的培训需求和培训计划。总体计划根据进度里程碑计划和配置管理计划中的基线，规定哪些文档或代码，什么时间，哪些人员要参与评审，同时确定评审的规格（正式评审、组内评审、书面轮查、个人复查）。
4. 《项目总体计划》中要规定项目日常的沟通行为，解决周会、里程碑会、每天的晨会哪些人参与，项目工作向谁汇报的问题。
5. 项目经理统一项目名称，指派配置管理员，建立好配置库。配置管理员编排配置管理计划。
6. 项目经理选择自己项目需要收集的数据，制定度量分析计划。
7. 项目经理再识别一遍风险。

• 项目监督与控制

1. 项目监控的核心是在控制，监督只是观察手段不对结果产生影响。控制要从两个方面着手，一个是与计划产生偏差的问题，一个是对项目过程进行调整。
2. 进度需要统计的数据可以分成日期进度（容易监控）和工作量完成进度（不容易监控）两种。成本可以通过监控工作量间接达成。数据不真实的原因可能有：

• 因为数据填写的频率过高，填写人员积极性不高；
• 填写的手段不够便利，数据收集比较困难；
• 因为和绩效或者收入挂钩，所以填的数据看上去很美；
• 执行人员没有养成数据填写的习惯。

1. 项目经理每周写周报，到了项目里程碑结束，撰写《里程碑报告》（主要是通过度量数据进行总结）
2. 干系人的监控（C3体系中没有介绍），主要是干系人对项目态度的监控，然后采取不同的策略。

                       

干系人特征	态度	管理措施
权利大、利益小、影响小	支持	尽量满足要求，并当面澄清需求的目的
	中立	尽量满足要求，告知不能实现需求的理由
	反对	周报或口头报告问题到项目发起人、项目的分管领导
权利大、利益大、影响大	支持	分析需求实现的利弊，决策做不做的理由，上报领导
	中立	告知能实现和不能实现的需求项，告知不能实现的理由
	反对	和发起人对项目情况进行说明

项目的变更控制                

1. 
   项目的变更要走CCB的审批。需要关注项目变更中哪些人对变更拥护，哪些人不支持变更，中间会有利益点的冲突，需要项目经理进行协调。
2. 项目变更每周都要做监控，但是如果项目周期超过了4个月，可以等到一个月再处理一次。如果一个月内累计工作量不超过3人天的变更，项目经理自行处置。如果一个月内，累计发生的变更工作量超过了10人天，项目经理需要走变更流程，通知CCB决策。项目周期较短，可以每周/半个月处理一次。
3. 执行变更后，开发人员报告执行变更遇到了未预见到的问题，应该第一时间报告给项目经理，需要协调项目外部资源的情况下，项目经理将问题升级到领导处。

• 项目验收和结项

1. 验收的流程和方法按照C3的验收流程开展工作，原则上不具备验收条件的项目，未经过领导批准不能自行验收走商务付款。项目相关的验收标准要严格遵照项目合同中的验收规定。如果合同中没有规定如何验收，项目经理需要和业务部门、数据中心拟定验收的要求。
2. 先有项目验收，后有项目结项。项目结项主要是为了撤出项目资源和移交组织过程资产，因此需要得到领导的批准才能进行结项。是否召开结项评审会，主要是看项目涉及的各方是否对项目资源撤出有不同的看法，或者项目需要做一次全面性的总结工作。

• 软件设计

1. 软件设计主要弄清软件：

静态：内部关系和结构，使用的技术框架，每个模块的功能和性能，编码时使用的设计模式（优化代码，减少维护工作量），类的命名和类之间的关系。数据关系设计和结构设计，数据库设计，接口设计等。

动态：不同模块间的交互方式（一对一、一对多、多对多），通信协议，交互顺序，时序要求（同步或异步）。

1. 设计如果发现需求没有提清楚，应该第一时间把发现的问题记录下来，然后提交给项目经理处理。处理的方式可以是召开需求研讨会议，业务人员澄清需求。
2. 假如项目组的设计人员提出了多套解决方案，或者有不同的声音，应该使用决策分析流程选择最佳方案。
3. 设计的评审工作应该邀请真正的设计专家参与，可以请原厂商的人员参与设计评审，对照设计检查单一起进行检查。

• 软件编码

1. 开发的软硬件环境、工具、组件的版本一定要统一。
2. 代码必须写注释，注释要进行人工检查。
3. 单元测试要做好检查，利用检查单。
4. 编码规范的检查可以借助专业的代码扫描工具，也可以人工进行检查，每周项目组花一小时检查代码。

• 上线试运行

因为推广计划没有做好，用户培训做的不到位，或者用户反映的问题得不到及时的解决，会认为系统质量差，所以需要周密的计划系统的培训和推广方式，这个可以在系统《试运行计划》中策划该工作，如果方案特别复杂，需要整理单独的推广计划。