19年_PMO_实践

19年继续做了1.5季度的PMO工作，相比18年变化颇大。倒不是PMO的定位，而是PMO面向的对象发成了变化。总体来说，有如下转变：

1. 强调产品概念，产品经理上升到与子部门长同级别的地位。产品线、部门专业线以矩阵形式交叉运作。项目范围向前、后两端延伸，是普遍的趋势。项目启动之前的商业分析、需求调研，项目收尾、系统上线之后的运维工作、版本管理、宣传推广，更强调产品经理的职责。同时产品经理负责管理团队，对团队成员进行绩效考核。同样，各子部门作为专业能力组织，提供专业支持，对隶属成员进行能力做等量绩效考核。

2. 从IT项目上升到BT项目，前提是组建信息化委员会，由体系就能做决策了，作为BT项目引领变革的指导、支撑组织。

3. 流程纳入IT。IT、组织、流程三者本就是一家子，将流程纳入IT说明了IT在公司的重要性达到了新的层次。

---

BT项目

立项

1. 审批流程，提交申请-信息化委员会成员-项目指导委员会-主任-总裁

2. POC场景梳理，到底问题是什么都没弄清，不同业务立场回答不一致，这样即使做了POC也无法得出结论；可找一个案例，通过实际操作去理解问题；不仅基于功能考虑POC，还要基于用户角度；调查清楚业务模式，大的共有几类，将场景全部列出，并得到各业务方的认同，由此检验产品能力

项目监控

1. 项目汇总表。进度、质量、问题、风险、决策

2. 项目+版本发布。issues，requirements，project

项目费用管控

1. 项目科目标准化

2. 费用执行。必须产生项目编码，费用申报必填项目编码，把控部门公共项目费用报销途径审核。

项目团队架构

1. 指委会。主任-分管业务一级流程owner；成员-相关领域一级owner

2. 核心团队。项目经理-相应二级owner，若没精力投入可再任命执行项目经理；成员-相关具体业务owner

3. 执行团队。若干个执行团队

---

产品管理

版本号标准化管理

6周一大版本（1个月太短，2个月太长），紧急事件或维护，1周发小版本。版本号命名的统一规划，标志字母+日期+流水号

注意事项

1. 矩阵管理碰到的最大问题是资源，因涉及个人绩效矩阵考核
2. 外包资源池，提前与采购沟通，签署框架协议，以快速入场

产品经理绩效管理

1. 目的：  做的过程中跳出来审视，从结果去看能带来多少价值，识别无意义事项，并把含金量高的事项
2. 绩效管理，区别于任务管理。体现在考核结果与落地而非过程
3. 一件事不能量化、明确、简单化，说明就没有想清楚，没有体现价值或意义
4. 专注长期的、全员受益的工作，减少杂散的事务性工作，做成标准化、规范化流程
5. 事情简单化，目标说完能被记住，前提是把事情想清楚；拔高目标，与业务视角一致

沟通机制

1. weekly meeting with customer. Do what with priority. Export PBI, determine issue& painpoint->opportunity,  approached by project, change or issue.

   1. cost

   2. work time

   3. importance, strategy, legality

   4. urgency

2. weekly meeting internally, export SBI

3. daily meeting

---

Process

1. Planning

   1. Overall planning

2. Development

   1. Agil Requirement

   2. Sprint

   3. Daily Scrum

   4. Release

3. Service and maintenance

   1. Issue

   2. Key incident

   3. Disaster backup and recovery

   4. Change

4. Information security

   1. Incident management

   2. Reward and punishment

   3. Emergency treatment

---

其他感想

1. 存在的问题

   1. 系统的理解能力，SA，短板明显。商业平台本身产品较复杂，若没有对产品的深入理解很难做好方案

   2. 业务的理解能力，BA，对业务的理解较弱，同时业务本身理解也弱

   3. 项目管理能力，计划管理、资源协作能力，关键节点把控、问题风险管理能力

   4. 缺少方案评审能力

   5. 版本管理不够重视

2. 项目逐渐趋向于借助商业产品，能有现成模块功能实现的就不开发，或低代码开发。能用工具代替就采用工具