行动派

经过半个月额的沟通后，每个人都有了一定的预期后。我按照整个项目管理周期，按照职能划分了 3 个角色：BAPM（业务分析与项目经理），Delivery Lead 和 Produciton Lead。因为以外包厂商的交付模式， 所有角色都需要以强化管理能力来提高掌控能力。

类似上图，整个科技组相当于 Cross Functional Product Teams，在原本各自为政的系统 SIC，转换为跨功能的产品小组。以下为职能概要：

BAPM 组：负责业务条线的需求对接与分析，重要项目管理推进，整体需求排期。

Delivery Lead 组：可行性分析与设计，工作量评估，开发与测试工作。

Prodcuton Lead 组：生产运维，生产自动化管理，投产质量管理。

按照以上其中有以下利端：

1） 优化工作量分配，不会因为系统或者业务属性在某时段特别忙或者特别闲。（例如财务系统在月结日）

2）让有冲劲的同事有更广的平台发挥, 不会因作为边缘系统 SIC 限制

3） 基于小组执行项目群，每个人的事项比原来透明，所以好的实施经验（Best Practice）可能更快的有效跨系统落实。

4）需求与交付专注在整个业务条线的需求，而不是系统级别的需求，所以更能增加对项目业务价值的关注。

5） 基于整体业务链条系统的设计，有产品化思路和沉淀。

其中有以下弊端：

1）各个职能团队间易产生谷仓困局

2）启动阶段，因没有相应业务领域知识积累，与业务的沟通效率降低。

3）因系统耦合历史负担重，长期造成技术体系散乱，因为不再是原本最熟悉的 SIC 带项目和变更，很长一段时间可能会交付效率低下，工作质量不高。

4）交付和运维的目标不一致造成天然紧张关系（求快求多 vs 求稳）

ReOrg 第一个月回顾

最开始的时候，需要的是有一个抓手把结果先带出来，然后每个小组自然就会有竞争意识开始行动起来。生产组（Production Lead）的是我最先操刀下手的，以下为一个月的成就：

1) 交付了金融市场的 14 个系统每天早上的自动化开门健康检查，检查内容包含服务健康状态与日志检查（仅覆盖严重类出错的关键字）

2）制定了系统运维资产的最低准入条件（系统文档列表与模板，生产环境信息）

3）统一上收了 14 套系统的投产流程，与投产评审环节

这个过程中，因为已有运维的资料实在与预期差得太多，所以降低了预期，修改了多次准入条件。不但已有的材料有问题，新提供的生产系统信息也错漏百出，PL 的同事一个个在生产上确认，才最终完成了材料。到现在全部 14 套金融市场的系统信息完全收集完成，现在在评审检查阶段。整个过程有多次的反复退回，每个成员也在这个过程中真实的感受到自身基建的不足，积极的配合完成的同时也燃起有一种“早就该这样了的”激情。

然后紧接着这一周，对于 PMBA 和 DL 组，也开始下达了 KPI 命令，这部分明天开篇继续。