谈谈银行核心系统建设--篇3：核心系统的项目组织
文章来源：e路向上，文章仅供个人学习
有别于日常工作，核心系统建设是一个典型的“项目”，具有“起止时间明确”、“建设目标确定”、“需要在特定的约束条件下（时间与成本）达成”等典型的项目特点。核心系统建设的项目管理，就是要通过合理的项目计划、科学的项目组织、有效的监控、高效的执行，在可接受的预算约束下，如期达成项目目标。其涉及的具体内容包括：项目计划、团队组织与协同、项目风险管理、项目预算管理、项目时间管理等等。本文就核心建设项目中的一些可能有用的经验做些分享。
判断项目周期及前期准备
核心系统建设的行业实践中，完成项目所需的时间周期，从1年到4年，甚至更长时间的情况都有。鉴于核心系统建设通常需要全行参与，其对人员投入、市场产品迭代、作业流程优化、账务与考核等均具有全行性的影响，项目建设过程不可避免地会影响全行日常工作，因此，核心系统的项目建设周期，在确保可顺利完成的前提下，项目周期越短越好。那么，如何相对准确地判断需要的建设周期呢，有几个关键性的因素建议参考：
1、项目范围。如“谈谈银行核心系统建设–篇2：核心系统的需求定义”，项目要达成什么目标，是判断项目周期的重要因素之一。如果只是换个系统，组织架构、作业流程、新的账户能力、核算体系等一应照旧，同需要重新设计运营、账务体系，需要重新打造更立体的账户能力，所需要的时间差别很大，后者涉及大量的需求定义与设计工作，时间是前者的两倍以上都在可接受之列。
2、团队能力。人永远是最重要的因素，要多长时间可以做成项目，机构内部是否有战斗力可靠的团队是最关键的变量–没有之一。对项目的执行1号位（通常是CIO）而言，手底下是否有一支服从指挥、执行力强大、专业能力（兼具业务和技术）突出的IT队伍，是支持其敢于作出决策的最大底牌，如果要做出比较激进的项目计划，一定要有这张底牌。反之，则需要为项目计划预留足够冗余，并在项目过程中，更多取得供应商和业务单位的支持。
3、厂商选择。显而易见，相关话题不作展开。
4、同业参照。选择已经进行过核心系统建设的同业机构作为参照系，是进行项目决策最简单的途径。但是，选择什么样的同业会有讲究：资产规模相似、客群结构相似、业务结构相似、团队情况相似、甚至应用架构相似的同业，更有参考价值。千万要避免别人行我就行的错觉。
除此之外，要有效压缩项目周期，还有些办法可供参考：
1、提前从核心剥离一些相对独立的服务。对技术主官而言，如果银行的旧核心已经进入生命周期的尾声，则在换心项目开始前，需要有意识地将一些服务尽可能提前地从核心剥离，比如将贷款账务、现金管理、存管账户等从核心剥离，建设为独立的服务，这样，可以有效降低新核心本身的项目复杂度，并有效缩短项目建设周期；
2、提前进行技术栈验证和新技术运维体系的构建。如果新核心将采用的技术栈是基于云原生、分布式的。则需要尽量避免在核心建设时，再去引入IaaS和PaaS能力，在核心系统开始前，选择一些相对简单的系统，比如客户信息、商户收单一类的系统，做云原生和分布式改造，并在过程中提前完成私有云的构建，对分布式数据库、分布式中间件、分布式事务管理器、云管平台等完成功能和性能验证，搭建好云原生架构下的运维体系框架。在新核心系统建设启动后，要做的只是对私有云的扩容，将核心系统建设尽可能约束为应用系统建设项目，而不要既是应用项目，又是基础运维项目；
3、提前开始需求编写和功能梳理。换心项目中，需要确保现有系统功能得到继承与实现，并确保核心系统与周边系统的集成能够衔接顺畅。换心过程中，如果能够提前对现核心进行整体功能梳理，并完成对外提供的接口清单的梳理，形成有效、准确的文档，将大幅减少后续需求差异分析的工作量，确保未来新系统提供的功能完整性，避免对业务连续性的冲击。但这又回到团队能力问题，在核心系统正式启动前，业务单位不太可能配合来完成这项工作，只能依靠技术团队，尤其是核心系统的开发团队，作为技术主官，手上有一支这样“召之即来、来之能战”队伍，非常关键。P.S：核心系统在真正Kick off前，其实会有大量的项目论证、选型、预算审批、招采等过程中，这段时间起码持续半年以上，这段时间就是技术团队提前完成现系统需求和接口梳理的黄金时间，很多成功的案例会告诉你1年半载就做完了，但不会告诉你技术团队其实2年前就开始做准备了…..
项目组织与关键人员识别
无论是提前从核心剥离部分服务，还是提前构建面向云原生的运维体系，抑或是提前开始编写需求，都离不开有效的项目组织。虽然说“一艘没有目的地的航船，任何风向都是逆风”，但吉姆.柯林斯在其名作《从优秀到卓越》一书中也指出：“先人后事”（“First Who, Then What”）其实更重要。因为哪怕航行方向尚未完全明确，优秀的水手也能够适应变化、主动调整船的方向，找到最佳航线。这一观点不但在企业管理中被反复验证，在“核心建设”这样的项目中，也同样适用。我们讨论几个问题：
IT内部的人员准备。核心系统作为CIO直接领导的项目，在技术主官之下，要确保项目顺利推进，首先需要在核心系统所有分子系统的领域，都有能够独挡一面的技术1号位（关键人员），包括：平台技术底座1到2人，存款服务若干人（视服务如何拆分）、客户服务至少2人以上，保证金服务、存放同业服务、产品、定价、收费、内部户、会计引擎等等各若干人。这部分关键人员的画像：必须具备娴熟的代码能力，必须拥有对应领域的业务知识，无需严苛管理、能够自我驱动、主动工作，如果他还刚好具备良好的沟通能力、产品思维，那就是捡到宝了。总而言之，先需要一个至少20人左右的核心系统骨干团队；其次，还需要一位不但技术能力、业务能力突出，还能够有效进行团队组织，并与兄弟团队进行良好沟通的核心系统团队长；再次，需要开发部门总能够在技术主官领导下，既充分参与核心系统建设过程的全局架构设计，又有效推动周边系统开发团队与核心系统团队的配合，并通过与业务部门之间的有效沟通，帮助开发团队获得业务支持；最后，需要运维部门总经理以下全体成员能够与开发团队主动协同，以服务者而不是管理者角色–变“XX事项你要提单给我”为“XX事项我们已经帮你准备好了”，带领团队为项目建设提供有力的基础设施支持。
跨团队临时组织。核心系统建设项目，不可避免地会按矩阵方式设置一些跨团队的临时组织，但跨团队组织建议越少越好，原因一方面是对大部分组织架构成熟的企业而言，核心系统建设，与多数日常项目并无特别大的不同，需求、设计、开发、SIT、UAT、投产，都有明确的团队在各司其职，并不需要另起炉灶；另一方面，跨团队组织的一个很容易掉入的陷阱，是“权责”不对等，临时设立的组织，对其团队成员，通常不具备有效的管理手段–如果考核关系不在临时团队，凭什么要听你的？几点建议：1）、临时团队能不设立就不设立，项目过程中一些需要进行整体统筹的，由部门总经理组成的，在CIO领导下的执行小组进行跨部门协调就好；2）、需要跨团队协调的工作，主要出现在需求、UAT测试及投产演练阶段，银行完全有能力临时进行组织；3）、跨部门协作事项的进度跟进及风险预报，由PMO团队跟进即可；4）、IT部门内部，应该按照现行行政组织架构，进行工作分工–设定权责，如果现行组织架构不满足项目建设需要，需要调整的，则应该在项目开始前即调整到位。这样有利于保证项目的执行架构，就是未来的组织架构–避免项目完成后的团队动荡。
开发与测试的协同。在日常开发工作中，开发与测试的职能分工，最好的模式应该是“同甘苦、共患难”，进退一体，有功一起赏，有事故一起罚。其原因是，很多应用系统的生产事故，大多都是从开发到测试被整体击穿导致的，开发和测试的职能边界存在很大的灰色地带，如果在问责时非要泾渭分明，必然导致相互推诿，通常表现在：1）、开发过程中，相互处处设防，事事留痕，大量内耗；2）、测试团队为了免责，会设置各种莫名其妙的刚性指标，比如冒烟测试通过率、测试缺陷率、单元测试覆盖率等等，最后为了形式合规，大家一起玩成文字游戏。最后的结果就是，事故没降下来，两个团队之间产生大量内耗，并且关系也从精诚合作变成了处处提防。但在核心建设，或其他大型项目中，开发和测试，则不应继续这种工作模式，而应该将测试团队变成开发团队的监督者，原因是在大型项目中，涉及的开发事项千头万绪，必须通过上下游制衡尽快充分暴露项目的风险和问题，此时，通过测试团队客观地反映开发工作中没有做好或者没有做完的事项，对有效识别项目风险，非常重要。
业务骨干的卷入。核心系统建设，关系最大的业务单位是偏中后台的运营与财务，因此，如果CIO是项目组组长的话，COO和CFO就至少需要作为常务副组长角色存在。对应的，运营部总经理、财务部总经理，以及对应的集中作业团队、分支行柜面管理团队、会计团队等，也都是项目的关键业务方，这些部门或团队中，需要有精通流程设计、精通银行会计账务、具备丰富的实操经验，以及有能力进行顶层设计的骨干人员参与，项目启动后，圈定这样一些关键人员，将非常有助于项目的后续推进。
厂商关键人员的锚定。同样一个系统，厂商在A机构实施和在B机构实施，取得的效果时常会差别巨大，除了甲方的能力差别外，厂商关键人员的控场能力是其中的关键变量。对项目而言，最好的乙方现场负责人，不是一味屈从银行意志，有求必应的响应者，而是能够根据银行的诉求，结合系统特点，并基于项目约束条件，给出合理化建议的人；退而求其次，也应该是能够时时将项目上线放在第一位，敢于顶住甲方压力，强硬拒绝甲方需求天马行空、灾难性蔓延的人。这样的乙方一号位，其能力画像是：有丰富的核心系统建设经验，具备扎实的业务知识，对乙方的系统了然于胸，技术水平突出，个性强硬又懂得适时妥协。怎么识别呢？乙方在POC阶段出场的，多数时候会是个中佼佼者，但是，POC或者售前阶段出场的，有时候只是临时救场的，他很厉害，但这种人到处都需要，厂商不一定就能派给你。因此，对甲方而言，可以要求在POC阶段，就指定由未来的厂商项目经理负责各项讲解，一旦相中，未来可以在合同中固定人员名单。选好厂商的交付负责人，比选好厂商可能更重要。
项目的外部合作方
项目的关键合作方，毫无疑问是核心系统厂商，这个不需要讨论。本节主要讨论一下除核心系统厂商之外的，其他外包合作方。
咨询服务。集中式核心建设时期，很多时候会引入咨询公司，帮助设计信息化后的组织架构和业务流程，对业务治理和IT治理提供建议，这一时期，以IBM为代表的厂商，具备从咨询顾问、到应用系统实施、到提供全栈软硬件的能力，是真正的集大成者开放式核心兴起后，伴随着IBM逐步退出应用系统建设领域，咨询服务也开始逐步淡出。但是否需要咨询服务，与项目目标有关，如果管理层的目标不仅仅是上线一个新的核心，而是藉由核心建设，推动全行治理优化，则可以考虑引入咨询公司提供针对性建议；如果只是换心本身，则无太大必要大费周章。
PMO服务。核心建设的另一项重要服务，是PMO服务，为核心系统的项目管理，提供专业化的支持。PMO服务在项目过程中，建议进行引入。其一，千金难买是教训，如中电优智汇等专业PMO公司，可以将行业大量项目建设案例，特别是项目过程中的优秀实践和血泪教训进行共享，帮助甲方有效避坑；其二，对项目的第一责任人（一般是CIO）而言，项目中千头万绪的事项，需要有人来充当眼睛和耳朵，协助CIO对项目的整体健康度进行检查和监督，而怎么检查与监督，需要专业技巧；其三，外部PMO在项目过程中，因为不牵涉行内部门、人事纠葛，相当于一个独立第三方，最有条件对项目的风险进行客观揭示和向上反映，确保项目始终处于健康的轨道上。不过，银行自己才是项目的最终责任人，不管是核心系统集成商还是PMO厂商，银行都不应将项目的成败寄托在厂商身上，因为项目需求梳理的细节、各个系统建设状态、各个功能点的完成度和健壮性、系统监控是否完善、操作培训是否到位等等细节，最终还是需要行内团队以高度的责任心自己对自己负责。
测试服务。包括SIT和UAT测试，由于人手所限，银行不可能储备足够的人手自己完成测试工作，因此通常需要外购测试资源进行支持。这里的建议是：1）、如果要补充测试资源，则自SIT阶段开始，即应开始引入，以供引入的测试人员有足够的时间熟悉系统，在对功能掌握全面后，才有机会在UAT阶段面向用户使用做进一步的测试；2）、测试资源可以通过外包补充，但测试质量必须由行方自己进行保障，尤其在UAT测试阶段。测试执行可以外包，测试方案设计、测试案例编写等关键性工作，则不能外包，或者至少，也应该是在行方深度参与下，外包协助进行。因为，UAT测试实质上是对系统是否满足未来操作需要，即是否有效满足使用要求进行检验，外包人员并不是系统最终用户，没有条件真正结合实际使用需要进行判断。
云服务。H（华为）A（阿里）T（腾讯）均有较成熟的私有云解决方案，目前市场上的核心系统集成商，基本都支持对不同云厂商产品的适配，这里主要涉及未来软硬件技术栈的选择，笔者非运维专业人士，仅做提及，不敢置喙。
周边开发服务。核心建设，还需要考虑的一部分是周边系统的改造，如果不能自研或者在日常外包人力中消化，这部分的开发资源需求，记得纳入项目整体预算就好。
项目风险管理
银行项目，只要定义清楚了项目目标，说清楚需求，技术上就都能做到，技术方案本身，并不存在什么风险。项目风险管理主要目标，是项目时间管理与项目预算管理，即保证项目不要延期，不要超出预算。
项目时间管理。核心建设这样的大型项目，一般采用瀑布式项目管理，将项目分为需求、设计、开发与自测、系统集成测试、UAT测试、投产演练、上线发布几个阶段。这里主要分享几点容易踩坑的点：1）、需求随便糊弄，到UAT阶段再大量返工，是常见的导致项目返工的重大风险成因。需求阶段大家看不到成品，很难判断需求的质量与完整度，因此也最容易交差。对应的建议是：a、保证需求阶段在项目整体计划中的时间投入，如需求占项目的时间，至少与开发时间相等；b、要求结构完整的明确的交付物，以标准需求模版交付需求规格说明书；c、杀鸡儆猴，业务部门总和开发部门总，对一些关键需求进行抽检，发现不合格的需求，即对责任人进行强力问责。2）、不留时间冗余。对项目组公布的项目计划与每个阶段的时间计划，与管理层可接受的项目计划相比，要预留出冗余，如果管理层可接受的时间是1年半，则对项目组公布的计划，至少应该提前到15个月，就紧不就松，每个阶段应该预留出15%到20%的时间冗余，以应对各种不可预测的意外，这个原理跟打仗类似，大型战役，一定要保留预备队。3）、建议将测试或者投产演练的时间留的尽可能多（自SIT阶段开始到投产上线阶段的时间，建议为开发阶段的2~3倍），即在项目的推进上，前紧后宽，原因是，测试是检验成果的最有效手段，一旦有风险，还有足够的时间转圜（但这个对开发团队的挑战巨大，实操上，还要看开发团队的能力，以及是否与管理者之间建立了足够的信任，如果开发团队足够值得信赖，按合理的方式制定计划，是更好的选择）。
项目预算管理。仍然是需要进行冗余管理，预留占总预算盘子的20%左右的资金，作为预备资金。一方面，核心系统建设牵扯面巨大，很多开支在计划阶段难免挂万漏一，计划外开支很难避免；另一方面，需要为可能的项目延期，做充足的准备，因为参与厂商都是按主计划进行投入的，一旦因非乙方原因导致延期，厂商会不会主张额外费用，殊难预料，家里有粮，心中不慌。但预留冗余，不等于预算管理可以随便搞，从预算到合同、到付款，需要有专门的团队，建立清晰的台账，并进行有效的管理。
项目进度监控。看战线，而不要看战报。什么周报、日报之类的，尽量不要去做要求，因为写在周报里面的，要么是一切正常，要么是有风险，但是别人导致的，有效信息非常有限。比较有效的办法，还是部门总经理一级的管理者，要亲自下场，根据项目所处的阶段，调文档、调代码、做系统现场演示，现场抽查真实的进展，抓几个弄虚作假的典型，比什么效果都好。
项目信息共享。信息共享不及时，是导致项目风险的又一因素。在核心项目建设中，最容易出问题的，是核心系统的接口。在项目建设过程中，因为需求变更导致的接口变动，会非常频繁，另外，项目的一些统一决策，也需要有效地传递给项目组所有成员。这时候，建立有效的信息发布机制就非常重要。建议：1）、为所有成员分配行内邮箱，是最基本的操作，有些特定的职能小组，还应该建立邮件组；2）、引入腾讯文档、阿里语雀之类的共享文档工具（可以买私有化版本），通过共享文档发布公告，尤其是发布标准接口，非常重要。这方面，SVN，或者文档服务器之类的，远不如共享文档好用。
结语
大道至简，核心系统建设在银行业已经积累大量的成功实践，不同机构的实际情况千差万别，做好核心系统建设的项目管理，需要根据机构自身的情况因地制宜，但诸如“先人后事”，“权责对等”，“若无必要，勿增实体”，“凡事预则立、不预则废”，“冗余原则”等一些朴素的道理，仍应是行业通行的，只要做好这些基本遵循，核心系统就一定可以如期达成建设目标。