“数字化重构系统，搞定 CEO 是第一步”

“任何行业，都值得用数字化再做一遍。”

这句话出自陆奇（奇绩创坛创始人兼CEO）之口，也是过去一年中，我引用最多的一句话。过去21年的IT职业生涯与近两年的数字化系统研发经历，使我对此深有体会。

极智嘉研发总监邱良军

2000年，我大学毕业进入外企，一待就是15年。回过头才发现自己错过了互联网发展的十年黄金期，也与移动互联网带来的风口擦肩而过。但有失亦有得，从事软件开发的十年和做技术管理的五年间，我从带领十多人的小团队到领导数十人的中型团队，并系统地学习了PMP（国际项目管理师）相关知识，为我在研发管理方面奠定了基础。此后三年，我在外包公司从零开始组建团队，也积累了管理近五百人团队和直面客户的经验。

如今，我身在创业公司，从组建异地研发团队并参与子公司的筹建，到负责公司数字化转型的系统研发，研发管理经历已涉及多个方面。在本文中，我总结了多年的研发管理经验和数字化转型管理经历，希望为当下处于数字化转型浪潮的众多技术管理者提供一些参考价值。

对数字化转型的认知

借用数字化转型机会重做一遍系统，是对系统覆盖的业务及涉及岗位的重新认识，通过对新技术的使用、逻辑的梳理、细节的打磨、流程的重构，能够激发每个参与者的能力，从而提升企业的整体竞争力。以往的数字化转型管理经历，使我深刻地感受到：

• 数字化转型正发生在每个人身边，它既不高深莫测，也非遥不可及；

• 数字化转型是企业的核心竞争力，是提升效率的关键因素之一；

• 数字化转型是社会信息化过程中的新阶段，是发展的必然；

• 数字化转型是循序渐进的过程，需要根据自身实际情况出发。

但是，许多企业在最初的信息化建设阶段通常只涉及一个部门或一个业务单元，推动相对容易，而在真正落地实施数字化时，往往会面临三个问题：

• 软硬件技术飞速发展让企业面临更多选择，很容易陷入选择困境；

• 规划很美好，落地过程却困难重重，短期效果不如预期；

• 转型涉及全过程、全业务，会带来利益的重新分配，以及对旧模式、部门壁垒的打破与重塑，因此会阻碍重重，必须从“灵魂”深处动手。

我一直坚信，一切问题归根到底都是管理的问题，这个道理在数字化转型上也同样适用，对于企业而言：

• 数字化转型势在必行，必须由企业一把手推动；

• 可以边规划、边落地数字化转型，从最易处入手，如远程会议、共享协作文档等；

• 以满足用户和实际业务需求为驱动，更容易达成转型目标；

转型过程没有“银弹”，必须从点点滴滴入手。每个企业都有自身特点（组织架构、业务模型、团队关系、企业文化都有所不同），成功的案例只能借鉴，不可完全照抄，可以在推动过程中不断进行微创新。

本文节选自《新程序员004》纸刊+电子刊同步上市

要和CEO及决策层讲ROI

在过去一年中，我最深刻、最痛切的领悟便是：要和管理层讲ROI（投资回报率）。即便曾经带领超300人的部门，直接面对客户，为公司..。我当时也没能理解“企业花费每一笔钱必须有商业逻辑”这句话。如今我才真正明白，必须简单明了地阐述企业的核心问题：如何创造价值、量化计算。

数字化的灵魂是业务，骨架是组织，手段是技术。在规划数字化转型时，必需计算ROI，这是企业管理层唯一能听懂及达成共识的语言。ROI的计算要简单且有说服力，通过量化ROI可以决定做哪些事、先做哪件事。优先级事项排列方法见表1。

看似简单的方法，却难在如何判断价值的大小和事情的难易。

首先，价值大小的计算公式为：总价值=降本+增效+提质。其中：

（1）降本=人力成本（发生频率*单个人效提升*人力单价）+ 其他节省（硬件成本降低+软件费用降低）

（2）增效=单位时间内产出（性能）的提升

（3）提质=产品良率提升+系统稳定性提升+产品更标准化+客户满意度提升

可以根据项目系统或功能做拆分和计算，产品价值计算案例见表2。

（1）“降人力成本（每年）”=（原处理时间－改进后处理时间）*单项目发生频次*项目数量*人力单价

（2）风险规避（每年）=（原事件发生次数－规避后发生次数）* 单次发生的平均损失

