我国软件工业未来的生存空间

　　我国软件工业从上世纪90年代初期的接近60％的净利润（下同），下调到目前平均利润不到5％。这个现象说明我国的软件工业正在面临一个重大的危机，如何面对未来的挑战？继续生存和发展呢？

　　欧美软件企业目前还可以维持平均17％的利润，印度更能维持27％的利润。以我国一家年营业额达到人民币五千万的软件企业来说，规模已经不少，技术人员总有一百多人，但平均5％利润只能为企业带来人民币两百五十万元的净收益。万一有一两个大型项目发生重大延误的时候，这家软件企业便会面临一个严峻的考验，继续挣扎生存，还是改善运营的模式。

　　一些软件企业尝试引进项目管理，希望能够利用这门管理科学改善企业的效益，但在过去数年中，成功利用项目管理来提升项目实施效率，能够控制成本，能够提升交付质量的个案并不多见。项目经理只是一个高薪的技术人员，不但未能发挥项目管理的作用，也未能有效地使用项目管理的知识来降低项目的延误，减少项目范围变动的需求，有效地与客户进行沟通，适当的利用资源的技术能力来让项目如期完成项目的交付。

　　主要的原因是软件企业内部未有一个完善的管理环境，也缺乏一套可操作的管理制度。一些软件企业的领导多以“竞争激烈”为理由。但处于一个市场经济的大环境下，竞争是必然的事实，我们必须考虑如何提升自身的竞争能力，有效地降低交付成本，提升企业的利润，才能够面对未来的挑战，让企业能够继续发展。

我国软件工业的开发特色

　　从上世纪70年代开始从事软件开发的工作，分别在欧洲、美洲和澳洲等地经历了三十多年的IT项目经验。各地的IT从业人员都有明确的工作岗位和职责，从早期的程序员（Programmer），系统分析员（System Analysts），系统设计师（Systems Designers），系统工程师（Systems Engineers）等主要职位，到后期因应IT科技的技术发展而增加的通信/网络工程师（Communication/Network Engineers），数据库设计师（Database Designer），数据库管理员（Database Administrator），项目经理（Project Manager）等职位。但回顾我国的IT行业多只有软件工程师的职位，其中可能分为高级工程师，中级工程师，和初级工程师三大类。一些企业内部可能会添加网络管理员来维护网络系统的运行。

　　国外IT企业的岗位是依据企业所采用的系统开发体系(System Development Methodology)和企业本身的商业运营模型（Business Operation Models）而建设。主要是为了建立技术人员的专业能力，让技术人员有足够的时间一步一步地学习和扩展本身的专业知识和提升技术水平，从开始进入行业执行编码的工作，积累足够的经验后才开始进入系统分析的工作，能够积累分析问题和找出原因的经验后才知道如何解决问题成为系统设计师。在整个项目开发过程中利用不同的专业人员本身的经验和专长在不同的阶段提供最优质的交付。

　　其中最重要的一环是团队必须定期进行沟通，把自己发掘及建立的信息不断转移到其他成员身上，不断互相进行比较。系统设计师依据系统分析师所建立的系统需求说明来建设系统的架构和逻辑，建立系统和程序的规格，然后交由程序员按照规格进行编写。测试结果必须与系统需求和系统规格吻合后才能够完成交付。对系统的质量在过程中受到全面的监控和审核。

反观我国大部分软件企业在系统开发过程中，完全是一个软件工程师对一个模块、或一个功能、或一个子系统进行全程负责，从开始调研、到设计、到编码、到测试、到安装，到文档编写、完全是“从一而终”。我们的软件工程师是全能的工程师，可以负担整个开发过程中所需的工作。但很明显易见，我们的全能软件工程师并没有达到我们的要求，不管是执行调研的任务，还是设计的任务，还是编码的工作，还是测试的过程，我们的软件工程师是“通”而不“精”。导致项目开发过程中不断进行返工，修改，和测试。到最后系统勉强进行交付，后期补上的文档不但未能符合系统工程的基本要求，而且“残缺不全”，对系统的逻辑和后期的维护带来负面的结果。这个开发模式我称为CAF开发模式（Code and Fix），在开发过程中不断进行修改，测试，返工，测试，重做，测试，在修改，到最后，程序的逻辑出来这位软件工程师外，其他技术人员绝对没有办法理解。

