行进中的项目管理

1行进中的项目管理承接能力[1]多元世纪项目情况汇总说明3交付项目项目数量概要说明TAS新需求项目3深文、九州、久丰、微盘3华兴、北文、新丝路新TAS部署安装6山东联合、青西、酱香酒、北贵、东北亚、嘉兴华凝内部研发过程中6MTP、现货、清算、新银行接口、终端、资管老客户5星级4西北、粤国际、北文、冠东、大连再生、存在问题3长江、鑫江、海西待签约6通德、盛屯、久丰发售、哈贵、中渝、中原大宗银行平台4浦发、微信支付、银联、民生运维类10不一一列举项目总数：45承接能力评估承接能力微盘项目、新TAS项目，TAS升级项目，内部研发项目、监控运维要求。1.1个项目经理承接3个项目，1个研发同时并行3个项目可以，多个项目经理同多个项目时研发怎对任务就无法排期?项目存在冲突和打架严重2.需求响应基本达到预期，能在规定时间点出来，不管是通用版需求，还是个性化定制需求，但什么时间研发出来心中没谱？3.运维内在规定时间内完成部署，但TAS的运维还是存在较多疑惑，出现问题定位难，发现问题处理慢？研发的同时能承接的项目数量？如何通过制度和流程提高项目承接能力，通过补充资源和提高能力来提高项目承接能力版本合并V2及V3可迁移至通用版需求个性化需求微盘3个新TAS每月3家运维项目支持MTP每月1家承接能力评估一线的声音[2]多元世纪面临问题7资源问题资源如何做到有计划补充；新人：新人持续补充，如何快速熟悉业务技术并融入团队？需求问题个性化需求较多谁叫的凶先做谁的，插入任务较多工作压力核心人员加班多鞭打快牛签约的合同迟迟无法交付项目验收项目上线后验收没有标准运维的服务标准交付周期项目周前短：1-3个月每一个项目的优先级都很高客户的呼唤和呐喊8研发客户观点内容信任是合作的基础观点内容需求入口／出口唯一：每个项目要有明确的项目经理，运维的项目要明确对应的客服经理；需求基线：需求及时知会到客户，客户确认后进行基线，基线后如有变动走需求变更流程；项目交付过程中：工作分工、汇报机制、风险处理机制、变更处理等；项目交付承诺：保证里程碑点观点内容1.售前的时候貂皮大衣，交付的时候给的是裤衩；2.系统方案不专业:方案是什么，为什么这么给，没有安全实施能力，性能与负荷指标是什么？3.产品质量不高，问题不断，修复问题时间长，出了问题不出解释；4.出了问题找不到人，问题找到人后给不出计划，给出计划后又按时交付不了，太不靠谱；5.如何做到有效监控？如何保证高可靠性运维，标准是什么？1.客户太强势，要什么就要给什么；2.需求老是变，需求到底有没有一个标准；3.又不是什么大不了的问题，缓缓吧；研发吐槽的声音91计划&需求1、项目工期不合理，项目从合同签订就是不可能完成的任务2、不同项目交付时间冲突；项目需求和产品需求研发时间冲突；3、评审会议变成讨论会议，占用太多项目时间4、新人，对技术框架及业务不熟悉，赶工项目没有学习时间2流程&规范5、项目早期没明确项目流程，后续才逐步完善，造成很多返工6、职责不明确；产品经理干了较多售前的工作、实施培训工作，项目经理承担了研发监督的任务，研发经理干了需求澄清活7、TAS部署复杂：配置手册、帮助手册不完善、银行接口上线客户所需要准备的材料3行进中的问题8、一个员工承担多个项目，工作效率低9、一个问题修改涉及到多个技术组，一级服务、二级服务等10、产品不稳定，兼容性不强；11、监控工具不完善，不能有效发现问题并处理问题，研发花较多时间定位处理线上问题，没有沉淀完善的TAS运维知识库。12.需求的统一汇总项目经理的困惑流程体系项目交付1.交付的边界界定：合同约定外的内容处理？2.交付周期的界定：主要里程碑点，谁说了算？3.交付质量的界定：客户反馈的bug响应机制？4.交付能力的评估：项目、需求、产品研发？5.项目群交付如何有序：优先级项目经理是监工？1.项目启动后四处找人；2.交付周期无法承诺给客户，承诺给客户的延期；3.越是骨干活越重，加班越多；4.项目交付过程中陷入黑洞，项目经理何时才能脱身；5.项目交付过程中问题及需求如何响应？项目经理不是监工，也不是超级协调人，做到从人盯人到制度和流程来保证项目的有序交付；项目群的交付应该是有秩序的：售前项目有售前的流程、紧急项目有紧急项目流程，让每一个项目有一个合理的排期，和销售一起排优先级；版本发布节奏：区分个性化需求和通用需求，不同的需求有不同的交付期限，明确的产品台帐观点内容疑惑疑惑瓶颈与期望瓶颈：两头大、中间小问题及需求产品设计项目经理客户&销售研发测试问题及需求产品设计客户&销售运维客服未来产品规划：产品规划：做当前版本，规划下一个版本当前产品规划：那个紧急处理那个，如粤国际、九州对冲未来项目交付：流程制度，任务驱动，主动反馈当前项目交付：人盯人，研发被动加班，交付周期随意Delay，如久丰融资理财建议与措施[3]多元世纪应对方案需求要做优先级划分，项目经理和产品经理、研发定期碰头会议建立有效的需求台帐和客户产品部署台帐需求的统一汇总、确认及回复客户机制补丁的发放流程重大产品规划汇总机制，以季度为单位产品大版本的发布机制，并及时传递到市场及销售待签约的项目提前知会，资源储备；硬件集成工作标准化验收标准要明确界定运维的标准界定合同约定外的交付物要走审批确认流程待交付合同优先级排定合同或新需求的接口统一风险定期反馈应对跟踪方案交付过程中进度的及时汇报：表现形式为日报、周报QA的审计制度：项目审计，并及时知会到高层带病系统避免上线，并和商务做好沟通、客户做到有效验证系统上线暴露出一些问题处理流程，响应时间；项目进度管理：承诺的关键里程碑点一定要做到承诺前做到有效沟通，避免各个环节不统一特定场景不合理的排期商务交付有效沟通并降低客户预期合同客户问题及需求产品规划进度风险质量商务和交付的约定14PMO需求变更问题：项目经理发给客户确认，确认后投入研发资源，研发完成后如再次发生变化称为需求变更硬件集成工作：合同约定内的，投入施工人员，但安全评估及安全配置需要请外部施工团队个性化需求的评估及确认：工作量及费用按照合同约定或高层邮件确认的需求进行交付需求澄清；交付工作清单确定；商务需求变更：商务追加路由及防火墙的安全配置：外部5000元/人天，不含食宿、差旅费用；网络施工：3000元/天标准银行接口：单独计费；维护的期限约定验收的期限约定个性化需求提出销售管理部每周五统一发出：签约的合同和未来1个月待签约客户沟通与知会待签约项目支持活动支持工作：明确交付内容、项目的交付时间评估•约定的交付内容表现在合同中，•约定网络施工谁来做，不要临时抽调；•体现银行接口接入风险；•验收工作约定：验收标准及验收约定；•运维工作及SLA万事开头难项目经理签约项目处理登记合同及付款情况排定优先级知会项目管理部商务部运维步骤1步骤2步骤3指派项目经理交付优先级的确认与回复问题反馈与跟踪与风险应对交付内容清单确认和客户沟通项目启动事项和研发沟通里程碑事项沟通甲乙双方的工作界面项目的汇报机制开弓没有回头箭-项目交付1234交付项目•项目启动会议•项目工作计划•项目沟通机制•项目问题处理机制：包括需求、客户反馈的问题处理时间约定、•集成方案【标准、谁来做】•系统部署方案【缺乏】•网络施工【是否收费】•安全配置及审核【能力不足】•银行接入方案材料【缺乏】•系统部署-模拟盘•培训工作：次数、是否收费•系统部署-实盘•客户体验•出入金测试与验证•问题的反馈与解决•需求类问题澄清与工作量统计•实盘问题的紧急处理•项目验收与结项•项目总结与报告•转运维•运维的SLA【问题的处理流程】•问题优先级分类及响应：实盘、非农以周为单位的项目审计并知会高层、销售、研发负责人：每周四下午1:301234项目经理•项目经理负责制；•统筹整个项目：客户、研发、销售、运维；•对项目成员绩效考核意见反馈；责任与权利需求分析人员•客户需求反馈跟踪处理：个性化需求，能否同步至通用版，需求的设计和规划•培训工作：模拟盘部署完成后去客户现场培训。技术经理•Bug的分配与处理•软件部署方案；运维组长•系统的部署与安排•运维工作支撑和反馈，运维问题的修复。•非农处理，项目启动的四驾马车•设备台帐：IP、系统名称、用户名、密码等•系统部署台帐：部署的版本、补丁•运维问题处理及知识库形成没有规矩不成方圆项目的KickOFF关键活动•制定详细计划（开发＋测试）•部署计划关键输出•沟通机制•明确项目的工作流程•问题处理时间约束•项目章程主导角色•PM参与角色•产品设计人员、项目经理、技术经理、测试负责人、运维负责人、QA、工程个性化大需求的处理建核心团队团队分工表需求评估功能点工时评估优先级启动项目里程碑计划项目章程划分迭代迭代需求清单需求确认待解决问题清单需求评审需求评审记录研发类立项主导角色：产品委员会参与角色：需求分析、架构设计师、研发总监关键活动：可行性分析、需求范围、交互设计、产品的RoadMap关键输出：产品的需求概要列表，交互设计原型主导角色：项目经理参与角色：需求分析、技术经理、关键开发人员关键活动：里程碑计划、风险识别、流程裁剪关键输出：KickOffPPT研发流程管控保证成果合理交付22研发过程12345过程•详细设计•测试方案•需求变更•项目计划调整•Codereview•功能预演•冒烟测试•功能测试•Bug跟踪•协调沟通•回归测试•安全测试•风险控制•项目细节•项目范围•文档跟踪•项目周报•问题跟进•项目发布知会•运营情况•项目总结•发布计划•数据准备•发布验证•流程响应•问题记录RedMine银行接入客户•银行接入要准备的材料：包括商户号、测试用的个人账户、测试用的企业账户、拨号猫•根据测试报告申请正式专线•和银行沟通虽然不可控但要标准化公司•明确测试负责人•搭建测试环境•测试报告•测试过程中的问题及风险知会•研发过程中沟通机制•实盘后的回归银行•不可控制因素•需要客户沟通项目变更控制，减少纠纷投诉24（1）变更申请：应记录变更的提出人、日期、申请变更的内容等信息。（2）变更评估：对变更的影响范围、严重程度、经济和技术可行性进行系统分析。（3）变更决策：由具有相应权限的人员或机构决定是否实施变更。（4）变更实施：由管理者指定的工作人员在受控状态下实施变更。（5）变更验证：由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。（6）沟通存档：将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。变更管理的基本流程是：项目变更控制，减少纠纷投诉25（1）对用户的变更要求进行记录；（2）遵守变更控制流程；（2）对变更请求进行足够的分析并获得批准；（3）在修改过程中注意进行版本管理；（4）修改完成后进行充分的验证；建立完善的变更控制流程，严格按照流程对变更进行管理，使变更在受控条件下进行。沟通机制261234项目例会•项目组全体成员•本周计划及需要协调事项。沟通工作汇报•日报或隔日报、抄送责任销售、客户方的项目经理，项目组成员•周报：客户方的高层、我方的销售、项目组成员；•风险及问题的跟踪要及时知会项目组成员，重大的风险要告知商务承诺•非计划内工作：需要研发、需求、运维、项目经理一起确定•重要里程碑点若依赖与外部因素要及时告知。重要建议：•交付日期及重要里程碑销售、项目经理、研发内部口径一致，不单方面承诺；目标一致、口径一致风险和问题多强调一点问题和风险和处理和沟通：如何先客户想到，如何教育和引导客户，如何做到提前预警，项目经理与销售、商务、研发、测试达成一致项目QA审计工作28计划阶段制定质量管理计划和相应的质量标准；按计划实施质量检查，检查是否按标准过程实施项目工作。注意项目过程中的质量检查，在每次进行检查之前准备质量检查清单，并将质量管理相关情况予以记录；依据检查的情况和记录，分析问题，发现问题，与当事人协商进行解决。问题解决后要进行