行进中的项目管理

上传人:jiups****uk12 文档编号:44713982 上传时间:2018-06-14 格式:PPTX 页数:42 大小:2.78MB
返回 下载 相关 举报
行进中的项目管理_第1页
第1页 / 共42页
行进中的项目管理_第2页
第2页 / 共42页
行进中的项目管理_第3页
第3页 / 共42页
行进中的项目管理_第4页
第4页 / 共42页
行进中的项目管理_第5页
第5页 / 共42页
点击查看更多>>
资源描述

《行进中的项目管理》由会员分享,可在线阅读,更多相关《行进中的项目管理(42页珍藏版)》请在金锄头文库上搜索。

1、1行进中的项目管理承接能力1多元 世纪项目情况汇总说明3交付项目项目数量概要说明TAS新需求项目3深文、九州、久丰、微盘3华兴、北文、新丝路新TAS部署安装6山东联合、青西、酱香酒、北贵、东北亚、嘉兴华凝内部研发过程中6MTP、现货、清算、新银行接口、终端、资管老客户5星级4西北、粤国际、北文、冠东、大连再生、存在问题3长江、鑫江、海西待签约6通德、盛屯、久丰发售、哈贵、中渝、中原大宗银行平台4浦发、微信支付、银联、民生运维类10不一一列举项目总数:45承接能力评估承接能力微盘项目、新TAS项目,TAS升级项目,内部研发项目、监控运维要求。1.1个项目经理承接3个项目,1个研发同时并行3个项目

2、可以,多个项目经理同多个项目时研发怎对任务就无法排期?项目存在冲突和打架严重2.需求响应基本达到预期,能在规定时间点出来,不管是通用版需求,还是个性化定制需求,但什么时间研发出来心中没谱?3.运维内在规定时间内完成部署,但TAS的运维还是存在较多疑惑,出现问题定位难,发现问题处理慢?研发的同时能承接的项目数量?如何通过制度和流程提高项目承接能力,通过补充资源和提高能力来提高 项目承接能力版本合并 V2及V3可迁移至 通用版需求个性化需求微盘盘3个新TAS每月3家运维维项项目支持MTP每月1家承接能力评估内部规规划 项项目5个紧紧急版本一线的声音2多元 世纪面临问题7资源问题资源如何做到有计划补

3、充 ; 新人:新人持续补充,如 何快速熟悉业务技术并融 入团队?需求问题个性化需求较多 谁叫的凶先做谁的,插 入任务较多工作压力核心人员加班多鞭打快牛 签约的合同迟迟无法交付项目验收项目上线后验收没有标准 运维的服务标准交付周期项目周前短:1-3个月 每一个项目的优先级都很高客户的呼唤和呐喊8研发客户观点内容信任是合作的基础观点内容需求入口出口唯一:每个项目要有明确的项目经理,运维的项目要明确对应的客服经理;需求基线:需求及时知会到客户,客户确认后进行基线,基线后如有变动走需求变更流程;项目交付过程中:工作分工、汇报机制、风险处理机制、变更处理等;项目交付承诺:保证里程碑点观点内容1.售前的时

4、候貂皮大衣,交付的时候给的是裤衩; 2.系统方案不专业:方案是什么,为什么这么给,没有安 全实施能力,性能与负荷指标是什么? 3.产品质量不高,问题不断,修复问题时间长,出了问题 不出解释; 4.出了问题找不到人,问题找到人后给不出计划,给出计 划后又按时交付不了,太不靠谱; 5.如何做到有效监控?如何保证高可靠性运维,标准是什 么?1.客户太强势,要什么就要给什么; 2.需求老是变,需求到底有没有一个标准; 3.又不是什么大不了的问题,缓缓吧;研发吐槽的声音91计划&需求1、项目工期不合理,项目从合同签订就是不可能完成的任务 2、不同项目交付时间冲突;项目需求和产品需求研发时间冲突; 3、评

5、审会议变成讨论会议,占用太多项目时间 4、新人,对技术框架及业务不熟悉,赶工项目没有学习时间 2流程&规范5、项目早期没明确项目流程,后续才逐步完善,造成很多返工 6、职责不明确;产品经理干了较多售前的工作、实施培训工作,项目经理承担了研发监督的任务,研发 经理干了需求澄清活 7、TAS部署复杂:配置手册、帮助手册不完善、银行接口上线客户所需要准备的材料 3行进中的问题8、一个员工承担多个项目,工作效率低 9、一个问题修改涉及到多个技术组,一级服务、二级服务等 10、产品不稳定,兼容性不强; 11 、监控工具不完善,不能有效发现问题并处理问题,研发花较多时间定位处理线上问题,没有沉淀完 善的T