（3）初始投入（研发或采购软件成本）

（4）投入运营费用（每年）

表2 产品价值计算案例

合计后的ROI通常由财务人员计算，这里便不作展开。需要注意的是，如果初始投入是研发成本，可以把软件计入资产，分摊到多个年份折算，降低企业的税费。

对于业务价值的判断，业务部门拥有最大的话语权，转型负责人必须理解业务，和业务部门达成价值计算（即ROI）的共识，并得到业务部门的支持和背书。据我观察，之所以研发需求多到做不完，是因为有许多伪需求，通过ROI方式计算后，超半数的需求都不会再被提及。

其次，对于事情的难易判断比较主观，取决于个人能力。难易程度决定成本，而成本又是ROI的关键因素之一。从经验看，我们可以选择外采服务、SDK、SaaS、自研等模式，在预算有限的情况下，方案的选择会是决定性的因素。

在与管理层沟通时，需要把上级看得见的和看不见的联系起来，并说明之间的关系。

看得见的包括：

• 销售业绩增长了1倍，客户满意度提升了5%；

• 岗位人员效率提升，流程执行规范化；

• 日、周、月报表提交是否及时，是否有数据支撑的精细化管理；

• 高大上的数据大屏（这点尤为重要）。

看不见的包括：

• 技术术语、开发语言、前/后端分类、技术架构、业务拆解、设计模式等；

• 敏捷开发、代码规范、内存溢出、慢SQL、DevOps，数据中台、技术中台等；

• 架构、设计模式，以及重构、改进、优化等。

除了以计算ROI来驱动数字化转型的方式外，还可以采用问题驱动的方式，且这样的效果看起来更好。很多问题会在交付过程中引发故障或引起客户投诉，所以需要通过反向分析做出改进和预防。

业务痛点分三种

如果说获得企业决策层（尤其是CEO）的支持是数字化转型的起点或第一推动力，那么理解业务或由业务驱动便是转型成败的关键点，也是转型持久改进的动力源。

在数字化转型过程中会遇到各种奇葩问题，转型负责人必须和业务团队做深度沟通，理解业务痛点。

系统建设过程中，主要参与角色包括决策者（出资人）、需求方、系统使用方，以及产品系统的设计、研发、运维、运营。在复杂的ToB场景中，四方角色可能不在同一部门。而根据经验，各种情况都会存在，且直接影响转型成败。下面列举其中三种情况。

第一种情况：需求方（+客户）=用户方，是赋能的过程。

这种情况下，需求方、客户和用户是同一个人或同一团队，转型过程较容易推动，干扰和阻力较少。在成熟企业，该情况往往发生在信息化已完成阶段，需要做重构、持续优化、系统打通、数据治理等事项，主要考验团队的技术能力。不得不防的一种极端场景是，开发者担心自己的工作可以系统化后，职位的重要性降低，他们就会保留一些“秘诀”，导致系统化不彻底（根本原因是利益作祟）。

这是我遇到的真实事件：2009年在新加坡，我的印度同事做运维支持工作，负责人工监控日志和传输文件、进程等。因为工作强度非常高，所以我们作为开发工程师短期转岗支持他们，但对方却不愿意透露监控规则，最终出于业务压力才不得不说。为避免类似阻力，需要企业具备良好的文化和改革决心，建立起学习型组织。

第二种情况：需求方非用户方，能力转移，是革命的过程。

这种情况是将专家的能力赋能到系统中，普通用户通过使用系统即可获得专业能力，是能力转移或赋能的过程。听起来比较拗口，举例说明：360卫士对计算机做安全检查就是一个赋能过程，原本IT专业人士才能完成的工作，普通用户通过使用360卫士也能完成。在ToB场景中，有大量类似的情况，“专家们”在岗位上长期积累的经验不愿完全沉淀到系统中，总会有所保留。从理论而言，这是为了企业的发展，是应该做的，但在我负责过的部分系统中，这类项目的推进效果不佳。即便有CEO强力推动，也都是雷声大、雨点小，专家会有各种推诿、说辞，甚至故意相互抱怨。

究其原因，主要是在ToB场景下，从线索、商机、方案、订单、项目管理、供应链制造、交付实施、售后维修和运维支持，直到系统停止运行的链条较长（我们的研发链条包括将软、硬件结合，并需要做集成方案，管理整个生命周期），在此过程中涉及各阶段的领域专家协作，沟通协调很困难。如果这些能力可以下沉到系统中，将大幅提升协同效率。

