阳光保险总裁助理、金融科技专家、经济专栏作家

前段时间，领导多次强调，要尽快完成某项重点工程。团队成员非常清楚项目的重要性，积极加班。我以为领导知道大家都在努力，应该明白发展毕竟需要一定的时间。结果，在每月的工作会议上，领导对项目的进展非常不满意。批评这样一个简单明了的项目花了这么长时间。要求无论怎样都必须在规定的时间节点投产。

◆◆◆

1. 重新认识IT开发工作量

领导或业务部门对IT工作最常抱怨的就是开发周期长。这很大程度上是因为没有看到IT开发的全部工作量而产生的误解。外行人只能从表面上开发实现的功能来了解IT开发的工作量，但IT实际需要完成的工作远不止于此。例如，在汇款时，大多数人只会想到从一个账户的余额中扣除要汇出的金额，然后将其添加到另一个要汇出的账户的余额中。

汇款系统实际开发过程中，应考虑记录汇款操作处理明细、查询汇款明细、为可能出现的错录提供会计处理支持、与汇款机构的资金结算、汇款机构名录管理、反洗钱管理、 IT工作量就像海上的冰山，水下的体积巨大。

开发的产品承载的用户数量决定了相应建设工作量的规模和复杂程度。搭建一个临时避难所只需一个人几个小时就可以完成。如果你想建造一栋可供一家人安居的平房，就必须考虑保暖防寒、耐用性、出入方便性、隐私和安全等因素。除了自己做大量的准备工作外，还需要很多有经验的朋友和邻居。在别人的帮助下，我忙活了几十天。

如果要建造一座可供数百人居住的建筑，就必须考虑更多的给排水、通讯、隔音、通风、照明和消防等因素。依靠大量专业施工工程师和施工人员，历时一年多才完工。如果要建造一栋摩天大楼，会有很多完全不同的考虑，需要相应的专业团队、社会协作以及几年以上的建设。

随着用户数量的增加，建筑物的架构将完全不同，规模和复杂性将呈指数级增长。不同架构的工程量和复杂度基本处于同一数量级。无论细节如何简化，工程周期总会超出一定的时间范围。软件系统开发基本遵循相同的规则。只要使用规模增大，就必须有相应的架构支持，这肯定会显着延长开发周期。

单用户架构允许一个用户自由操作，但不可能数百人同时使用。必须升级为支持多任务的架构系统。如果数万人同时操作，则必须在支持大规模并行处理的可扩展架构上运行。随着用户数量的增加，所需开发人员的数量和能力将完全不同。

不同架构的复杂度和开发工作量是完全无法比拟的。开发者需要根据预期的业务发展规模配置相应的架构。如果业务量较小，同时使用的用户较少，可以采用比较简单的架构，相应的开发工作量也会比较小。更大的业务量需要更复杂的架构。大量的程序互连和调用，需要考虑的情况呈指数级增长，导致调试和测试工作量曲线急剧上升。

领导和业务部门要求项目能够在短时间内开发出来，这是完全可以理解的。但工程师不是魔术师，必须遵守客观规律的要求。在完成所有必要的工作之前，系统无法投入使用。大量的开发工作无法并行。即使加班或者增加人力，对于缩短开发周期的作用也非常有限。

减少开发工作将对项目完成时间产生根本性影响。压缩项目开发实现的功能可以在一定程度上减少开发工作量。降低对交易容量、安全性和可扩展性的要求，可以简化系统架构，大幅减少开发工作量。但在做出决定之前，你需要想清楚哪些牺牲的需求比时间安排更重要，以及你将如何处理未来可能出现的情况。

对于用户使用前期无法预估的实验性创新项目，为了避免浪费，可以从一个简单的项目开始。在实际环境中检验其未来的发展潜力后，我们才能考虑未来如何加大发展投入。如果你非常清楚这个系统未来将扮演什么角色，有多大，那么你就不能偷工减料。必须采用满足业务发展需求的系统架构。

一些领导认为，只要对IT团队采取高压措施，就能缩短工期。 IT团队可能会面临压力，不得不专注于眼前的开发进度，采用简化的系统架构，从而为未来埋下隐患。有些工作量无法节省，必须保证足够的开发时间。如果我们不做那些重要但不紧急的事情，那么事情就会变得不仅重要而且非常紧急，让你抱怨不已。

有时业务部门提出一些新的功能需求，认为只是对现有系统的部分补充修改，不应该做太多工作。如果现有的架构支持的话，确实会很容易完成相关的开发工作。如果现有架构不支持需求，就需要对现有架构进行修改或者更换新的架构，这并不是那么简单的事情。

这个时候，你要么要心存委屈，根据现有架构的限制去改变自己的需求；要么或者你必须要有耐心，花费更多的时间、成本和开发资源来修改或更换架构。这就是公司随着时间的推移升级其核心系统的原因。所谓新一代核心系统，实际上就是在架构上进行根本性改变，采用最新的技术手段来满足业务发展的要求。

◆◆◆

2. 过去的经验和教训

2000年随着互联网的兴起，我觉得银行应用互联网将是一个趋势。开发中心组织了几个人的团队进行研究，开发出了适合少量用户的系统原型。设计中使用的架构非常简单，但演示却相当不错。在一次与业务部门的沟通中，我向对方介绍了一个可以让客户通过互联网远程操作账户的应用系统原型。

