老系统维护

源地址：https://www.cnblogs.com/ahl5esoft/archive/2011/08/17/2142739.html

今天收到了老板给的一篇关于老系统维护的文章，本人读后有了，了解了很多，也清理了本人诸多的模糊想法，现将此文章分享给各位，原文如下：

我之所以把这个主题放在过程管理篇的第一部分，就是因为很多程序员每天干的工作，不是在开发新系统，而是在维护老系统。这个理儿大家都清楚，世界上哪有那么多新项目新产品开发啊。一个公司，也就是那么2~3个产品，也不可能老有新的产品出现。那么多程序员，只能做维护的事情了，不断让软件升级，而这个软件是谁写的第一版代码，都无从查起了。一翻开源代码，会看见各个时期各种风格的源代码，甚至很多源代码都没有注释，根本不知道某些代码干嘛要那样写，到底是为了什么目的。

 

一天早上，有个网友给我发了一条消息：他是一个老产品版本维护开发人员。他应聘到这家公司的时候，这个产品已经卖了4年了。最初的开发者已经都在这4年中不断流失走掉了。他来了，任务就是维护这套软件，而且就他一个人维护这套台面，有BUG改BUG，有需求改需求。

 

虽说这套软件卖了4年，但真不知道是怎么坚持了4年。他接手的时候仍然是BUG百出。代码没有文档，没有注释，连表结构说明都没有。代码莫名其妙，经常横插一句代码。显然是客户报告了某个错误，为了临时决定这个错误而做的针对性处理，但到底是为了修补什么错误，代码也没有说明。所以他不敢乱动，但还要需求，只能硬着头皮来。他也不知道自己修改的代码是否还会引起其他的问题，只能凭空企求千万不要出问题。老板还在到处吹产品很成熟，而他每天都在心惊胆战，害怕这套代码不知道哪天突然崩溃，出了错误自己都收拾不了，那只能自己被K掉。他能想象得出老板发怒的情景：这么稳定的产品你都搞不定？！

 

   他希望我能帮他出出点子。

 

   我想了想，能有机会开发新产品或新项目的程序员是很幸运的，因为没有历史包袱，白纸画画。而现在大部分的软件公司都是拿一套已经有了型的代码到处修改，客户化为新项目。真正做一个新项目，从头编写这个项目的第一行代码，这样的机会比较少。

 

   对于修改现有代理适应新客户新项目，这种情况非常多，也是大部分没有文档，修改定制没有注释。客户打电话说一个需求，技术能达到就答应下来修改，修改完就给客户覆盖，根本没有需求管理、版本管理。而这样的代码，还不是一个特定客户一套特定定制化代码，是要给其他客户也更新的。很可能这个客户好使，那个客户使用其他功能的时候就出错。按下葫芦起了瓢，是很常见的现象。

 

   我问他：“现在你改的代码有注释吗？”

   他回答：“没有，自己修改的自己都记得，即使忘了，看看自己写的代码也能回忆起来，所以也没有写。”

   我问他：“那以后你走了，其他人怎么办？”

   他回答：“反正也是一个烂产品，其他人怎么办，他就管不了了，就应该让这套烂代码尽快死亡，省的祸害别人。”

   我问他：“那你找我帮助的目的是什么？”

   他回答：“在我工作的这段期间内，它不要崩溃就可以了。”

   我无语了。

 

 

   关于老系统维护这个话题，我喝许多开发人员都有过深入的交流探讨。

 

   许多从事开发的网友认为，一个老系统要维护好，必须具备以下关键因素：有责任心，有文档，设计前做好详细的需求分析，要有需求管理，要OO编程，要有专门的测试人员。如果没有这些，干脆推到重来，如果不让推到重来，那就赶快跑路，否则就容易当了冤枉替死鬼。

 

   但现实中，往往维护老系统的就一个人。这是很矛盾的事情。一个软件的开发，往往1~2个月就完成，而它的销售、实施、升级周期却长达4~8年。但每个老板好像都认为软件已经开发完毕，修补修补都是小功能，所以一个老系统维护人员就OK了。殊不知白纸好画画，而要在别人的画儿上再能点睛成龙就是难上加难了。

 

