导图社区 改进版--项目经理
- 208
- 17
- 2
- 举报
改进版--项目经理
项目管理是对一些成功地达成一系列目标相关的活动（譬如任务）的整体监测和管控。这包括策划、进度计划和维护组成项目的活动的进展。项目经理上手须知：职责类型，管理过程，工作内容，相关系统。助力你的工作更上一层楼！
编辑于2021-06-03 19:04:53- 相似推荐
- 大纲
项目经理执行手册
需求管理
输入
需求概要
需求优先级
过程
提前了解需求，预测需求所涉及到的模块和团队规模
组织产品概要设计预审
提前一天将需求预审文档，供参会人员查阅
参会人员
技术专家
测试专家
产品
项目经理
几个问题
遗留问题输出指定责任人和解决时间
需求优先级和范围
输出
预审澄清会议纪要
会上争议的记录
遗留代办问题跟进（需符合SMART原则）
下一步工作计划
UEUI完成时间
PRD完成时间
需求实施方法
项目
资源投入大且实施周期大于两周的需求
迭代
已采用迭代制度，且达不到立项标准的需求
日常
未采用迭代制度且未达到立项标准的小需求
项目立项
输入
需求概要
立项申请单
过程
项目立项
立项申请
立项审批
一般预审前完成 ，视情况可以需求详审前完成
项目启动
正常情况下，需求详细评审时间就是立项时间，如果需求详审后，不能正常进行技术工作且跨度较长，那么以后续技术评审时间为立项时间。
需求定义
组织需求详审、UEUI澄清
提前一天将需求PRD，供参会人员查阅
参会人员
产品
技术专家
模块技术owner
开发人员
测试专家
模块测试owner
测试人员
项目经理
几个问题
业务流程是否清晰
项目范围是否清晰（功能点、涉及的端、能力中心等）
输出
需求详审查、UEUI会议纪要
会上争论的记录
明确项目范围
遗留代办问题跟进（符合SMART原则）
下一步工作计划
技术方案评审时间
项目执行/监控/日常
项目
技术方案评审
提前一天将技术方案，供参会人员查阅
参会人员
产品
技术专家
模块技术owner
开发人员
测试专家
模块测试owner
测试人员
项目经理
几个问题
各模块的设计文档是否完整，无遗漏
自测方案是否明确
开发所需要的全链路拉通的基础数据定义及格式是否明确
项目计划
工作量估算
开发
编码
联调
冒烟
测试
用例设计、评审
测试
stable
UEUI
UEUI验收时间
产品验收
不晚于stable前一天，产品必须启动验收
项目计划指定
项目各阶段里程碑清晰明确
注意事项
将质量保证计划纳入到项目整体计划中，如灰度发布等
将UEUI、产品验收纳入到项目整体计划
项目计划需获取团队和专家的共识，并公开承诺
编码
编码实现
自测联调
用例编写
用例评审
提前一天发出测试用例，供参会人员查阅
参会人员
产品
技术专家
模块技术OWNER
开发人员
测试专家
模块测试OWNER
测试人员
项目经理
几个问题
冒烟用例是否明确无异议
测试用例是否覆盖完整无遗留
性能指标是否纳入测试用例
测试环境部署
由测试负责测试环境部署，开发协助
必须于提测前完成
冒烟提测
提测前必须在测试环境完成自测并且冒烟用例通过
提测符合优行科技规范
验证
冒烟测试
功能测试/性能测试
UEUI验收
在冒烟通过以后，设计进入UEUI验收
stable 测试
产品验收
不晚于stable前一天，产品必须启动验收
发布
项目发布方案阶段
评审至少不能晚于部署Stable的前一天
组织编写发布方案
参会人员
产品
技术专家
模块开发owner
开发人员
测试专家
模块测试owner
测试人员
项目经理
运维、DBA
几个问题
发布服务范围、顺序、时间是否无误
回滚方案是否清晰可行
影响范围和风险是否明确
线上验证/监控方案是否清晰可行
发布留守人员
项目发布
项目
日常
紧急
线上验证
项目发布失败，须第一时间执行回滚，避免影响范围扩大
迭代
迭代活动
采用双周迭代制度，即每两周进行一次App发版，特殊情况可以向过程管理部申请增加或减少发布周期；
每一个迭代过程采用小瀑布的流程方式，所有的过程参考项目管理流程的各个活动要求：项目管理流程
迭代整个过程，由项目经理负责管理，包括但不限于版本需求和发布规划、需求的实施方法选择（迭代、项目、日常）、过程质量管理、持续优化措施、资源协调等；
注意事项
乘客端、司机端接入
项目接入前必须达到稳定状态：功能测试完成，bug修复完成
乘客端灰度发布
安卓市场聚道
日常
研发+测试工作量小于两周的需求（业务需求\技术需求若存在日常需求迭代规划外的紧急需求插队，则受影响的需求的优先级顺排
日常管理
站会
规定时间地点
形式
轮流发言
当天问题当天解决，并在钉钉群钟公示问题解决结论
每日项目跟进
进度
风险/问题
日报
风险及应对
整体进展情况
带协调支持事项
优效
周报
变更管理
变更评审阶段
需求变更提交
变更受理
所有项目和迭代的变更由项目经理统一受理
日常的变更由团队自行负责
评审评估
变更决策
拒绝变更
如果变更理由不充分或者没有必要，项目经理有权利和义务拒绝变更
更新项目计划
更新文档
变更实施
风险管理
风险预警
定级及预警
相应和处理
向上汇报
风险复盘
阶段性复盘
季度
归档输出
质量管理
线上故障管理规范
线上故障定义
线上故障处理流程
故障响应阶段
响应和修复
线上验证
故障复盘阶段
启动故障报告
SQA角色暂由各业务线项目经理兼职
分析报告
由故障处理相关人、涉及模块的负责人编写
复盘会议
复盘会议必须由两名以上部门负责人，1名以上战略专家参加
定级定责
由过程管理部最终确认定级定责
向上汇报
由过程管理部向CTO汇报故障结论并审批
故障备案
故障以季度为单位统计分析，记入各部门以及管理人员考核
故障确认后，备案至HRBP处
模板
线上问题管理规范
线上问题响应阶段
响应和回复
反馈结论
创建问题
线上问题修复阶段
计划与修复
紧急或复杂问题可以申请项目经理协助解决
问题与验证
线上验收
修复反馈
更新问题状态
对于影响较大的问题，上报项目经理走故障处理流程
阶段性复盘
每个季度项目经理整理分析全局线上问题报告
项目过程度量体系
项目数据
项目交付数
资源投入
冒烟通过率
提测准时率
发布准时率
研发周期比
需求数据
需求完成度
需求变更率
质量数据
过程中质量数据
质量密度
BUG分段比值
功能测试阶段与stable回归阶段BUG数比值
线上问题
项目故障
发布数据
项目结项
评估结项
过程数据
结项成员评价
复盘
复盘资料整理
问题反馈
优化措施定义
复盘会议
项目流程执行要点
项目立项
立项条件
需求研发模式采用项目制度（资源投入大且实施周期大于两周的需求）
业务项目和技术项目
立项审批
审批进度跟进
项目启动
新业务启动需要组织KICKOFF会议
正常情况下，需求详细评审时间就是立项时间，如果需求详审后，不能正常进行技术工作且跨度较长，那么以后续技术评审时间为立项时间。
需求管理
需求的实施方法
项目
资源投入大且实施周期大于两周的需求
迭代
已采用迭代制度，且达不到立项标准的需求
日常
未采用迭代制度且未达到立项标准的小需求
团队自行负责
迭代规划
固定时间盒
固定需求阶段、设计阶段、编码阶段、验证阶段和发布阶段的时间周期
需求周-设计周-编码周-验证周-发布周
下个版本在编码周和验证周完成需求设计、技术方案设计和评估工时，以此循环
根据实际工作量调整需求范围并告知团队
需求预审
会前
需求概要输出时间
确认参会人员
会中
把控会议时间
会上争论记录
会后
遗留问题跟进
确认UEUI、PRD产出时间
跟进进度
需求详审、UEUI评审
会前
确认参会人员
分批
会中
把控会议时间
会上争论记录
会后
遗留问题跟进
确认各模块技术方案产出时间
跟进进度
项目执行
技术方案
会前
检查技术方案完整、无遗留模块
确认参会人员
分批
会中
把控会议时间
会上争论记录
会后
遗留问题跟进
评估工时、指定项目计划
将质量保证计划纳入整体计划，如灰度发布、集成测试回归
项目计划需获取团队和专家的共识，并公开承诺
编码、验证
进度跟进
问题、风险、变更推进解决
发布
至少在部署stable前一天进行发布方案评审
确认评审人员
发布方案评审
确认发布服务配置脚本、顺序、时间是否无误
回滚方案是否清晰可行
影响范围和风险是否明确
线上验证/监控方案是否清晰可行
发布留守人员
线上验证
项目发布失败，须第一时间执行回滚，避免影响范围扩大
项目结项
结项时间
上线1周内
数据
过程数据
评价数据
复盘
会前收集问题并形成优化措施
日常/监控
优效
站会
每日项目跟进
日报
周报
风险管理
过程中及时有效跟进处理风险
同步反馈
组织协调
变更管理
所有项目和迭代的变更由项目经理统一受理
如果变更理由不充分或者没有必要，项目经理有权利和义务拒绝变更
变更后，文档更新及同步如产品文档、技术文档、项目计划
质量管理
质量内建
产品-开发-测试-发布-上线的规则
过程数据
过程改进措施