为什么IT项目开发周期远比想象中的长？

苏文力

减少开发工作量才会对项目完成时间产生根本的影响。压缩项目开发实现的功能可以在一定程度上减少开发工作量。降低交易容量、安全性和可扩充性等方面要求，则可以让系统的架构变简单，大幅度降低开发工作量。但在做出决定之前要想清楚，所牺牲掉的这些要求与时间进度相比到底谁更重要，后续将怎样应对可能会出现的局面。

前段时间，领导多次强调某重点项目应早日完成。团队成员都非常清楚该项目的重要意义，主动开启加班加点工作模式。自己以为领导知道大家都在全力以赴，应该能理解开发毕竟需要一定的时间周期。结果在月度工作会上，领导对于项目进度很不满意。批评这么简单明确的项目，却拖了如此长的时间。要求无论如何必须在规定的时间节点上投产上线。

重新理解IT开发工作量

领导或业务部门对IT工作最常见的抱怨是开发工期长。这很大程度是因未看到IT开发的全部工作量而造成的误解。外行仅能从表面开发实现的功能去理解IT开发工作量，而实际IT所需完成的工作远不止于此。比如说汇款，一般人只会想到从一个账户的资金余额中扣除所要汇出的金额数目，加入到所要汇入的另一个账户的余额中。

实际开发汇款系统过程中要考虑记录汇款操作处理明细、查询汇款详情、为可能发生的记错账状况提供账务处理支持、与汇款机构间资金清算、通汇机构目录管理、反洗钱管理、系统故障后的数据恢复处理，以及未来调整汇款手续费等参数设置管理等等。IT工作量很像海上的冰山，水面以下有着巨大的体量。

开发产品所承载的用户数量决定了相应的建设工作量规模和复杂度。搭个临时住的窝棚，一个人数小时就可以完成。若要盖个一家人可以安顿下来的平房，则要考虑保暖防寒、坚固耐用、出入方便和私密安全等等因素，除了自己大量的准备工作外，还需要有经验的朋友和左邻右舍很多人帮助，忙活几十天。

如果要建筑上百人居住的楼房，那就还要考虑上下水、通讯、隔音、通风、采光和消防等更多因素。必须依靠大批专业建筑工程师和施工人员，耗费一年多时间才能完成。如果要承建摩天大楼，则又会有许多完全不同的考虑因素，需要相应的专业团队，社会化协作，建设数年以上。

随着用户人数的上升，建筑的架构会完全不同，规模和复杂度就会呈几何级数的递增。不同架构的工程量和复杂度基本在一个数量级。不管细节上如何简化，工程周期总会在一定时间范围以上。软件系统开发也基本遵循同样的规律。只要使用规模上去了，就必须有相应的架构支持，就一定会大幅延长开发周期。

单用户架构可以让一个用户自如操作，但不可能让上百人同时使用。必须升级到支持多任务处理的架构系统上。若上万人同时操作，就必须运作在支持大规模并行处理的可扩展架構上。随着用户数的增加，所需要的开发人员数量和能力要求会完全不同。

不同架构的复杂度和开发工作量完全不可类比。开发者需要根据业务发展规模预期，配置相应的架构。若业务量很小，同时使用的用户少，就可以用比较简单的架构，相应的开发工作量就比较小。业务量规模大，就要配套更复杂的架构。大量程序间相互连接调用，需要考虑的情况成倍增加，造成调试测试工作量曲线陡直上升。

领导和业务部门要求短时间内就将项目开发出来，其心情完全可以理解。但工程人员不是魔术师，也必须符合客观规律的要求。只有完成所有必要的工作才能将系统交付使用。大量开发工作无法并行，即便加班或增加人手，对于缩短开发周期的作用也十分有限。

减少开发工作量才会对项目完成时间产生根本的影响。压缩项目开发实现的功能可以在一定程度上减少开发工作量。降低交易容量、安全性和可扩充性等方面要求，则可以让系统的架构变简单，大幅度降低开发工作量。但在做出决定之前要想清楚，所牺牲掉的这些要求与时间进度相比到底谁更重要，后续将怎样应对可能会出现的局面。

对于初期无法估算有多大用户使用量的实验性创新项目，为避免浪费，可以先简单做出来。在实际环境中检验其未来发展潜力后，再考虑后续如何加大开发投入。如果你很清楚系统未来将会起到什么作用，会有多大体量，那就不能偷工减料。必须采用符合业务发展要求的系统架构。

有些领导认为只要对IT团队采取高压手段，就会达到缩短工期的要求。IT团队很可能会迫于压力，偏重于眼前的开发进度，采用简化的系统架构，给未来埋下隐患。有些工作量是不能省的，必须保证足够的开发时间。如果我们不能做好那些重要而不紧急的工作事项，后面就会让事情变得不但重要，而且异常紧急，让你叫苦不迭。

有时候业务部门提出一些新功能要求，以为仅仅是对现有系统的部分补充修改，应该没太多工作量。若现有架构支持，的确会很容易完成相关的开发工作。如果所提要求在现有架构下不支持，就需要修改现有架构或更换新架构才能实现，那可就没那么简单了。

这时候要不就是你委屈一下，基于现有架构的条件限制，改变自己的需求;要不就是保持耐心，付出更多的时间成本和开发资源修改或更换架构。这就是为什么企业过段时间就会升级其核心系统的原因。所谓新一代核心系统，其实就是在架构上做出根本改变，采用最新技术手段，满足业务发展的要求。

曾经的经验教训