实际上，多数需求方（即领域专家）的觉悟不高（自我保护意识太强），不愿分享自己积累的经验，以各种理由搪塞和拖延系统化的研发进度，容易让管理层失去耐心，最终导致项目失败。

那么该如何破局？据我观察，在此过程中重要的是与需求方反复沟通，如图1所示。把需求方定义为“创意人”，使用工具（系统）的人定义为“工具人”，系统的能力也需要不断迭代提升，当需求方释放能力到系统时，就可以有更多时间来学习，并持续不断地输入需求、优化系统。实际上系统是依赖他的，而不是完全取代他。从效果看，部分人能够接受，部分人还在顽强抵制。

图1  需求方与用户方的协同模型

第三种情况：用户方=产品研发，自我改进、革命的过程。

在较大的研发团队中，研发的数字化转型通常是第三种情况，对应的解决方案是DevOps。由于研发数字化转型（即当前比较流行的DevOps）的技术性较强，再叠加各种技术术语和新词汇，要么会让外行不敢发问，要么所有人三句话不离新词汇和新概念，比如云计算、云原生、虚拟化、大数据、人工智能……

该场景下，投资方是企业自身（通常需要CTO来驱动），用户包括开发工程师、测试工程师和各业务系统。对应的研发工作主要有运维开发、工具集成或二次开发，涉及领域包括CI/CD、基础..（IaaS或PaaS..）。

通过这些年带研发团队，我得出三点经验。

第一，对于较小的研发团队，用主流开源工具自己搭建即可，通常一个资深的开发..就能做好。

第二，当研发团队开始扩张，达到几十人甚至上百人的规模时，需求、任务、代码集成、代码质量，以及工程师间的协同、开发，测试间的协同、上线、变更、监控、运维等一系列冲突就会频繁发生，研发过程的数字化转型迫在眉睫。这时需要判断是自研还是采购PaaS管理..和DevOps..，我个人建议：外采所需的系统和工具，并派DevOps架构师专人负责过程管理与系统运行的基础环境上云。

第三，如果研发团队人数上千，团队成员差异性可能很大，使得协同变得困难。此时，研发数字化转型复杂度大幅度提升。通常需要组建自己的..组，专门负责自建DevOps..。比如，Google花费数年时间完成了持续集成、持续交付的CI/CD（即DevOps）..的建设，支撑其每天45000个代码变更提交。阿里云在2021年发布其DevOps产品“云效”，并免费开放使用。

总之，当前在互联网领域炙手可热的研发数字化转型是深水区，不容易讨论清楚，很多投入也不容易感知。

技术团队的数字化转型

在企业数字化转型过程中，由于技术团队是主要执行落地者，需要承担非常重要的责任。因此，技术团队自身也需要做数字化转型来提升效率。

对于转型中的技术团队，核心责任是用最小的代价满足业务需求，并具备一定的前瞻性，保证在业务和技术的发展过程中持续改进和迭代，避免推倒重来以及欠下太多技术债。

具体而言，技术团队需要承担哪些责任？在讨论该话题之前，先说一下我在实际工作中选择的四种方案类型：

• 第一种，外购不需要自己运维的SaaS产品，这类产品按照账号数量和功能模块收取年费，当数量较多时会有一定折扣。

• 第二种，外购需要做本地化部署的产品系统，这类产品会进行一次性软件授权，也会收取实施费用，之后每年还会收取服务支持费。

• 第三种，自主研发。

• 第四种，外购SDK或服务能力（API），其余部分自研。在此基础上定制化开发，把复杂且有难度的事情交给专业公司，相对容易且需求多变的部分自己做。该方案对于有研发能力的公司是最佳选择。

需要注意的是，对于前两种情况，如果产品功能不能满足要求可以做定制化开发，需要按工作量额外收费。

对于上述四种方案的选择，负责数字化转型技术的团队或决策者一方面要了解行业产品的发展动态，另一方面要了解自身的技术实力或专长，用最小代价、最小风险及最快速度满足业务需求。我的分析和选择标准见表3。

表3 技术方案分析、选择标准

因为我是软件研发出身，所以比较倾向于选择第四种方案。该方案的好处在于，综合了预算成本、风险把控、定制化要求，且在数字化转型不断深入时，保持系统迭代与重构优化。不过，其中也会遇到各种问题，主要包括：

• 系统之间的打通；