6、AS运维知识库。 12.需求的统一汇总项目经理的困惑流程 体系项目 交付1.交付的边界界定:合同约定外的内容处理?2.交付周期的界定:主要里程碑点,谁说了算?3.交付质量的界定:客户反馈的bug响应机制?4.交付能力的评估:项目、需求、产品研发?5.项目群交付如何有序:优先级项目经理是监工?1.项目启动后四处找人;2.交付周期无法承诺给客户,承诺给客户的延期;3.越是骨干活越重,加班越多;4.项目交付过程中陷入黑洞,项目经理何时才能脱身;5.项目交付过程中问题及需求如何响应?项目经理不是监工,也不是超级协调人,做到从人盯人到制度和流程来保证项目的有序交付;项目群的交付应该是有秩序的:售前项目有

7、售前的流程、紧急项目有紧急项目流程,让每一个项目有一个合理的排期,和销售一起排优先级;版本发布节奏:区分个性化需求和通用需求,不同的需求有不同的交付期限,明确的产品台帐观点内容疑惑疑惑瓶颈与期望瓶颈:两头大、中间小问题及需求产品 设计项目 经理客户& 销售研发 测试问题及需求产品 设计客户& 销售运维 客服未来产品规划:产品规划:做当前版本,规划下一个版本当前产品规划:那个紧急处理那个,如粤国际、九州对冲未来项目交付:流程制度,任务驱动,主动反馈当前项目交付:人盯人,研发被动加班,交付周期随意Delay, 如久丰融资理财建议与措施3多元 世纪应对方案l需求要做优先级划分,项目经理 和产品经理、

8、研发定期碰头会议 l建立有效的需求台帐和客户产品 部署台帐 l需求的统一汇总、确认及回复客 户机制 l补丁的发放流程l重大产品规划汇总机制,以季度为单位 l产品大版本的发布机制,并及时传递到市场及 销售l待签约的项目提前知会,资源储备; l硬件集成工作标准化 l验收标准要明确界定 l运维的标准界定 l合同约定外的交付物要走审批确认流程 l待交付合同优先级排定 l合同或新需求的接口统一l风险定期反馈应对跟踪方案 l交付过程中进度的及时汇报: 表现形式为日报、周报 lQA的审计制度:项目审计,并 及时知会到高层l带病系统避免上线,并和商务做好 沟通、客户做到有效验证 l系统上线暴露出一些问题处理流

9、程 ,响应时间;l项目进度管理:承诺的关键里程碑 点一定要做到 l承诺前做到有效沟通,避免各个环 节不统一 l特定场景不合理的排期商务交付有 效沟通并降低客户预期合同客户问题及需求产品规划进度风险质量商务和交付的约定14PMO需求变更问题:项目经理发给客户确认,确认后 投入研发资源,研发完成后如再次发生变化称为 需求变更硬件集成工作:合同约定内的,投入施工人员, 但安全评估及安全配置需要请外部施工团队个性化需求的评估及确认:工作量及费用按照合同约定或高层邮件确认的需求进行交付需求澄清;交付工作清单确定;商务需求变更:商务追加路由及防火墙的安全配置:外部5000元/人天, 不含食宿、差旅费用;网

10、络施工:3000元/天标准银行接口:单独计费;维护的期限约定验收的期限约定个性化需求提出销售管理部每周五统一发出:签约的合同和未来 1个月待签约客户沟通与知会待签约项目支持活动支持工作:明确交付内容、项目的交付时间评估约定的交付内容表现在合同中,约定网络施工谁来做,不要临时抽调;体现银行接口接入风险;验收工作约定:验收标准及验收约定;运维工作及SLA万事开头难项目经理签约项目处理登记合同及付款情况排定优先级知会项目管理部商务部运维步骤 1步骤 2步骤3指派项目经理交付优先级的确认与回复问题反馈与跟踪与风险应对交付内容清单确认和客户沟通项目启动事项和研发沟通里程碑事项沟通甲乙双方的工作界面项目的