2000年互联网兴起，感觉银行应用互联网应该会是趋势。就在开发中心组织了几个人的团队进行研究，并开发出来了适合少数用户使用的系统原型。设计采用的架构十分简陋，但演示起来还挺像模像样。在与业务部门的一次交流中，向对方介绍有这么一个应用系统原型，可以让客户通过上网远程操作自己的账户。

对方看到演示后非常兴奋，要求马上投产推广。吓得我赶快解释说明这仅仅是个原型，还有大量开发工作未完成，完全不具备投入生产的条件。对方感觉很失望，强烈希望赶快完成剩下的开发工作，在最短的时间内投入生产，争取成为国内第一家开展互联网业务服务的银行。

这样的目标追求对于我们技术人员也很有吸引力，当下双方一拍即合，决定共同努力让系统尽快上线。既然工作重点是快，那一切就围绕早日投产开展工作。为省时间，我们决定在现有简易架构基础上开展后续开发。项目进展比较顺利，很快就将各部分配套功能开发完成。投产上线后市场反响不错，系统也能够支撑当时的业务规模。

就在此时，行里高层敏锐意识到互联网发展的战略契机，决定成立电子银行部，大力发展电子银行业务。新部门一成立就把向客户推荐互联网银行服务作为工作重点，随着全国各地分支机构的积极营销，系统每天的交易量迅速上升。一开始自己还挺高兴，但很快就意识到系统容量恐怕要撑不住了。

赶紧安排研究寻找对策，得知更换高档机器设备可以在一定程度上缓解压力。而以目前的架构和业务上升趋势，即便是选择最顶级配置，也坚持不了多长时间。唯一的方法是改造现有架构，但可利用的时间已经不多了。脑中呈现出一种不祥的预感。很后悔前期为了快，选择了支持小规模应用的架构。

第一时间赶紧安排大批精兵强将，开发高并发架构下的第二代互联网银行系统。同时更换高端机器设备，尽可能扩展系统容量。担心的事情还是发生了。业务很快迎来了爆发性增长，一开始还可以通过性能调优做出应对，坚持了一些日子，终于有一天系统被压跨，一连三天都无法正常运行。给行里的声誉带来了破坏性的影响。

被逼无奈只好硬着头皮尝试优化旧架构，想方设法使其能够在一定程度上支持多台机器设备并行处理。只能优先保证系统能够提供最基本的服务，其他也就顾不上了。表现出来的客户体验实在让人不敢恭维。业务部门很支持，暂缓了新用户的注册审批，引导用户错峰使用，人工提供应急服务。经过狼狈不堪的一通折腾，总算是稳住了局面，赢得了更多的时间。

当第二代互联网银行系统投产时，一切才算平静了下来。业务方面可以全力以赴的开拓市场，技术方面则能够针对业务需求提供稳定快速的升级服务。这件事给我带来的教训十分深刻。明白了若没有合理预估业务发展前景，一味用简化架构追求上线速度，最后必然会遭受惩罚。

开诚布公地寻求理解和支持

多年前为行里信用卡部开发系统，业务方面的负责人抱怨我们主机项目团队开发周期太长。差不多相同的需求提交给了微型机项目团队很快就能完成，而在我们这里却迟迟不能交付。给出这样的证据似乎很有说服力，但他并不清楚实际上这是拿了两个完全不同的系统在做开发规模比较。

表面上看二个系统实现的功能差别不大，但最终投产要求的效果差异巨大。微机系统只能满足城市一个信用卡中心柜员日常操作。主机除了满足城市信用卡中心日常操作外，还要支持一个城市所有储蓄网点柜员操作办理信用卡业务，与商户实现消费对接，开展同城和全国资金清算等等。二个系统架构的复杂度差着好几个数量级别。

跟他讲了讲上面那些道理，好像被理解了，可没过多久同样的抱怨就又来了。这很影响开发团队的心情，也让业务和技术双方产生了隔阂。看来其内心一直存在疑虑，必须彻底消除。在项目非常忙的情况下，找个比较完整的时间与其做了一次深入交流。

我拿出项目系统开发规格书，将涉及的所有开发工作一一指给他看。详细解释这意味着需要做那些工作，消耗多大的开发资源。针对其不太理解的工作事项，解释说明如果该部分工作没有做好会有哪些后果，实现后会对整个系统提供什么帮助。使其了解到这些工作必不可少，唯有此才能支持其业务后续的持续发展。

虽然没有让对方完全信服，但他对于我们工作有了比较完整的了解，知道了与微机开发团队所做工作并不可以直接比较。其逐渐转变了态度，更愿意听取我们的想法，并尽全力参与配合整个开发工作。由于平常工作地点就在一起，他能够很清楚的看到我们每天拼命的工作狀况。大家慢慢建立起了相互信任，团结成了一个战斗集体，项目进展越来越顺利。

当所开发的信用卡系统顺利投产推广后，业务部门终于看到了的主机版本带来的优势。投产应用的城市机构市场竞争力碾压同业，业绩大幅度提升。相对应的微机版本虽然有着先发优势，但推广后的效果则差强人意。受到系统架构方面的限制，其后续也难有根本性的改进。维持一段时间后，就逐渐被淘汰掉了。

文章开头所讲的项目进度最终还是按领导要求上线了。既然投产时间不能改变，项目质量也必须保证，解决的方法只能是将项目拆分成两期。一期先实现业务交易处理，采用人工辅助完成与其他系统的对接操作。二期再开发与其他相关系统的直通互联，彻底实现全流程操作自动化。算是运气比较好，该项目的特点适合进行这样的拆分。

（作者系阳光保险助理总裁）