项目管理规范培训_V1.0（项目经理版）_1.ppt

* * 项目经理们的系统建设愿景…… * * 打破系统的限制，通过SOA服务梳理实现松耦合的组件架构，通过规范实现集中化的门户展现 遵循SOA理论进行服务梳理 遵循统一门户接入管理规范 组件注册接入管理 集中化门户展现 谢 谢！ * * * * 珠海移动IT项目管理规范培训 ——项目经理篇 为什么要制定规范？ 原因 针对项目建设中实际遇到的问题，我们讨论出相应的解决方法，形成与IT项目建设相配套的管理、技术、评估规范，并希望在项目建设实践中不断完善与修正。 * 规范制定过程 规范修改稿V0.1-V1.0 规范初稿 在用规范集 管理、技术、评估规范V1.2 规范获取路径：知识管理系统---知识库---信息技术中心---部门概况---制度及流程---项目建设制度与流程 * IT开发管理规范内容 思路：以系统开发的生命周期为主线，以存在问题的部分为重点，从管理和技术两大维度对系统的开发管理进行规范。 * 讲解思路 IT项目建设生命周期11个阶段中不同角色的职责、输出物 贯穿IT项目建设的关键部分 * 角色说明 * * 项目立项时即让需求部门明白他们所担负的需求调研、评审、业务测试、项目推广职责的重要性，对项目的后期进行非常必要。 建设方项目经理在这里需要向需求部门解释清楚项目开始后的沟通和通报机制，以及项目结束后的评估机制。 * * * 需求分析注意点 与知识管理系统的结合 1.系统中如果有文档或知识存储的需求，秉着“一个知识库”的原则，尽量与知识管理系统合并。 2.是否有知识推送的需求，可否将知识管理系统中的知识转化为系统中的生产力。 3.是否有一些知识可以通过知识沉淀接口沉淀到知识管理系统中。 门户接入方面 1.系统中有哪些功能是可以当作服务提取出来接入门户的，这些服务如果要绑定知识，关键字是什么。这里的“服务”主要指一个工作流程的起始环节。 权限方面 1.系统权限、功能权限的控制 2.账号方面，尽量与门户帐号一致。避免后期修改。 * A类项目，建议邀请ITC和业务部门副总及以上级别的领导参加需求评审会；B类项目可以邀请室经理参加；需求评审通过后，与会各方需要在需求规格说明书上签字确认； 对于未参加周会及需求评审会的业务部门人员，可在会议纪要邮件中列明参会人与未出席人，必要时可抄送其主管。 * * 如果因为某些特殊原因不需要或不能执行测试，则需要由提出部门做出书面保证、经部门领导审核通过，并对系统质量负责。 对于经过测试后出问题的功能：如果测试用例覆盖到的，属业务部门责任，如果测试用例没有覆盖到的，责任在于开发商。 * * * 《项目经理项目规范检查列表》、《需求提出部门项目规范检查列表》、《开发商项目规范检查列表》三份检查表需要建设方项目经理、需求方项目经理、开发商共同签字。 《技术规范检查列表》由ITC项目经理和开发商项目经理共同签字确认。 四份列表均作为初验文档进行提交。 * 维护类型 ITC响应 开发商/合作伙伴响应 备注 系统硬件故障、软件问题，影响系统使用。 立即响应，给开发商/合作伙伴发出维护请求 立即接收，进入处理流程 维护接口人填写《故障维护记录》 对系统功能、界面优化调整 进行登记，从对系统、对实际业务数据是否有影响、维护工作量大小等方面分析，确定是否要提交维护请求。 在两个工作日内，开发商需要评估出维护调整可能造成的影响，并确定是否要接收维护请求。 需求部门提供《故障维护申请书》 新增需求 按需求变更流程处理 按需求变更流程处理 需求部门提供《需求变更申请书》 * 项目通报采用季度通报的形式，每个季度末进行通报。 按照项目所处的状态，对通报项目做以下分类：未立项项目、建设中项目、使用中项目。 对于其他部门自建的项目，项目经理需要每月给ITC接口人项目月报，便于做项目通报。 * 分类代号 分类内容 汇报对象 形式 周期 A1 市公司重点项目 市公司领导或分线条领导 汇报会 不低于每月一次 A2 市公司普通项目 业务部门领导 汇报会 项目里程碑阶段 B1 ITC重点项目 ITC总经理 汇报会 项目里程碑阶段 B2 ITC普通项目 汇报会 C 省公司项目 市公司领导或分线条领导 汇报会 不低于每月一次 * * * 系统上线后试运行开始后算起一个月后进行评估，本评估作为试运行报告的重要内容。 对每季度的运行情况进行评估，收集数据为上一季度的最后一日到本季度最后一日前，对所有系统进行评估，本季度内上线的新系统除外。 每年10月31日前对所有系统进行评估，评估数据为上年10月31日到本年10月31日产生的数据，本季度内上线的新系统除外。 * * * * *