• 各系统之间单点登录的需求，页面之间的跳转（无需 再次登录和授权）；

• 随着系统数量的增加，用户体验会下降；

• 集中化的系统运营和运维管理需求。

为此，我们进一步做了统一门户和登录，设计了API服务网关、消息..和数据..，技术细节在此就不展开了。而关于自研系统，通常企业开发资源是固定成本，在资源（预算）能够承受的前提下，尽量采用第四种方案，原因如下：

• 通过自研系统，产品方和研发方在需求澄清、流程再造的过程中，发现业务不合理之处。对细节的打磨（魔鬼隐藏在细节中）会提升各方对业务的理解能力，这远远不是购买一个软件系统可以达到的，也只有如此才能达到从量变到质变的效果。

• 通常软件中的大部分功能是用不到的，买了不用是浪费。自研系统会先完成一个MVP版本，而后通过不断迭代与完善，发现不需要的功能可以及时终止。

• 以自研系统为基础，实现各系统之间的连接与打通，可以便捷地将系统产生的数据采集沉淀到数据仓库中，形成公司的数据资产，再利用数据挖掘、AI算法做分析。我将其总结为两个阶段：第一个阶段为数字化建设和运营，主要目标是提升运营效率，积累公司业务和运营的数据资产；第二阶段为数智化，利用积累的数据资产，为决策层提供“驾驶舱”看板和决策的数据支撑。

对于技术的发展方向，需要明确三点：

1. 零代码或低代码..是软件的发展方向，可以降低软件开发的复杂度，第四种模式实际上已经接近一种低代码模式；

2. 上云是不可逆的趋势；

3. DevOps是大型研发组织必须做的事情，是研发团队的数字化转型之路，也是一种必然。
   

结语

总而言之，数字化转型影响着社会的各个行业，影响着企业各岗位和每个人，比如：

• IaaS..系统（硬件即服务）的建设，让一个运维工程师可以管理上万台服务器，大幅提升基础运维的效率；

• DevOps..系统的建设，让软件工程师可以更专注业务需求的实现，无需陷入构建失败、测试不通过、需调试线上环境、部署失败等问题，不必耗费大量时间，可以大幅提升软件开发效率；

• 低代码..的蓬勃发展让产品经理甚至需求用户可以自己搭建软件，大幅降低了搭建软件系统的门槛。

即便是保安岗位，因人脸识别和摄像头的普遍应用，实现了电子巡更、电子围栏等，可以大幅提升安保效率，减轻保安的工作负担。

如今，相信每个企业、每个人都对数字化转型的重要性有深刻认识和感知，我将数字化转型的要点总结为五点。

第一，商业逻辑层面。企业数字化转型的商业逻辑是降本、增效、提质，这也是向企业负责人做出解释的商业部分，以及投入成本、获取收益（包括成本规避、直接收益、间接收益、风险收益）。

第二，上下游层面。数字化转型落地需要企业全体员工、客户、供应商的参与。

第三，技术层面。基础架构（公有云或私有云）、应用系统技术栈，以及智能设备（IoT）的结合，可以提升公司的运作效率。如果企业没有软件系统研发能力，难以选择和把控技术栈，持续推进就会困难重重。

第四，业务层面。主要是支持企业及各部门运行所需的系统建设。是选择采购SaaS服务，还是外购系统做私有化部署，或者选择自研系统。如果企业对外提供服务的产品具备软件研发功能，就趋向于系统自研。

第五，运营层面。运营是数字化转型开花与结果的阶段，在收获的同时还需持续迭代与改进，运营的每个过程也都需数字化加持。同时，通过运营过程中的反馈，让数字化得以深入。

千里之行始于足下，说再多技巧，学再多理论，不如马上行动，保持不惧困难、持续学习的心态，一定可以将数字化转型做好、做成功。

作者简介：邱良军为极智嘉研发总监，在软件行业工作近21年，前10年做软件研发，后11年主要做管理工作，包括研发管理、项目管理、运营管理，团队组建，管理团队峰值达400人。

— 推荐阅读 —
☞眼睛小被误判“开车睡觉”？网友：这波不怪小鹏，真的
☞损失37亿！Intel将彻底退出傲腾存储业务；支付宝新增一键取消「自动扣款」功能；iOS 15.5验证通道关闭|极客头条
☞在 M1/M2 Mac 上，让 Windows 11 免费“跑”起来！
《新程序员001-004》已全面上市 
扫描下方..或点击进入立即订阅