工程实施人员和软件维护

软件维护常被工程人员误解为“系统维护”，即维护系统的正常运行。认为软件开发和软件维护是互相独立的两个工作。其实，软件维护是软件开发过程的组成部分。一个新版本的产品发布到现场之后，软件维护开始了，软件维护既是这次版本开发过程的继续，又是下一个产品版本开发周期的开始。

 

软件维护不只是维护系统的运行。更重要的是，发现和解决软件产品的缺陷，找到改进产品的新思路。绝对完美的程序并不存在，对任何设计或任何代码，总能找到改进的方法。软件开发必将是一个长期的、反复的过程。产品被使用的经历对产品的改进至关重要，许多时候，只有一个产品真正被使用了，我们才知道本来我们要创造的什么东西。这也是原型化方法被提出和流行的原因。

 

如果一个产品，很长时间没有变化，经常不是因为这个产品太完美了，没有需要改进的地方；而是因为太滥被丢弃了，或者这个产品太专用，不能添加新的功能或用于新的环境下。

 

工程人员在软件维护中担任重要的角色。工程人员在软件维护过程中的作为，实际上是对软件开发过程的参与。软件开发过程是一个长期的过程，在这个过程中，工程人员和开发人员有相同的目标，就是生产高质量地软件产品。当前，我们特别强调，工程人员在工程实施、项目验收中责任。却忽略了工程人员，在整个软件开发过程中的角色。

 

工程人员也是开发人员。

 

在部门里面，经常出现这样的局面：工程人员打来电话说：“我们明天都要验收了，怎么这个模块转不起来了！”。大家好像都有这种体会：越到关键时刻，越出问题，其实这是因为，我们只在关键时刻到来之前，才认真的去使用软件，才认真的去发现问题。经常是，研发那边发布了程序，工程人员就装一下，一看运行了就可以了，直到“关键时刻”到来之前，才会再想起来去看看。有的时候，甚至在初验的前一天，才去安装一个新的模块。出现问题后，就开始抱怨开发人员的质量。我要说：最终的软件，应该是工程人员和开发人员共同的产品，工程人员尽早地，准确地报告产品的问题，就是对最终产品质量的促进。

 

下面是对工程人员地一些建议。

1.认真学习开发发布地产品。阅读文档，参加部门组织地培训。许多优秀的工程人员，对整个系统地了解比开发人员都全面（不必深入但要全名）。不要一副架势：“我不知道你们是怎么回事，反正是没有数据，你要给我解决。”而是使用所知知识，积极的协助解决问题。

 

2.工程人员不止要报告产品的问题，还要报告产品改进的建议。使用的经历难道没有激发你对产品改进的创意？既便是报告问题，也不是简单地想开发人员要一份解决办法，想一下是否可以通过产品改进，今后不必再面对这个问题。

 

3.软件问题的报告，BUG的发现和处理，是一个很不精确的过程，经常被偶然性误导，浪费大量的时间。特别是，部门的条件有限，不能模拟各个项目现场复杂的环境。这种情况下，解决问题的第一步，就是设法重现这个问题，找到问题重现的规律。这个规律，对开发人员的指导意义那是相当的大。并且，如果你不能重现问题，你如何确定，开发人员真的把这个问题给解决了。

 

4.在初验到来的时期内，反复的使用软件，尝试不同的配置选项。以全名测试的策略，让程序的问题尽早的出现。现在有一种态度：“现在系统运行的好好得，可不敢乱动了。”结果到验收得时刻到了，你不得不动得时候，问题就出现了。

 

5.问题出现后，不要忙着责备。许多现场习惯使用这种对开发人员得责备来缓解工作得压力。无论谁得责任，这是你要免对得问题――也许，有一点让你放心，你不是独自面对。