传统行业的IT研发体系

老编过去3年一直在金融行业做开发，众所周知，金融可以说是传统行业里最重视IT的，然而相比那些靠IT起家的科技公司，它的IT研发体系还是会有许多欠缺的。接下来，老编就基于所在公司的情况，分享一些对于传统行业的IT研发体系的思考。

1.产品管理

首先，还是得有专业而统一的IT产品管理团队，也就是常说的“产品经理”团队。无论是对客的渠道系统，还是内部管理的后台系统，都必须在这支团队统筹规划下、按着既定的规范和流程推进研发工作。

这支团队应该是是公司IT系统的总设计师，需要清晰的定义各个系统，规划好功能和数据的架构。日常工作中，他们要对接业务部门的需求，或是根据自己对业务和产品的理解提出需求，并经过充分而科学的调研流程，将业务需求转化为用户需求，再借助产品原型设计工具，将用户需求细化为功能需求，并导入到开发阶段。

只有这样做，才能帮助到避免公司IT治理中常见的几个问题：一是IT系统在功能和数据上的杂乱；二是，开发过程中需求的缺失和频繁变更，影响项目进度；三是不合理的需求。

着重说一下不合理的需求。现在传统行业的企业都在推数字化转型，各个业务部门都背了相关KPI/OKR, 猛着向IT部门提需求，其中必然会有些缺乏深思熟虑、效益低下、面子工程类的需求，产品团队应该运用自己的专业性，拒绝或推动修改相关需求。当然有很多需求来自一些领导的“灵感”，对此我只能说，好的领导应该尊重专业团队和相关流程，而不是将个人意志凌驾于专业性和规范性之上 ，也不考虑团队的实际工作情况。牛逼如马化腾，给广研院提了个文档 在线协作的需求，但广研院一直忙着弄微信，让pony足足等了8年才去实现。

另外，这支团队也是产品研发成果的校验者和跟踪者。项目上线后，他们需要定期地收集和分析业务数据、持续地跟进用户反馈，从而评估项目成果，总结经验，为未来的研发提供方向。

总得来讲，产品管理团队要拥有业务、产品和技术的复合知识，充当着业务和技术之间的桥梁，也是IT研发工作的重要驱动者。近几年，许多金融机构的信息科技部都更名为金融科技部，以凸显科技“驱动业务、引领业务”的价值，但如果没有建立这样一支团队，还是依赖业务部门里的非专业人士充当“产品经理”角色，来直接对接开发人员，那“金融科技部”也只能徒有其名。

2.开发团队架构

接下来说说研发团队中的核心——开发，一般也是科技部门中人员规模最大的，会分成很多个子团队。单个系统专门交给一个子团队开发是比较常见的做法，因为这降低了沟通成本，方便整体把控这个系统的设计、代码以及版本。也有另一种分工方式，将一条业务线分散到各个系统的功能全部交给一个团队开发，比如成立一个投资交易团队，将电子渠道、柜台系统、后台管理的基金、证券等相关功能全部交个这个组，这样的好处是相关开发团队会非常熟悉整个业务流程，方便推进这个业务线的研发项目。

我个人还是倾向于第一种的分工，因为“高内聚低耦合”不仅使用于程序设计，也适用于团队架构，详细来讲就是两点：第一，整体业务流程的把控还是得交给产品经理团队去把控，开发人员只用熟悉自己负责的环节就行了；第二，同一业务线中不同系统之间无非就是通过API交互，撰写出清晰易懂的API文档，是开发人员的基本功，而这个文档就能帮助到不同系统的开发人员之间的交流，无须非要将他们塞到同一个团队中去。相反不同团队的人同时为不同的项目开发同一个系统，会经常为开发测试部署工作带来混乱。

开发团队架构还可以引入另一个概念，就是解放军发明的步兵战术“三三制”，就是一个步兵班里有3个战斗小组，1个战斗小组里有3个人，选用政治过硬、战斗能力较强的战士作组长。这种编制下，最基本的战斗小组有着完整的战术能力，战斗小组之间保持适当间隔，在班长指挥之下，根据战地情况灵活组合和走位，既能发挥出有效战力，又能避免过大伤亡。

