团队基建系列 - 组织知识传承 1

作为业务系统群的 IT 负责人，当前阶段管理团队的其中一个难点，就是解决如何让现有的系统知识体系能作为资产传承下去，降低 Key Man Risk 的影响。

在我司现有的的研发管理体系中，主要以 SIC（System In Charge）叠加第三方厂商的形式来管理各个业务系统。研发组中每一个成员基本都承担着一个业务系统的全流程工作，系统从 0-1 的时候做主要项目经理，待系统第一期建设上线后，又开始不断的做需求迭代对接，日常的运维事项解决也都是由 SIC 跟进的。在 8 年前，基本上是 40+的系统由 100+的研发成员支持维护，所以基本上每个系统有一个主 SIC 和一个备份 SIC 来支持，而随着业务的不断变化和增长，在系统数量已经翻了一番有多，100 有多的业务系统数量，系统与成员算是趋近 1:1 的对应关系。基于这个简单的数据，我就初步判定作为备岗的 SIC 一定承担不了备岗的职能，在我加入团队半年的时候，特别在组内做了个简单调研：每个人对所支持的备岗系统做知识掌握自评 ：

1- 深度了解系统各个模块，能够配合系统重建，或较大范围的改造。

2- 对接业务需求，能够承担中小范围改造的落地（供应商 5 个人月工作量以内的改造）并能支持业务的日常问询

3- 配合协调业务和供应商解决缺陷

4- 不了解系统

果不其然，除了几个重要信息系统外，其他系统基本都只是能协调缺陷的解决，有几个小伙伴也诚实的表达其实他们一点也不了解系统，只是知道名字和其大概功能范围。因为前面所提出，我司是基于外包厂商的交付形式，理论上所有的现场定制化的需求与功能手册都可以由厂商维护管理并及时归档，用户资产入库。可是恰恰相反，我管辖系统向下的 10+的供应商，没有一个能让我在这方面满意的。答案很简单，厂商工作量是计需求件数和计工作量的，在完成相同需求向下使用的人力成本月底利润率越高，所以对此基本都是不主动不拒绝，能马虎就马虎，能不写就不写。厂商另外一个问题是，因为项目制来调配人力配比的，所以相对不稳定，导致了金融科技公司整个市场都是谁开的高我就去哪里，六个月跳一次的程序员大有人在，因此造成了完善文档延续性的困难。

基于以上情况，首先目标就是要提高行内人员对技术管理自控力，并要加强对业务系统的了解。这种加强不是简单一个口号，让大家互相学习系统就可以的（尝试过，获得有失败案例 ），是需要打破现 SIC 机制的，但凡一个 SIC 增加了一个额外系统的责任，他们就会从心理开始拒绝，无论说的是工作量或者说是责任过多开始推脱， 所以要从组织架构开始调整，这个我下一篇和各位伙伴叙述。