对方看到演示后非常兴奋，要求立即投入生产和推广。我吓坏了，赶紧解释说这只是一个原型，还有很多未完成的开发工作，所以还没准备好投入生产。对方感到非常失望，强烈希望尽快完成剩余的开发工作，并在最短的时间内投入生产，力争成为中国第一家提供互联网业务服务的银行。

这种目标追求对于我们技术人员来说也是非常有吸引力的。双方一拍即合，决定共同努力，尽快让系统上线。由于工作的重点是速度，所以一切都应该围绕早期生产进行。为了节省时间，我们决定基于现有的简单架构进行后续开发。项目进展比较顺利，各部分配套功能很快就完成了。投产后市场反应良好，系统能够支撑当时的业务规模。

此时，该行高层敏锐地意识到互联网发展的战略机遇，决定成立电子银行部，大力发展电子银行业务。新部门一成立，就专注于向客户推荐网上银行服务。随着全国分支机构的积极营销，系统日交易量快速增长。一开始我还挺高兴，但很快就意识到系统容量可能无法支持。

我赶紧安排研究寻找对策，了解到更换高端机械设备可以在一定程度上缓解压力。而且以目前的架构和业务上升趋势，即使选择顶级配置也坚持不了多久。唯一的办法是改造现有架构，但时间已经不多了。他心中有一种不祥的预感。遗憾的是，前期为了速度，选择了支持小规模应用的架构。

第一时间抽调大量精锐部队，开发高并发架构下的第二代互联网银行系统。同时，更换高端机械设备，尽可能扩大系统容量。我担心的事情还是发生了。业务很快出现爆发式增长，一开始我们通过性能调优来应对，持续了几天。终于有一天，系统不堪重负，连续三天无法正常运行。它对该行业的声誉造成了毁灭性的影响。

没办法，我只能硬着头皮尝试优化旧的架构，想办法让它在一定程度上能够支持多机器、多设备的并行处理。我们只能优先保证系统能够提供最基本的服务，而忽略其他的。所展示的客户体验确实令人不快。业务部门非常支持，暂停新用户注册审批，引导用户非高峰时段使用，并手动提供紧急服务。经过一番尴尬的波折后，局势终于稳定下来，赢得了更多的时间。

当第二代网上银行系统投产后，一切都归于平静。在业务方面，我们可以全力以赴开拓市场，在技术方面，我们可以根据业务需求提供稳定、快速的升级服务。这件事给了我一个非常深刻的教训。要明白，如果不合理预估业务发展前景，一味使用简化架构来追求上线速度，最终必然会受到惩罚。

◆◆◆

3. 公开、诚实地寻求理解和支持

很多年前，当我为银行信用卡部门开发系统时，业务负责人抱怨我们主机项目组的开发周期太长。几乎同样的需求提交给微机项目组并很快完成，但在我们的案例中却被延迟了。给出这样的证据看起来很有说服力，但他不知道他实际上是在用两个完全不同的系统来比较发展规模。

从表面上看，两个系统实现的功能没有太大区别，但最终生产所需的结果却有很大不同。微机系统只能满足市内某信用卡中心柜员的日常操作。上位机除满足全市信用卡中心日常业务外，还支持全市各储蓄网点柜员办理信用卡业务，实现与商户的消费对接，进行同市及全国资金结算，等等。两种系统架构的复杂度相差几个数量级。

我跟他讲了上面的原则，他似乎也明白了，但没过多久，同样的抱怨又来了。这极大地影响了开发团队的情绪，也造成了业务方和技术方之间的隔阂。看来他心中一直有疑虑，必须彻底消除。在项目很忙的时候，我找到了一个比较完整的时间和他进行了深入的交流。

我拿出项目系统开发说明书，把涉及到的所有开发工作一一给他指出。详细解释一下这意味着什么工作以及会消耗多少开发资源。对于自己不太理解的工作项，说明这部分工作做得不好会带来什么后果，实施后对整个系统有什么帮助。让他们明白这些任务是必不可少的，只有这样才能支持他们业务的持续发展。

虽然对方没有完全信服，但他对我们的工作有了比较完整的了解，明白这与计算机开发团队所做的工作不能直接相提并论。他逐渐改变了态度，变得更愿意倾听我们的想法，并尽力参与和配合整个开发工作。由于我们平时一起工作，所以他能清楚地看到我们每天的努力程度。大家逐渐建立了相互信任，团结成了战斗集体，项目进展越来越顺利。

当开发的信用卡系统成功投产推广后，业务部门终于看到了主机版本带来的优势。已投产的城市机构竞争力已超越同行，业绩显着提升。相应的微机版本虽然具有先发优势，但推广后的效果却并不理想。由于系统架构的限制，未来很难做出根本性的改进。维持一段时间后，逐渐被淘汰。

文章开头提到的项目进展终于按照领导的要求启动了。由于生产时间无法改变，又必须保证项目质量，唯一的解决办法就是将项目分成两期。第一阶段，首先实现业务事务处理，通过人工辅助完成与其他系统的对接操作。第二阶段将开发与其他相关系统的直接连接，完全实现全流程操作的自动化。幸运的是，项目的特性适合这样的拆分。