项目管理参照
PM职责
项目干系人管理
|列出所有关系人：PM、PD、TC、前端、后端、其他负责人以及开发人员
l 项目动态及时通知相关责任人
l 建立项目管理群，相关文档材料以及开发进度列入群公告中
- 透明化
l 项目价值、产品方案、技术方案、项目计划、各个结论等全员共享
l 项目状态、风险、动态等即需要告知相关责任人，也需要同步效率平台让关注的人查阅
l 信息传达要及时，相关知识要共享。
- 沟通机制
l 建立沟通机制，沟通群、邮件组
l 项目协同工具：效率平台、jira、gitlab
l 沟通频率、沟通反馈与同步
-
需要给各个角色提供什么信息，何时提供
-
明确在过程中需要沟通的环节以及各个环节需要确认的问题与输出
-
何时开会、会议主题、会议议程、计划时长
- 有效沟通
l 告知可以反馈，但要注意告知范围
l 沟通要有反馈确认
l 会议要明确议题与议程，做好会议记录、做好控场，避免跑题。
l 让具体负责人直接沟通，消除中间环节，但注意沟通结果的信息同步
l 重要的事情说三遍
- 项目范围
需求分解、变更必须和整个过程管理配合。
l 明确项目的核心价值，避免项目过度复杂或过度简化，这是评估合适项目范围的参考标准
l 需求管理：协助需求分解
l 变更管理
- 时间管理
组织任务分解，关键节点设定，计划排期，跟踪并应急
l 工期估算
l 排期计划
l 计划跟踪与修正
- 项目成本
跟踪实际投入与产出，作为效率监控
l 主要为资源投入、评估工作量，跟踪相关工作量进展，为效率管理提供依据
- 项目质量管理
l 产品方案评审
l 技术方案评审
l 验收标准管理
l code review 的组织
l 测试计划、测试范围、测试用例评审等协调
l 测试报告
- 风险管理
l 风险识别
l 风险分析
l 风险应对
l 风险监控
- 共享知识库管理
l 需求、需求变更记录及相关知识文档（aone），讨论记录
l UI
l 技术方案，设计思路等
l 会议纪要(建议除邮件外,要有干系人共享的wiki版本)
l 排期计划
l 发布计划(部署方案)
l 测试计划、测试用例、测试报告
过程管理
需求阶段
-
需求收集、审批确认 —— 会议记录、审批流程记入相关项目知识库
-
建立项目知识库，建立需求讨论组
-
复杂的需要要制定需要计划
l 需求收集
l 需求分析
l 评审记录
l UI 设计
l 业务确认
- 输出产品方案(PRD、原型、UI)等
研发阶段
-
需求评估 —— 简易需求直接与需求评审会议合并，复杂的单独组会评估
-
组织需求宣讲
-
项目主要资源(产品\架构\研发\测试\UED)对于项目进行整体评估
l 技术方案以及技术方案确认
l 工作量评估（粗略保守估算）
l 资源评估
l 风险评估（需求是否稳定，资源是否充足、时间是否存在风险，其他风险）
l 可启动开发条件是否充足
- 需求分解
l 用户故事或者功能分解到适合一个迭代可完成的大小（粗略评估）
l 无法更细颗粒度分割不要强求分割，迭代时可按照任务分割
- 输出项目排期计划，整体迭代节奏，邮件通知相关责任人
迭代管理
-
组织迭代计划会议，评估迭代内完成的用户故事\功能点\测试\UI,分解任务,制定具体到天的迭代计划,并输出(邮件)给负责人，记录到知识库
-
组织每日立会(或隔日)
l 需要明确每个人最新进展、当天计划、遇到的问题，时间建议 15分钟以内，不讨论具体时间，具体问题单组组会讨论
l 小团队项目，最新进度通过聊天同步即可(记录到 doc 上)
l 需要跨组协作的项目，需要及时跨组进行同步
- 组织迭代演示及复盘
l 在项目上线前一两天进行
l 在本阶段完成的做一个简单回顾
l 能演示的东西，向产品、测试或业务进行展示；可及时发现问题，增加大家对项目的了解，而不是等到开发完成才展示成果，有效提升项目信心、降低项目风险。
l 迭代报告
- 测试计划制定
l 尽早组织测试计划制定，建议项目启动测试即介入，尤其时研发兼PM时注意计划、例会、演示等不要遗漏了测试同学
l 协调测试与产品沟通验收条件（重点针对与需求场景而非功能点），含测试范围（测试边界），验收标准，质量标准，性能标准
l 协调测试输出测试用例，进行用例评审
l 测试切入的时间计划与资源安排
- 发布管理
l 制定发布计划
l 多个项目的部署顺序，是否依赖
l 部署步骤，各环节负责人，各环节部署时间
l 回滚计划，或发布失败的应急方案
l 通知所有项目负责人，重要的负责人必须确认
- 复盘（小项目直接通过迭代复盘）
l 回顾目标
l 评估项目效果
l 总结做的好的地方，与不好的地方，并讨论优化思路
l 根据总结，形成行动计划
效率管理
量化是我们评估项目投入，进度、效率的基础。
推荐量化管理方案：
l 需求和任务要有工作量评估
l 以工作量评估作为基线，实际发生工作量做对比，评估进展，团队效率
l 量化方式一（可阅读Scrum相关资料）
l 尽量细化任务及需求,需求分解到一个迭代（两周），做用户故事点数或工作量评估（可细化到任务）
l 通过需求完成趋势图、需求燃尽图作为效率衡量，在基准线之上的项目要标记为风险
l 量化方式二（可阅读挣值管理相关资料） <u>https://www.jianshu.com/p/ffa22f2533a5</u>
根据项目评估项目价值（计划值PV）
细化分解各个任务价值，作为任务估值
根据实际完成（EV）/计划估值（PV），衡量项目进度偏差
根据实际完成（EV）-实际发生成本（AC），衡量成本偏差——计划投入与实际投入偏差
统一的估值管理模型可以衡量整个团队的效率问题
通过价值流图识别浪费，然后优化，聚焦于价值最大化，而不仅仅优化成本
