01 - 理想 VS 现实

如上篇所述，随着整个组织内的系统的越来越多，原本充裕的人员配置，也逐渐捉襟见肘。在领导看起来，每个系统还是很稳健的，依然是有两角色，一主一个备。如果把整个 100+的系统配和 SIC 汇总起来，就可以发觉，一个 SIC 作为 2-3 个系统的主岗比比皆是，然后再互相担任对方 SIC 的备岗。

刚开始的时候我并没有觉得不妥，毕竟是厂商负责交付，每个系统都签署过维保合同，也许我组只需要做一些协调，负责上下游连通就好。粉饰的太平不叫太平，在 2020 年的上半年一个系统的 SIC 离职，我发现 SIC 备岗的同事随后的连续两次上线，都发现了不可理解的简单错误，导致必须要追加投产来解决，造成了极大的印象了生产稳定性与业务对我部的信心。

我花了一周时间，总结了几个现实的情况：

1. 系统经首次上线后，乙方一般仅仅留个别技术骨干驻场支持来解决缺陷，懂业务的全部调走去开拓新的市场，导致现场开发与测试场景与实际不符。虽说有用户测试，因用户人力有限，基本上只是测试新增功能。

2. 文档资产严重缺失，无论新来接手的厂商或者行里同事，都是两眼一抹黑，不断的挖坑填坑来学习。

3. 内部工作量严重不均。有经验的人知道，维保一个渠道类的重要信息系统（如企业网银，手机银行）与仅行内使用的培训系统 是完全不一样的，所以及时花名册上都是 2-3 个系统的主 SIC，工作量和技术要求也不一样。

02 - 方轮子困局

基于以上的情况，我首先也是考虑整合相似功能的系统的 SIC，让这几个 SIC 作为一个小组互相学习，不但可以平衡一下工作量，也可以在请假和紧急的时候互相支持。我开了好几次的研讨会，设定了系统的知识成熟度指标 Skill Matrix，还给小组设定了 KPI 与完成计划，同时也制定了定期分享学习计划，并让一个有经验的组长跟进这件事情。

这种方式我是有成功案例的，在 5 年前我带的两个团队由“小蜜蜂”到“金刚”也是这么磨炼过来的，可是这一次我遇到了战役的滑铁卢。每个月我都有追踪进度，效果不理想，同时在 2 个月的时候，组长对着 KPI 和我解释，因为小组每个人都太忙，目标知识按计划只完成了 30%。

这个是组织普遍存在“Too busy to improve”的恶性循环 (downward spiral)，下面是常见的场景，这次我基本上都中标了：

• 业务压得喘不过气

• 系统耦合历史负担重

• 老系统还要升级（换轮子）

组长说，如果要按原计划推进，我们需要暂停 30%的既定项目来保证。还有额外的几个因素将之前的安排更加暂缓了：

• 由于主 SIC 与备 SIC 的名册还是没变，所以事件经理出了问题还是会继续找名单上的人去解决问题。

• 接手新系统做交付出错几率大，如果不是必须要做的谁愿意冒这个风险呢。

• 自己主 SIC 也有本职工作，工作量不大的系统也无不想给领导发现，工作量特别大的也抽不出时间来做知识分享。

03 - 如何破局

持续交付业务价值是我们科技团队的主要职能，这个是红线不能受到影响。我们做破局的前提是要加强团队合作，提高每个人的积极性和要有一个必须破局的决心，然后就是打破现在的瓶颈约束，并加以针对性的一步步优化。下回会如何，待我下一篇和各位伙伴分享。