统一版本的诱惑

几个月前从一家软件企业来到一家通信公司工作，进入了计费与信息系统部。这个部门维护着公司中的几个重要的系统：营业、计费、帐务、客户服务、资源管理、经营分析、产品销售，这些系统是公司业务的基础。通过几个月的忙碌，渐渐的熟悉了同事，也熟悉了工作环境，对于所维护的系统也有了越来越深的了解。

营业和帐务系统的开发商是由一家位于东北的软件公司。这是一家上市公司，CMM5级，在通信、医疗、教育等多个行业都有产品，其中通信系统遍布全国的十几个省。开发商在我们的现场有十多个现场维护人员，协助我们进行营业和帐务系统的运行维护工作。系统的升级、新需求的分析都需要他们的协助。

通过几个月的接触，了解了开发商的一些特点。最近有机会来到他们的总部，更是近距离的体验了他们的研发过程。开发商的一个很大的特点，就是采用“统一版本”的方式。具体的说就是：现场的维护人员原则上是不可以对代码做改动的。如果现场程序出现了问题，维护人员必须将现象和原因报告给总部的开发人员，由开发人员进行修改，然后总部发布新的版本，现场人员重新部署。客户提出了新的需求，也要现场人员进行分析以后提交到总部，进行统一的评估和测算，决定是否可以实现，用什么方式实现，然后将升级后的版本下发到各个省。这就是统一版本。全国各个省，都只使用同一个版本序列，各省根据自己的需要采用不同的版本号。各版本在总部统一维护，统一的规划，统一的标准，统一的软件。

统一版本的实质是追求思想的统一，避免在各个地区之间出现分歧。人的思想是一种非常复杂的东西，尤其软件开发是一种以脑力为主的劳动，需要大量的沟通才能减少误会。一百个人总会有一百个想法。在各个地区间采用统一的版本，由总部实行严格的管理，在软件的设计上和实施上就避免了意见分歧。

从项目管理的角度来说，采用统一版本的方式有利于对项目的范围和成本进行控制。客户的需求做不做，如何实现，什么时候实现，都由总部进行统一的规划，统一安排开发任务，实现在统一的版本中，然后下发到各地实施。这样就最大程度的避免了各地各自为战，原则不一致的现象。总部对各地维护人员的控制力是非常强的。

采用这样一种开发和维护方式，由总部的研发人员进行设计和开发，测试之后下发到各个省，由各省的现场维护人员进行部署和维护。软件系统在运行过程中发现错误，现场人员分析现场的状况，然后将情况反应到总部，由总部寻找具体的原因，进行修改后，现场人员重新部署。客户如果有新的需求，可以和现场人员一起进行探讨，现场人员向总部提出。总部对各个省的需求进行统一的规划，安排研发任务，测试完成以后再重新到现场部署。总部的开发人员和现场维护人员之间采用这样的分工方式：总部人员集中了技术能力，可以统一安排各个省的研发任务，统一调度。现场人员了解实际的软硬件环境，了解客户的实际需求。这样的分工看起来是非常合理的。

对于通信企业的应用系统来说，尽管在各个地区在业务方式上有各自的特殊情况，对系统的要求也不尽相同，但是毕竟是同样的经营领域，同样的企业性质，以共性为主，各省之间共同点是非常多的。采用统一的版本管理方式，也能够避免在不同版本之间重复实现一些共同的功能，避免重复的劳动，提高了开发工作的效率。

然而，采用这样的统一版本的方式，也带来不少问题。

最显然的问题就是：采用这样的方式，现场出现的问题和客户提出的需求无法得到及时的解决。通常是在现场发现一个故障，经过检查只不过是一个非常容易解决的问题。但是在统一版本的规则下，现场维护人员对版本没有控制权，必须向总部反应情况，得到解决之后再下发新的版本。这个过程有时候是相当长的。对于客户提出的新的需求，现场人员在经过分析后，也要提交到总部进行统一的规划，总部的人员对现场情况要进行了解，然后再统一的规划设计，安排开发力量。这样一个过程下来，环节很多，时间往往相当的长，要受到很多条件的限制。信息系统部经常因此面对业务部门大量的压力。如果能够将部分控制权交给现场的维护人员，对于简单的明显的故障、本地化的需求可以自行解决，在过程中保持和总部的协调，应该是一种更加理想的方式。