11、汇报机制开弓没有回头箭-项目交付1234交付 项目项目启动会议项目工作计划项目沟通机制项目问题处理机制:包括需求、客户反馈的问题处理时间约定、集成方案【标准、谁来做】系统部署方案【缺乏】网络施工【是否收费】安全配置及审核【能力不足】银行接入方案材料【缺乏】系统部署-模拟盘培训工作:次数、是否收费系统部署-实盘客户体验出入金测试与验证问题的反馈与解决需求类问题澄清与工作量统计实盘问题的紧急处理项目验收与结项项目总结与报告转运维运维的SLA【问题的处理流程】问题优先级分类及响应:实盘、非农以周为单位的项目审计并知会高层、销售、研发负责人:每周四下午1:301234项目经理项目经理负责制;统筹整个项

12、目:客户、研发、销售、运维;对项目成员绩效考核意见反馈;责任与权利需求分析人员客户需求反馈跟踪处理:个性化需求,能否同步至通用版,需求的设计和规划培训工作:模拟盘部署完成后去客户现场培训。技术经理Bug的分配与处理软件部署方案;运维组长系统的部署与安排运维工作支撑和反馈,运维问题的修复。非农处理,项目启动的四驾马车设备台帐:IP、系统名称、用户名、密码等系统部署台帐:部署的版本、补丁运维问题处理及知识库形成没有规矩 不成方圆项目的Kick OFF关键活动 制定详细计划(开发测试)部署计划关键输出沟通机制明确项目的工作流程问题处理时间约束项目章程主导角色PM参与角色 产品设计人员、项目经理、技术

13、 经理、测试负责人、运维负责 人、QA、工程个性化大需求的处理建核心 团队团队分工表需求 评估功能 点工时 评估优先 级启动 项目里程 碑计 划项目 章程划分 迭代迭代需求清单需求 确认待解决问题清单需求 评审需求评审记录研发类立项主导角色:产品委员会 参与角色:需求分析、架构设计师、研发总监 关键活动:可行性分析、需求范围、交互设计、产品的 RoadMap 关键输出:产品的需求概要列表,交互设计原型主导角色:项目经理 参与角色:需求分析、技术经理、关键开发人员 关键活动:里程碑计划、风险识别、流程裁剪 关键输出:Kick Off PPT研发流程管控保证成果合理交付22研发 过程12345过程

14、详细设计 测试方案 需求变更 项目计划调整 Code review 功能预演冒烟测试 功能测试 Bug跟踪 协调沟通 回归测试 安全测试风险控制 项目细节 项目范围 文档跟踪 项目周报问题跟进 项目发布知会 运营情况 项目总结发布计划 数据准备 发布验证 流程响应 问题记录Red Mine银行接入客户银行接入要准备的材料:包括商户号、测试用的个人账户、测试用的企业账户、拨号猫根据测试报告申请正式专线和银行沟通虽然不可控但要标准化公司明确测试负责人搭建测试环境测试报告测试过程中的问题及风险知会研发过程中沟通机制实盘后的回归银行不可控制因素需要客户沟通项目变更控制,减少纠纷投诉24(1)变更申请:

15、应记录变更的提出人、日期、申请变更的内容等信息。(2)变更评估:对变更的影响范围、严重程度、经济和技术可行性进行系统分析。(3)变更决策:由具有相应权限的人员或机构决定是否实施变更。(4)变更实施:由管理者指定的工作人员在受控状态下实施变更。(5)变更验证:由配置管理人员或受到变更影响的人对变更结果进行评价,确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。(6)沟通存档:将变更后的内容通知可能会受到影响的人员,并将变更记录汇总归档。如提出的变更在决策时被否决,其初始记录也应予以保存。变更管理的基本流程是:项目变更控制,减少纠纷投诉25(1)对用户的变更要求进

16、行记录;(2)遵守变更控制流程;(2)对变更请求进行足够的分析并获得批准;(3)在修改过程中注意进行版本管理;(4)修改完成后进行充分的验证;建立完善的变更控制流程,严格按照流程对变更进行管理,使变更在受控条件下进行。沟通机制261234项目例会项目组全体成员本周计划及需要协调事项。沟通工作汇报日报或隔日报、抄送责任销售、客户方的项目经理,项目组成员周报:客户方的高层、我方的销售、项目组成员;风险及问题的跟踪要及时知会项目组成员,重大的风险要告知商务 承诺非计划内工作:需要研发、需求、运维、项目经理一起确定重要里程碑点若依赖与外部因素要及时告知。重要建议:交付日期及重要里程碑销售、项目经理、研发内部口径一致,不单方面承诺;目标一致、口径一致风险和问题多强调一点问题和风险和处理和沟通:如何先客户想 到,如何教育和引导客户,如何做到提前 预警,项目经理与销售、商务

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 行业资料 > 其它行业文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号