套用到开发团队，那就是3个人形成一个开发小组，组长应该是至少有3年以上工作经验、良好系统设计能力和编码习惯的高级工程师，由他主导设计并对组内代码进行day-to-day的评审，最后，每3个开发小组应该至少对应一个5年以上工作经验、架构师水平的资深工程师，项目最终的设计方案以及阶段性的代码评审由他负责。无论多小的项目都必须经过一个开发小组来完成，因为一个人单独完成一个项目在流程上就是有风险的，总需要第二双眼睛去检验他的成果。大型的项目则需要架构师合理拆分成多个模块，分配给多个开发组。当然，以上提到的3只是一个典型数字，根据实际情况调整为4、5都是OK的。

这套架构下，开发小组组长的招聘和培养就是关键，它决定了团队的可扩展性。每发现一位这样的组长，就意味着你可以招聘多招聘几位便宜的初级工程师，承担更多研发任务的同时又不影响研发质量。

3.测试运维

鉴于开发环节是整个研发工作落地的核心，让开发人员专注于设计和编程就是研发体系应该追求的重要目标，这就是为什么要推广DevOps，将开发人员从繁琐、重复的手工交付流程中解脱出来，别天天浪费时间在解决一些因代码版本混乱导致的测试环境问题，甚至每回投个产都要去把生产代码down下来搞对比。

严格来讲，建立了严密整合的、高度自动化的DevOps体系，项目最后的上线应该就和开发人员没啥关系，投产出了系统层面的问题直接由运维同事处理，要是程序层面的问题，那就是测试人员的主要责任，直接回退吧。考核开发人员的KPI就应该在测试阶段，按BUG数量扣当月绩效，并且在会议中分析BUG原因。

4.外包与采购

为了控制成本、保持团队弹性，现在很多公司都会有很大比例的工作是外包出去的。外包分两种，一种是人力外包，一种是项目外包。

人力外包，说白了就来个人，除了人事关系在外包公司，其他日常工作的方方面面都在本公司的管理体系之下。除了给外包公司付钱，自己也要付出一定的管理成本，好处就是过程可控，自己比较安心。但毕竟是外包人员，流动性比较大，也不适合赋予较高的权限，只适合一些低水平、重复性的工作，这样也好，让本公司员工专注于高价值的核心工作来。对人力外包员工的管理，是个精细活儿，最典型的问题还是重复管理，同一个人，得向两头汇报工作，挤占大量本职工作时间。

项目外包，现在用的是越来越少。因为一个项目最大的成本和风险都是在沟通，把一个需求完全交个一个外部团队去实现，期间的沟通工作一点都不会少，并不省心。而且这个需求非常重要，或者说独特性非常强，你也不太放心交给外人，还是自研比较好，也便于后期的维护和升级。如果这个需求没那么重要，那就安排自己团队见缝插针做了嘛，或者说是个很普适的需求，那市面上肯定有非常成熟的软件产品在销售，直接采购就行，顶多要供应商做一些定制化开发，更没必要请人从零开始开发一套。所以项目外包只适合一些紧急任务，立马得做，自己团队又确实没人了。

这里就顺道批判一下“追求完全自研”的错误思想。一个公司、一个部门，做事都得讲究一个聚焦，要有重点。一个公司的IT系统，重点肯定是那些核心业务系统，其他的如行政支持类的，都可以可以采用外购的方式。毕竟像什么项目管理啊人事管理啊流程管理啊，市面上有太多专业的公司在卖这些产品化的系统了，也自持定制，别人大几十上百号人日积月累的做出来的东西，不比你几个人在那儿瞎折腾强？从成本的角度来讲，你买这些产品花的钱，可能还不比你自研的贵多少，毕竟对于卖方来讲，软件这玩意一旦开发出来了，就可以无限无成本复制嘛，多少钱不是卖呢？