　　更重要的一点是我们的软件工程师不着重“分析”，缺乏了分析的过程，我们便不能够理解企业建设系统背后的原因，未能把握问题，我们便不能够设计高效的解决方案，更缺乏创新的思维。所以我们大部分软件工程师在调研阶段是希望能够从客户口中获知系统的功能需求，而不是从把握现状后对信息进行分析，结论出系统的功能需求（请参阅“我国软件工程的冤枉路”一文）。

降低系统开发成本

　　我国软件企业对服务报价也有本身的特色，就是一口价。我说的一口价并不是众所周知的“定额合同”总费用的一口价，是我们在合同内报价那部分编列出来“共？？？工作天或？？？人月”的费用。我国软件企业多以一个基准费用进行报价，不管是高级软件工程师，中级软件工程师，初级软件工程师，或项目经理，这个基准费用适用于各级别的技术人员，基准收费如何建设不在本文范围，但可以肯定，这个基准费用不会为企业带来很大的利润空间。再加上合同谈判过程中被客户压价，那么合同的总费用更没有多余的空间来应对项目延误所带来的损失。 

　　大家都知道，软件工程这个行业的最大成本支出是劳动资源的费用，工龄越久的技术人员工资可能是新进技术人员的十倍，而我们所惯用的CAF模式主要工作量是编码和测试，修改和测试，或返工和测试。这些工作估计占去整个系统开发工作量的70％。能够建立一套模式可以让初级人员负责编码的全部工作，当然可以降低服务成本，提升企业的利润。

改善CAF开发模式

　　我国的一些软件改进协会和学会组织，只把焦点集中在某类技术应用上进行改善和改进，从未考虑改进我国的系统开发流程，建立一套适合我国软件工程环境的开发体系。技术上应用的改进不能够降低我们在开发过程中的返工和重做的需要，我们要提升软件工程师的调研能力，分析能力，设计能力和沟通能力，进行有效的分工，提供合理的开发成本和管理方法，才能够帮助我国的软件工业摆脱目前的困境。

　　我们不能一下子把目前的CAF开发模式调整为国外惯用的架构性系统开发体系。但我们可以改善目前的CAF开发模式，让我们能够在改善的过程中不断调整和培育技术人员对系统开发过程的专业能力。

　　首先是让管理人员和中、高级软件工程师认同一套合理的系统开发文档，内容、填写方法和执行人。开始的初期不用划分太细，否则会产生很多矛盾和争议。开发模式大致上可以分为前期阶段，编写阶段和结项阶段。每一个阶段中的工作以工作包进行授权，实施，和审核。目的是让中、高级软件工程师编写合理和完整的系统规格说明书让初级软件工程师可以按照系统规格编写有关程序，同时在高级工程师或技术总监的指导下让初级软件工程师按照规格和系统需求进行程序和模块的测试。

　　结项会议是整个改善模式最重要的一环，目的是让项目组成员回顾项目实施过程中任何可以学习和改善的地方，对信息收集的方法，需求分析和说明的内容，系统设计和规格说明等文档内容可以改善的地方和方法，记录在案并发布，让其他项目组成员能够从中学习。同时可以尝试归纳项目的个别工作包内容，建立架构性的项目开发流程。慢慢改善软件工程师的开发能力，配合软件开发流程，达到“人尽其才”的最终目的。

　　同时让初级软件工程师负责全部编码工作，可以降低项目的开发成本，提升企业的利润。

全面的改革

　　要全面改革我国的软件工业，能够与国际企业竞争国际市场，我们必须规范本身的技术应用方法，项目管理不能够有效管理不规范的技术实施过程。在我们未能改善技术的实施过程前，任何项目管理知识和体系也不能够帮助我们提升效率。以目前我国软件工业平均利润指标来衡量未来发展的空间，只有改革技术实施过程，提升技术资源的专业能力，配合实施过程的需求，和配合科学管理的概念，才能够开展软件企业的潜能，拓展未来的生存空间。
 

原文转自：http://www.ltesting.net