我在管理运营企业的时候，发现遇到的难题也和维护老系统面临的很类似。都是缺这缺那，部门之间利益冲突，人的素质怎么也提不上来，员工和老板互相做猫和老鼠的游戏，不断博弈薪水和付出劳动力平衡。总有些公司的历史---留下的人留下的势力格局留下的客户印象留下的做事方法不能改变，也无法推翻重来，但公司还要发展还要提高，就必须已目标为中心，不断像骆驼一样挺着风沙干渴饥饿领队前进，有各种困难阻碍都要不断清除，无法根除就想办法平衡与缓解，时而让步时而迂回时而强势时而突然决策突然执行，公司就这样不断持续经营下去。

 

所以，维护老系统，也要想经营企业一样，不断继承包袱，不断细心剖析问题，剥茧抽丝理清思路，不断改进，不断渐渐从恶性循环走向良性循环，才能把一套烂代码扭转成可持续维护的代码。

 

 

 

                                                     写代码的8项建议

 

 

1、 重点把控输入数据的校验。  你看见很多横插进来的代码，就是由输入的漏洞进入，最后引起后续数据处理出错，所以以前的程序员不截源头，在最后爆发的地方堵漏洞。现在Windows程序都是消息事件触发式的，还说不准这个流程会走到哪里，他堵的了这个口，其余他根本想不到的触发，能堵住吗？所以，把控输入数据的校验，在保存按钮第一步代码中写好集中的详细校验。而且，这块代码要写成函数，不要大流水，省得代码复杂性会让程序加速崩溃。

 

2、 以后的需求再往上加，都写成函数。   遇到比较大的IF..else判断，就从其中的代码段再分出一个函数。

 

 

3、 以后再加功能，尽量不要做成联动触发的。 也就是说，保存，最好是单表保存。即使是主从结构的单据，如果客户不强烈反对，也先保存主表后再让录入明细表。而且录入明细表要单独的窗口，这样功能和代码都简化了。如查询一张单据，也不要上边是主摘要，下面就是明细联动。这样会影响性能。更因为速度可能慢，用户会连续点击多次，触发事件就会乱，莫名其妙错误就都产生了。最好是双击主摘要，弹出独立的窗口显示明细。

 

4、 以后写代码，分离特殊处理业务和正常处理业务的功能代码。  就好像你走路，老有人给你下绊子，你就感觉不爽。

 

 

5、 对不常用的功能做一些隐藏处理，将其放到一个不起眼的位置。  使用的人就会越来越少。到时候就适机真正隐藏掉，不让它触发了。

 

