低代码/无代码时代，企业IT人员的角色正在悄然改变( 二 ) 作者|轻流联合创始人&CPO严

令人唏嘘的是，稳定性所带来的“业务损失”并没有减少，而是以“IT成本”的形式出现在了财报中。
弊端二：信息化协作链路长，响应糟糕
大公司的“大”首先体现在复杂庞大的组织架构上。该公司超过1.2万人，共有5家分公司以及分散在全国各地40家左右的实验室的。为了服务这1.2万人进行协作和管理，公司组建了150多人的信息化团队；而为了维护这样规模的团队，每年公司需要支付总计数千万的各项成本，堪比一个小型企业全年的营收。这样级别的投入对于大部分公司来说都是难以想象的。
中心化的IT信息化团队在企业内扮演了乙方的角色，承接各个子公司、业务部门的信息化需求。在资源有限的情况下往往出现互相挤占以及排队现象，往往一个非常小的功能需求排期就动辄数月的等待周期。不仅是排不上队，即便排上队伍了，落地质量也差强人意。庞大的组织架构弱化了部门与部门之间的联系，中心化的IT团队离业务一线越来越远，使得甲乙双方有着巨大的信息差和理解差，这种差距直接导致了最终需求的落地效果差甚至无法落地。
这些问题在这家公司的集中暴露并不是偶然，在大企业中属于普遍现象。大企业的信息化陷入了一个怪圈：“投入越来越多，效果却越来越差” 。信息化的“大公司病”就像房间里的大象显而易见却又难以改变，所有人都默默的承担着，然后继续负重前行。
“甲乙方”式的协同存在的弊端
生产资料的稀缺性以及生产工具的使用壁垒导致了甲乙方的协作模式。这个基本原理在“信息化”领域同样生效。我们发现正是这种“甲乙方”的信息化协作方式的弊端，造成上述的种种乱象。
弊端一：甲乙双方对于需求的理解有断层差距
软件开发是一项具备高度专业性的工作，其包含了两项重要“任务”：
任务一：将抽象的业务需求设计为可操作的系统功能；
任务二：通过代码将任务一的系统设计进行实现；
在过去我们非常关注“任务二”的专业度却忽略了“任务一”中软件的业务逻辑设计同样具备专业性。大部分的IT开发者并不缺乏coding能力的专业度，但是缺乏对于业务需求/痛点的深度理解。大型企业的组织架构和业务流程往往庞大且复杂，大部分的IT开发者都距离业务一线非常遥远，而业务问题同时具备广度和深度，非实际经历很难有切身体会。
IT开发者能够意识到“需求理解”的重要性，但在大量的开发排期面前往往却有心无力。这种差距导致甲乙方的服务落地质量得不到保障。服务满意度较低。这种牺牲“开发质量”而追求“开发数量”的做法并不可取，但身处其中的IT开发者其中并没有能力扭转局势。
弊端二：甲乙方的中心化协同缺乏响应业务变化的灵活度
VUCA时代，企业业务变化的周期被大大缩短。对于信息化工作的灵活度有了更高的要求，超过59%的中国IT开发者认同其企业的软件开发速度需要加快。
然而甲乙方的协作模式下，企业内所有的业务系统需求，都通过一个庞大的信息化中心来完成，一个标准的研发流程包含需求梳理、方案设计、落地研发、质量测试、版本发布等等环节，每个环节都是专人执行。项目参与人数越多，协作难度越大。过程中的信息损耗、效率低下问题也是反复出现。各个业务部门对于中心化的排期资源抢占也变成了一种企业内的负和博弈，增加了不必要的成本支出。
这一切都使得响应周期过长，系统还未开发就变成了“过期产品” 。这些都大大提升了信息化投资的风险，企业每年投入大量的资金进行信息化投资，大部分都处于无法明确收益比的情况。这也难怪大部分的企业主想做信息化但又不敢做。