新运控项目集管理思路
2019-12-06 15:12:36 2 举报AI智能生成
新运控项目集群管理思路
作者其他创作
大纲/内容
航务运控项目集管理思路
执行
项目集群
明确统一的项目群目标，对目标进行拆分，分而治之
产品经理输出需求
研发组长基于里程碑计划输出开发计划带领研发小组实现需求
测试人员执行测试用例
产品经理主导发版
监控
抓过程，定指标，基于绩效目标拆解出关键监控指标
里程碑绩效目标按计划达成
产品交付物的返工2次以下
研发交付物的进度偏差5%以内
需求变更不规范的次数控制在2次以下
两周内补充资源缺口
生产环境重大故障发生率为0
过程问题分析与改进效果回顾完成率（项目管理过程质量）
基于度量数据进行问题分析（每周）
缺陷根因分析问题改进（项目管理结果质量）
降低研发预测试基础BUG逃逸率（研发提测质量）
基于预测试用例进行测试
提测前的研发showcase（二次检查）
降低UAT环境业务类型BUG的逃逸率（UAT测试质量）
数据的仿真性
每周三、日DBA同步
ETL工具的学习
用户的参与度
每次发版前与用户进行功能的确认
开展阶梯式用户测试
组织级推动
发版失误率为0
重点：发版邮件中的内容是否与GIT中MASTER分支中的更新记录一致
检查单的内容是否都执行完毕并且通过
半小时内恢复发生重大故障的生产服务
系统AB角人员是否明确
系统是否具备了应急响应机制
是否已搭建HA
运维监控机制是否完善，能否做到及时提醒
收尾
回顾过去，展望未来
复盘（海星法）
做的好的
做的不好的
应该做多一点的
应该做少一点的
继续保持的
项目收尾
合同收尾
启动
项目章程
项目范围初稿
规划
项目流程的标准兼指南（5W2H）
整合管理规划
变更流程规范
责任人：产品经理、项目经理
范围
需求
设计
进度
里程碑
工时
时间管理规划
项目计划规范
阶段里程碑目标须符合SMART原则
里程碑目标WPS活动拆解规范
任务须包含必要的管理工作
任务须分配了责任人并明确各任务的交付物
任务所对应项目成员，有时间投入比
任务时间按照每周7天，5个工作日分配（周末、法定节假日加班要备注）
最底层工作任务要明确工时及具体完成时间
工时估算
历史经验评估
三点估算
扑克牌法估算
任务优先级
最高
重要，紧急
提升业绩，规避风险
高
不重要，紧急
提高效率
中
重要，不紧急
低
最低
不重要，不紧急
任务复杂度
一级复杂度
前端
UI简单改动
简单弹提示
普通界面展示：基于现有前端组件，做数据呈现
后端
新建/修改API简单逻辑
简单SQL续写
简单存储过程
简单加个流程节点：这个指的是只用在流程中加一个加点，并简单加点逻辑代码
二级复杂度
界面兼容性调整：编写的界面需要考虑浏览器兼容性
界面自适应：编写的界面需要考虑自适应（在多种分辨率上都能正确显示）
组件化/代码复用：可以将代码抽象下沉至公共组件
复杂SQL
复杂存储过程
报表类SQL
三级复杂度
复杂算法：这里指需要经过如下流程才算该项1、详细设计文档2、设计评审3、coding4、代码review
通用工具：这里指需要经过如下流程才算该项1、详细设计文档2、具备通用性
涉及到新的通用技术栈：开发过程中，需要用到之前未使用的、但市面上已经广泛使用、有大量学习资料的技术栈
普通遗留系统改造：对有开发文档和代码交接的遗留系统的功能升级或bug修复
四级复杂度
复杂前端组件：界面交互复杂、具备灵活扩展性和适应性的前端组件，如：甘特图
涉及面比较广业务逻辑：具体例子如下：1、拼装管理的上传逻辑
复杂遗留系统改造：对缺乏开发文档和代码交接的遗留系统的功能升级或bug修复
涉及到新的特定技术栈：开发过程中，需要用到之前未使用的、但市面上尚未广泛使用、缺少学习资料的技术栈
五级复杂度
疑难问题解决：经多方协调、耗时3天以上解决的bug
兼具技术深度和业务广度：开发任务涉及的技术深度和业务广度达到一定规模，或两者之一达到特定规模
周报规范
每周一9点前提交至SVN
按模板填写
迭代流程规范
项目
抓进度
输入：组织级规划、里程碑计划
工具：迭代策划会议、站会、例会、周报、变更规范、同地办公
输出：迭代任务、里程碑任务按计划交付
抓质量
事前：质量管控计划
事中：按计划监控质量过程，进行纠偏
事后：进行缺陷分析，提出改进措施，闭环跟进
产品
业务轮岗
需求管理
研发
输入：开发计划
工具：微服务编码、性能优化、双活
输出：按时按质完成任务
测试
输入：测试场景、测试用例
工具：功能测试、集成测试、系统测试、性能测试
输出：可交付用户的产品
范围管理规划
产品经理管控业务端需求
项目经理管控内部需求
成本管理规划
输入：组织级项目目标
工具：基于目标匹配资源
输出：资源对应的成本预算
质量管理规划
数据库设计规范
代码管理规范
Git操作规范
前端代码Git分支管理
前端组长责任制
提测邮件发出后代码方能提交test分支
测试通过邮件发出后代码方能提交UAT分支
发版邮件发出后代码方能提交MASTER分支
后端代码Git分支管理
研发组长责任制统管前后端，详见《GIT代码管理规范》
上线过程规范
相应模块的产品经理责任制
检查表
《上线过程检查表》
《紧急发版检查表》
《上线方案》《上线风险评估报告》《系统关联影响性分析》《系统应急方案》
人力资源管理规划
组建团队
输入：项目计划
工具：招聘、内部协调
输出：人员补充
建设团队
人际关系技能
同理心
换位思考
培训（能力提升）
技术分享
代码讲解
业务知识分享
项目管理过程分享
团队建设活动
聚餐
羽毛球
基本规则
基础性质量问题说明
影响主业务流程或者让系统无法流转下去的缺陷
显而易见的界面性问题
研发三大军规
奖惩说明：相关责任人因以上过程执行不规范而引发项目进度延期导致基础性的质量问题的，相关责任人当月绩效予以B3以下反之予以适当的绩效激励
初犯：开会通报&差绩效
再犯：列入待观察对象&劝退
集中办公
认可和奖励
对于当季绩优同事申请业务分奖励
临时项目团队奖申请
及时关注团队思想状态，定期面谈
管理团队
绩效管理
输入：组织级目标，团队不足之处
工具：产品、项目、研发、测试头脑风暴
输出：绩效指标
输入：绩效管理计划
工具：OKR
输出：个人能力提升，团队整体能力提升，产出质量的提升，公司降本增效
冲突管理
分别聊天，明确目标的一致，同理心化解
沟通管理规划
主要作用：分析干系人的沟通需求，制定《沟通管理计划》
风险管理规划
《风险管理规范》
风险关注
产品经理需求产出，伪需求的识别
研发组长研发管理能力建设，执行力
研发梯队人员流失，绩效面谈关注
人员补充不及时，及时沟通项目信息
研发交付质量，研发过程管理
采购管理规划
责任人：项目经理
采购决策、明确采购方法、识别潜在卖方
获取卖方应答、选择卖方并授予合同
管理采购关系、监督合同执行情况
结束采购
干系人管理规划
责任人：产品经理对外（自顶向下），项目经理对内自下而上）
识别能或被影响项目决策、活动或结果的个人、群体或组织
基于对干系人需要、利益及对项目成功的潜在影响的分析， 制定合适的管理策略，以有效调动干系人参与
与干系人进行沟通和协作，以满 足其需要与期望，解决实际出现的问题，并促进干系人合理参与项目活动的
监督项目干系人之间的关系，调整策略和计划，以调动干系人参与的过程
收藏
收藏
0 条评论
回复 删除
下一页