6、 写代码时，避免全局变量和大流水代码。  其实很多时候，你觉得程序很烂，索性破罐子破摔，是由于以前程序员的代码排版可能和你不一样。你喜欢两个空格，人家喜欢三个空格，你就觉得不爽。人家喜欢把{放在最后，你喜欢新开一行。你可以使用代码格式转化工具重新排一次版。我看到很多老代码维护人员，抱怨变量都是M、N、S、Button1之类，但其实你阅读理解代码，这些并不会使你理解有歧义或不懂，只不过你不爽而已。理解了这个不爽，你就会心平气和一些，修改代码会更加顺利一些，你越和旧代码生气，你的工作越乱。看到这里，相信很多程序员都会会心一笑。真正的根源在此，老系统无法维护只是借口而已，可能是希望老板认为自己的工作很辛苦很复杂而加薪！真正危害大的是全局变量和大流水代码。所以写代码，要严格避免这两个坏因素。

 

 

7、 修改需求或BUG的时候，要按照模块来源集中修改，而不要挑好改的先改了，不好改的就最后改。  按照模块来集中修改，你会通盘考虑所有这些需求和BUG，而不是糊窗户式的补漏洞。

 

8、 多写视图，多写存储过程。  我曾今和很多做维护的开发人员都做过交流。他们都觉得一个软件没有文档，没有注释，简直就没法维护。但确实是很多软件没有任何设计文档，连帮助说明都没有，代码也没有注释。而这些软件又出自他们自己之手。也就是说，他们一边抱怨没有文档没有注释，一边自己也不做文档不写代码注释，不知道在等谁来专门做。我问他们到底需要什么文档才可以将一个软件维护得越来越好，从一套烂代码扭转到一套良好渐进的代码？他们说要表结构说明，要详细功能设计书。表结构还好说，可以整理出来，详细设计说明书就不容易出了。

 

     我曾今也维护过别人的代码，也是什么文档都没有，连操作使用帮助都没有，更别提详细设计说明书和表结构，代码当然没有什么注释。我并没有去整理表结构说明。幸亏这个人喜欢在数据库上倒弄，写了大量的视图和存储过程。视图中有各个表之间的关系连接，也有各个表中重要字段的中文含义。这样我就不需要表结构说明了。因为表结构说明不仅需要描述每个表中字段的中文含义，也得描述表之间的关系，这和视图能表达的效果是一样的。所以，我现在也建议开发人员写代码，多写视图，多写存储过程。有的老代码，SQL语句都在代码中执行，没有视图。对于这样的老系统维护，就是把这些SQL COPY 出来，做成视图，这样就好维护了。

 

     至于详细功能设计书，其实对于程序员来说，其目的是想弄清楚业务流程的来龙去脉细节。光直接看代码很难弄明白意思的，又没有什么其他文档可以参考，所以只能猜测代码的意思。尤其很多维护人员，很多功能细节都是为了处理某些特殊需求和异常业务的，都是以前程序员写的，但是以前的程序员已经走了，现有的维护人员连软件中具体的细节功能是怎么回事，程序员都发蒙，嗯，还有这个功能？我也不知道呀。

 

要解决这个问题，我曾今做过的事情就是组织实施人员写功能操作说明帮助。因为实施人员要给客户去培训讲解，没有帮助说明，只能一张嘴“叭叭叭”地干说，实施人员是最需要功能操作说明帮助的。但是实施人员认为这个帮助是软件的一部分，而且是开发部开发的软件，开发部最了解功能，所以帮助文档应该开发部写。而开发部认为开发部的职责就是编写代码，你自己培训连个操纵说明都没有，你怎么培训，所以帮助文档应该实施部门自己编写。于是帮助文档谁也不写。

 

归根到底，帮助说明是终究要写的，主要是谁写的问题。谁最有动力写呢？实施人员最有动力，因为这和他们的工作息息相关，而程序员明显没有动力理由。而且实施人员熟悉第一线客户的素质，理解客户的具体操作思路和理解思路，写出来的帮助客户都能理解，帮助文件才能真正为客户服务。很多帮助文档的写作都是由从来没有见过客户没有实施培训过没有给客户支持服务过，连软件测试都没有做过的纯粹文档人员编写的，可想而知帮助文档到底能对客户有多大的帮助性。

 

在写帮助说明的时候，我要求实施人员把每个按钮都要点到，每个GRID中的每一个字段数据来源和数据含义，每一张报表中的字段的数据来源和数据含义，每一个明细录入中的字段数据来源、数据录入要求和数据含义都要说明到。这一写不要紧，发现了很多隐藏的特殊处理功能。很多功能很多人不了解，因为很多细节功能，都是为摸个客户定制的，只有负责实施改客户的实施人员才知道。于是，实施人员之间互相通气，才算补足了不少功能细节的帮助说明。实在有写功能，都不知道是哪家客户提出来的需求，也不知道为什么要这样处理，就留下空白，转给开发人员，让开发人员看看代码是怎么处理的。就这样，一份详细的帮助说明在压力艰难中终于出来了。从此，开发人员理解需求快了许多，当然也就明白了那些在过去自认为乱七八糟的代码的含义，心情好了很多，修改代码也轻松了许多。

 

 原来，一切都是自己跟自己跟自己作怪。不盼望软件工程，不抱怨一穷二白，不幻想加人手，从现实入手解决自己的问题，发现很多解决方案既简单又有效，根本无需动辄就是团队就是UML就是OO。

 

另外，需求也是维护人员很头疼的事情。我的手下也经常问我：客户必须让咱们接他们的需求改，您看怎么办？

 

 

                                          客户需求！客户需求！

 

 

客户需求，这个让开发部最头疼的字眼！每当想起客户需求，就想起了一下这些话：

1、 程序员说：这是你们家个性的需求，太邪门，我们不做。客户说：不做我们找你们老板去，我们是花钱买了你们的产品的。

2、 客户说：我们不会用鼠标，你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通，你们给我们做一个吧。程序员：我晕！

3、 程序员说：等你们内部斗争完，你们协调完了，我再调研需求。

 

似乎，我们在需求上无能为力，我们永远在追赶客户的需求，满足他们的现状，把N多家的客户需求都加进软件中，只要能实现的，我们尽量咬牙实现了。

最后，我们发现，我们的软件无比复杂，谁也不会用了，连开发部门都不会用了，谁也不知道这个需求当时为什么要这样做。因为无比复杂，所以实施、培训、技术支持都成了问题，稳定性更成了问题。代码互相交叉，根本无法理清有多少交叉影响点。维护的程序员都快崩溃了，天天在祈求，千万别接到客户电话，千万别接到客户电话！

 

      一个业务处理，可以这样处理，也可以那样处理。你的软件采用了你的处理方法，客户采用了客户自己的处理方法。两种方法平分秋色，没有优劣。但客户用惯了自己的方法，所以必须让软件改成客户自己的方法。

 

      不改吧，没有理由，因为两种方案都差不多，单客户就是客户，客户占上风，否则就不验收不给尾款。改吧，又有什么意义？这家客户习惯了这种方法，下一家客户又不适应这家客户的方法怎么办？未必到一家改一家？

 

   我们也曾经动用了这样的技巧：

1、 客户业务部门不能随便提需求，必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司。

2、 客户IT部门的需求，必须由客户方负责IT项目的老板签字才能生效，才能报给软件公司。

3、 不能随时报，每3个月集中报一次。

4、 不能口头报（即使在现场实施支持也不行），不能电话报，只能EMAIL或传真来报。

5、 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。

6、 软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。

 

经过这么几招，客户也疲了。需求是不提了，开发部欢呼雀跃。但我们真的做好了么？难道客户真的满意了么？并没有。我们只是限制 了客户的需求！本来，是因为客户有需求，才找我们来开发软件。我们现在拿了人家的钱后，又嫌人家的需求多。

 

   需求，有很多方面。有关于功能的（尤其是每家客户特殊的业务需求），有关于异常错误的，有关于性能的，有关于兼容性的，有关于易用性的，有关于特殊权限的，有关于美观性的。

 

    而有需求的来源也是多方面的，有的是客户计算机室直接打电话，有的是客户业务部门直接打电话，有的是实施人员，有的是支持人员，有的是市场人员，有的是销售人员，有的是老板和客户打单或开会突然想到谈到就直接给开发人员打电话。

 

    而需求的优先级也不一样。有的客户态度强硬，你必须尽快满足他，否则他就给你老板打电话。

 

    而正是这来自四面八方的各种层次各种看法的人的各个方面的需求电话，把程序员烦的要命，还要去开发。而且很多时候客户都是以为一个电话程序员就能开发了。但往往程序员开发完后，客户一看不是自己最想要的，于是再修改。很多人抱怨说需求老变来变去。其实，不是客户需求在变，而是你对客户的需求理解在不断加深。

 

   所以，需求多，其实是一个幻觉。那该怎么办呢？我给出了这么几个注、主意。

1、 把需求分类，做个EXCEL表格，量化解决。  这个需求管理表格会有下列这些项：客户名称，需求提出人，提出日期，需求关闭时间，功能模块命名，客户现在版本号，需求描述，需求分类（需求，BUG）。我在最初没有需求管理系统的时候就使用过这种方法。过去没有使用的时候，我得手下老叫忙死了。我就让他把现在手头的事情整理一下给我报个邮件。但一整理，肯定不超过10件事。有些事情是等待客户给资料，有些事情是调试跟踪不出来错误，有些事情是需求模棱两可。我给他一分析，他现在正在进行的事情就两件，而且都是他自己能独立做的，根本不需要别人配合参与。他忙吗？他瞎忙，或者故意说 忙。没有工作效果就是这样。帐不算不清，话不说不明，就是这个道理。

 

      有了这个表格，要定期（可能是一周，可能是一月）给老板一份。这表明你的工作量，让他看看你确实一直很辛苦的在工作，而且干了这么多活。而且，这也能看出你工作的仔细负责态度。

 

     曾经有个客户，光想占便宜，但不想每年掏维护费，软件也不验收，每次去催验收，总给我们提出一大堆需求，说你们这个系统烂得不得了，还想让我们验收？你们必须把我们的这些需求满足了，咱们再看能不能验收。我们忍了，拿着需求低调修改，但如此反复了好几回仍然没有验收的意思，我们到了他们现场，发现那些他们声称不满意的功能他们还在继续用，这就奇怪了，难道他们故意装做不满意是为了不想给钱？我们就把过去所提的需求都翻了出来让他们看：什么时候提的，谁提的，提了多少条，我们是怎么满足的，你们又是怎么把需求变更的，我们又是怎么安排修改的。整个过程一清二楚，我们的工作量都摆在这里了。客户还在狡辩说我们从没提过这些啊，我们都不知道，我们怎么会提这么多呢？我们说这些需求都有你们的人名和时间的具体记录，那还有假。最后，客户也脸上挂不住了，好歹做了验收。

 

    有些程序员不做这个表格，也不给老板报告。很多时候是程序员并没有干那么多活，能推则推，能混则混，能拖就拖。怕自己有一天混不下去，所以心理压力很大，每天不干活却总觉得很累。这种累就是自找的。想必一些程序员看到此会想起自己。

 

2、 2、需求描述不清晰。需求描述不清晰是反复修改的罪魁祸首。对于BUG，要有错误报错整个的屏幕截图，千万不要就截那个错误消息框那么一小块。对于需求，是报表需求，要给出表格格式，还有每一项数据的来源，有公式关系的要给出明确的计算公式。对于输入单据需求，要给出单据格式，每一个输入项的要求：可选值、默认值、不可为空、唯一性、约束输入，数字要有小数点后精确度、日期要分辨精度是到日期还是时还是到分。

 

 

还有网友跟我求救，他跟我说了一种情况，说现在的需求压力，不仅仅是来源于客户，就连我们的实施部门也给我们提需求。老板说我们一天到晚坐在家里编程序，根本不了解客户需求。最了解客户的是每天和客户待在一起的实施人员，所以要让实施人员来给我们的软件提需求加功能。但是，实施人员那叫什么需求啊，比如说XXX功能不好用，比如说建议更易用一些。老板不相信我们，怕我们把实施人员改得需求给屏蔽了，专门派了一个人每天收集各个渠道来的需求，每天还要上报给老板，而且还每天想老板要报告，今天修改了多少需求，还有多少需求没有改，没有改得需求什么时候能改完，都要我们开发部给答复。而且，隔几个月，老板就把全公司人员都召集在一起，为软件提需求。一群人坐在一个会议室，每个人都可以提，一个模块一个模块的提。当场打开软件功能，演示，说明，阐述软件应该做成什么样。我们开发人员就跟开批斗会一样，这个标题不要这样叫，那个对齐不对，这里不够明显应该加粗体字或给一段红色的提示。唉，活的真窝囊，天天修改这些乱七八糟的所谓需求，还要被人追着赶着问进度，还要忍受被所有人都骂开发的什么烂软件。老板也觉得我们水平不行，需求也怠工不修改，两天才改修改了3个需求。而且越修改需求越多，软件越不稳定。我们哪还敢提涨工资啊。

 

我说：你的这种情况很普遍。现在很多软件公司都是老板开店，三五个人十来条枪，他有客户关系，卖个软件做个实施赚点钱。公司也不大，如果软件做不好，实施做不好，多年积累的客户关系就坏掉，以后不好再销售了，这就等于把老板的命根断了。所以老板肯定会盯死软件开发和实施。客户使用效果好才能以后有更多的单子做。而且你们作为开发人员，又不接触客户，怎么能理解某个需求真正意图呢？当然老板的思维逻辑对，你们这样，怎么能理解客户需求呢？当然实施人员最了解，提的需求最有权威。换你做老板都会这么想。

 

我也经历过这段日子。人和人的信任，都是在做事中不断看人试人品人，才能取得信任，才能放权。我的老板也如此。

 

  如何比实施人员更了解客户需求？如何让老板相信我比实施人员更了解客户需求？这也是摆在我面前的一个问题。

 

    我是把产品放在一个产业中看。看竞争对手，看业界标杆，看业内管理专家，所以我对产品的升级完善，是基于产品战略的，是基于盈利模式和竞争力构建的。如何引出更多的盈利增值产品，如何保证产品更有竞争力，是我思考的重点。

 

 而实施人员提的需求，都和他实施的客户具体业务流程有关。客户就是这样，咱们的软件不能满足客户这样做，就要改。不改，客户就不满意，实施就推进不下去，实施项目就延期，自己的实施就不力。所以，实施人员为了保护自己的利益，也要开发部必须改。而且一开口就是你从来没有去过现场，你根本不了解客户。

 

    老板信谁？

 

 我不是业界知识管理专家，我也不是业界明星CTO。老板怎么能信我对业界产品竞争的判断呢？

 

    而实施人员，天天真实地和客户待在一起，他们反映的肯定是真实地。

 

第一回合，一开发部门老老实实修改需求为结束。

 

 后来，老板又亲自主导了几次实施人员需求会议，什么都可以提，都记下来，让开发人员改，让实施人员监督开发人员修改，确认修改的符合实施人员的要求，并且实施人员负责测试，每次大约都能记个上百条，从要求简化SQLSERVER数据库安装（因为实施顾问都非技术出身，没接触过SQLSERVER之类的产品，用的最多的是EXCEL和WORD,因此用报表设计器给报表格式挪挪位置大部分人都不会）到把界面都换成绿色背景（说符合公司形象）。这种局面直到我在各个部门各个环节各个层次应用了多种策略才改变。 

 

     过了一段时间，老板看着实施人员都没事情可干，很奇怪，就问为什么不测试软件？实施人员回答说：开发人员没有改多少需求，我们正在等待他们开发呢。

 

     然后老板就找我：“为什么不修改？”

 

     我说：“程序员一直在修改，但另一方面，我们已经修改了多次，满足需求300多条，但是我们的产品竞争力增强了么？我们的特点在哪里？我们的亮点在哪里？我们的竞争力在哪里？”

 

     老板说：“不管怎么说，这是客户的需求，客户买了我们的产品，我们就有义务为他们满足需求。”

 

      我说：“看这条需求，客户要求在我们的管理软件中做一套视频会议。”

 

      老板说：“那你找找网上有没有免费开源的”

 

      我不再争辩。因为我知道，在他心中，做什么产品，叫什么企业管理软件都无所谓，客户需要在ERP中加入游戏，如果理由充分也是可以的，重要的是客户不能得罪。客户关系是他的生存之本，而非产品。

 

      我开始在网上写对行业的观点，因此也有幸结交了许多知名的行业内管理专家。他们称赞我的观点独到，思考有远见。文章也受到不少网友的追捧。

 

      我会把我写的一些文章的链接适机转给老板，转给喜欢思考提升的实施顾问。我也会经常把和我思想观点相似的文章链接转发给老板。

 

     老板继续组织全体人员需求讨论大会，但这次他有了改变。虽然仍然是让人统计未完成需求数，老追问什么时候才能完成，但显然他不像过去那样主导与控制整个过程了。他说：你也要跑跑客户，不能老待在家里。

 

     于是，我跟着实施顾问也跑了一些客户，有时候，还带上主力开发一起走访。

 

过去，开发和实施冲突很大。开发觉得没必要修改，实施觉得必须改，最后实在不行就拿出老板来压。而且，客户有自己特殊的业务需求，有能人者还自己想解决方法。而实施人员呢，在现场实施，陷于此境此客户，也觉得客户的解决方法有道理。于是非要开发人员按照那样的方法修改。但开发人员知道，按照那样的修改软件，那软件就死住了，这个功能只能给这家客户用了，其他客户没法用。于是开发人员骂实施人员胳膊肘往外拐，站在客户那方对付自己公司的同事。

 

但是一走访，开发人员也才认识到客户原来面临这样的问题，客户那样提需求其实是为了解决这样的问题。但很可惜，客户的想法太局限，只为自己这个问题想解决方法。如果开发人员当时在现场，就能明白客户面临的问题根源，只看表面问题现象，还自以为是提最佳解决方法，还让开发部实现。应该是，你提出你的需求问题，怎么解决是我们开发部自己的事，我们会综合考虑平衡。

 

我走访客户，主要目的有三：

 

1、 改善一下老板和实施人员对开发部的认知。 他们都认为开发部只是一群不懂客户需求，整天坐在电脑面前不用出差，说话神叨胡子拉碴的敲代码者，“你们不懂需求”，让这个理由一边儿去。

2、 改善一下开发人员和实施人员的冲突。 让开发人员也理解客户的现状。有些事情是不可改变的，有些事情是人为故意的，我们做为开发人员，不应该把软件假设在一个理想的工作环境下，那样的软件是不适合现实使用的。改委曲求全还得委曲求全，骂客户管理水平太次、骂客户都是白痴 。我在开发团队内部老是说：人家是白痴吗？ 人家买你的软件也是白痴。那岂不是反过来说你的软件谁买谁就是白痴？那岂不是说明你的软件很烂毫无价值么？咱们每个月的工资从哪里来？是老板发给咱们的吗？老板又不是白痴，发钱给咱们？老板的钱也是从客户口袋里掏来的。

3、 了解客户现状，想方法如何去引导与影响客户。 客户面临最需要解决的问题是什么？客户对软件的认知程度如何？客户怎么看软件价值？客户认为这套软件应该是干什么的？（有的客户认为我们的软件应该带上QQ）。实施人员是怎么给客户讲解软件中得管理思想的？实施人员是如何培训客户的？

 

   走访回来之后，我做了两件事情：

1、 发表了一篇我的走访感受。发到网上，也发给老板，发给实施人员。老板看了以后说了一句话：“看来走访走访很有必要，以后要多做。”老板、实施、开发，三者之间的关系改善了许多。

2、 把走访过程中确实应该改进的需求安排给开发人员。由于开发人员也是有切身体会，很快就改了出来。实施人员说这个功能做得不错，很实用。

 

第二回合，开发VS实施，平手。

 

然后，我又把业界知名专家的一篇文章中提到的评价模型内嵌到软件中。过去，我们虽然在产品PPT中老是宣称自己的管理思想先进，但在软件中却很难看到落实。所以，实施人员在实施过程中只能讲操作。而操作，客户觉得还不如一个EXCEL表好输入好修改好查询好统计，所以客户希望软件修改成这样修改成那样。反正，客户现有系统解决不了的问题就都提出来。而现在，终于有了一个可以讲可以量化的管理模型。这套评价模型成了这个软件的核心亮点。 客户为了应用这套评价模型，也乐意录入数据，维护数据。

 

  第三回合，开发胜出。

 

  然后我提出了需求管理系统，WEB型。不管谁在外面实施，或者是老板突然提出，或者是销售提出，都录入到需求管理系统中。把需求分类，分优先级，量化安排开发计划，有的放矢吸收需求，改进软件。

 

  我还提出，每年召开用户需求会议。邀请有思路有积极改进想法的客户参会。大家面对面交流共同的问题。共同的需求，共同探讨未来行业机遇挑战，共同寻找解决方法。引导客户，引领老板和实施人员提高对产品，对业界，对未来，对竞争的认知。

 

       现在在我得影响下，公司的IT咨询业务、IT教育业务、IT服务业务、IT整合业务、IT产品发展战略。集成合作伙伴，都逐渐专业发展起来，给公司提供了越来越多的盈利模式与收入渠道。

 

       对于这位网友的现状，我还建议他开始版本管理。

 

       CVS、VSS之类就不必了。因为这是一个人的战斗。连版本都没有概念，一上来就是特正规的工具，大半感觉太麻烦，又退回到最初原始状态，还对版本管理产生了不好的印象，觉得繁琐还没什么用。所以我们有一句话：一管就死，一放就乱。其原因就是缺乏一个 中间过渡解决方法。

 

       所以，我建议先把版本意识提上来，按照版本管理的方法走，走顺了就自然接受了正规的版本管理工具。版本管理工具可以分支，也可以合并，可以针对Bug进行补丁发布，而不发布还未完成的新功能，可以发布为某个客户专门定制的版本，也可以回溯历史版本，对比历史差异，源代码安全性也高。

 

                                              有几个过渡性建议特别实用：

 

    1、有大的修改或没有把握的修改之前，先把代码备份到其他的机器上。备份目录要跟上日期。

    2、在大的修改前，先定一个稳定的版本发布出去。很多程序员没有版本这一概念，每天都在持续修改。结果，给客户的，每个都是半成品，有半拉子没有修改完，还自己没有做屏蔽处理。客户不小心用了，产生了错误，再告知千万不能用这个功能，还没有完善。但晚了，错误数据进入了，以后报表平帐就是问题了，又得特殊数据特殊处理了。自己的孽障自己还得解决。

    3、即使是琐碎的修改，也要每天或隔天备份一份源代码，别怕代码多，现在的硬盘大的很，而且备份复制一下也就是5分钟的事情。别怕每天备份太烦。我们经常会遇到这个客户让改了，另外客户不让改。一个功能改了又改回去，但过去的源代码没存备份，忘了怎么写了，这时候你就想起代码备份的好处了。尤其现在有不少免费的文件同步或文件自动备份的软件，都能定时做。功能还强大，有些还有些差异备份的功能

    4、现在有不少文本对比软件，如WinMerge之类。可以对比两个文件的差异，这个功能和版本管理工具中的源代码差异对比一样的效果。

    5、如果每次发布新版本，就把从上一版本发布之日之后的关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。这样即使没有人写更新说明文档，根据追溯也能明白这次版本解决了哪些问题和需求。很多程序员没有需求管理表格，版本发布要求写更新说明文档，这才从脑海记忆中想，想的就有些遗漏，甚至错误。好多程序员有过这些的情景：我记得改了呀。真正一翻代码，一点没动。大叫：我的代码怎么没了，我记得我改了呀。

 

    我这些建议，从需求描述、工作量管理、遗留系统代码重构技巧、备份管理、版本管理、更新说明文档一整套说明了一个人如何维护老系统的工作方法，但希望能分享给大家，给大家以帮助。

 

    有方法，你就不是一个人在战斗。

 

    一切皆有可能。