在系统的运行维护过程中，现场的维护人员经常比较忙碌，压力也是比较大的。由于总部的开发人员发过来的程序总是会出现各种问题，造成现场运维人员处于救火状态，难以抽出时间和人力对需求进行思考，没有精力分析客户的业务。总部的开发人员远在东北，他们了解现场需求的唯一途径就是通过现场维护人员。这样一来，形成了研发人员不了解需求的局面，开发质量难以保证。并且，一些地区的个性化需求无法在总部进行有效的测试，这些代码没有经过测试就发到现场，交给维护人员测试、部署。这样就使得总部的开发人员受到的质量压力过小，不注重提高质量，进一步造成质量下降。然后运维人员更加忙于救火，更加没有精力分析需求。

对需求没有了解，对现场的环境也缺乏直观的感受，造成设计和开发人员不注重用户的需求。研发人员经常是局限在技术细节中，将生动的客户需求生硬的理解成数据库的增删查改，顺带再向交换发几条指令。这样的研发过程，生产出来的软件是非常不好用的，功能凌乱，文档不着边际，bug也很多。造成用户操作和极其复杂，思想压力也比较大。

将所有的版本都放在总部统一管理，实际效果也并不理想。统一版本的管理工作是十分复杂的。各省都有特定的环境，都有一些特殊的需求，为了适应本地的环境、实现这些需求而开发了一些功能。每个地市的版本都处于动态的变化中，新的需求要做，旧版本上还有bug要改，整体结构的开发仍然在进行，造成分支复杂，版本很多，管理难度巨大，经常出现错误。总部发到地区的程序部署以后，总会发现以前曾经实现的需求又不见了，以前消灭过的bug又出现了。客户和运维人员很多精力耗费在丢失的功能和重现的bug中。由于版本管理方面有这方面的问题，产品的升级工作带来了巨大的困难。

电信企业需求可以分为两个层次，首先是具有行业特点的普遍性需求，这种需求较为稳定。其次是各运营商的个性化需求，这种需求复杂多变。各层次的需求应该由不同的人员、在不同的子系统中实现。核心的部分由一个小组进行开发，然后各个小组在这个基础上实现各地区特定的需求。底层的子系统的在进化的过程中，只要保持向后的兼容性，各地区的版本就不会受到影响。这样化整为零，减少了版本的复杂程度。升级维护都比较方便，也能够快速的响应个别客户的特别的需求。这样的开发形式是比较合理的。然而，开发商采用的是总部全权负责研发，现场全权负责维护的形式。总部研发人员负责全部的设计、编码、测试工作。在这种管理模式下，系统形成了一个统一的大版本，各地区的需求都实现在这个版本中。各地的一些需求相差较大，强行统一在一个版本中，甚至出现了下面这样的代码：

if 四川 then
　　......
else if 云南 then
　　......
else
　　......
end if

总部的开发人员没有在普遍需求和特定需求之间进行合理的分工，无法专注于解决行业内的普遍需求，有限的人力纠缠在各个地区独特的软硬件环境、应付独特的商业需求，耗费在细节上。而各地的维护人员面对着总部发过来的低质量的代码、僵化的设计、混乱的版本，部署维护困难重重。需求不能得到及时满足，程序bug需要漫长的过程才能改正，运营商得不到有力的支持。

软件系统的开发，技术无疑是重要的，但决不是最重要的，业务需求始终要在最重要的位置。技术的目的就是要在项目中消除技术问题，到最后开发者和客户在一起谈论的是用户的需求，互相之间不是用技术语言交谈，而是用客户的业务语言交谈。做到这一点，才是技术的成功之处。开发商现在已经为这个项目工作了多年，在多个地区都有了部署，现在仍然在和客户谈论数据库表、存储过程，不能深入到客户的业务中去。这不是一种理想的状态。

好的软件是用什么做出来的？不是用手，也不是用脑，而是用脚做出来的。要走出办公室，多跑一些地方，仔细的研究调查，才有可能了解客户，理解客户的需要。最后才能站在客户的角度考虑问题。这样做出来的东西，才是客户真正需要的东西。