维护型项目之殇

维护型项目之殇

 

我在刚做一个功能的时候，发现有必要对原来功能进行大面积的抽象和重构，牵扯N个代码单元和大量的业务，复杂的要死要活，于是我又纠结了。刚刚同事还说，开发新Issue时又偶然发现系统的其他几个小缺陷，于是又占用时间改掉（这个当然不算做预算和工期里面，只能自己挤）。

于是我觉得有必要总结整理一下这些烦恼，好叫大家知道这一群默默贡献的人。

Q：维护要花多少钱？

好多领导都觉得维护型项目占用了大量的资源，成效还不是特别突出，于是对维护型项目往往存在着不同程度的看法。我想既然花“一块钱”做了这样一个系统，就要有花“十块钱”维护下去的觉悟。

新系统发布上线，只是万里长征的第一步，后面有着更长的路要走。就算按照软件工程的理论，产品发布之后的运行维护也占用了最大份额的比重。

维护花好多钱，大家郁闷也正常。新产品上线从无到有，显而易见，花点钱心里也舒坦些；维护项目不断的修复和完善系统从有到优，不容易察觉，这个花钱就会多少有点心疼。

Q：维护项目效率有多低？

前人栽树，后人乘凉；前人挖坑呢？新系统上线时，阶段的局限性，对业务的适应、代码的结构等存在着大量的问题，这就是一个个“坑”，是由后面的维护项目组来填的。新系统开始时，可以N个时间开发N个功能，留下N/2个坑，效率N/N=1；系统维护开发N个功能，往往还要解决至少N/2个坑，效率N/（1+N/2）<=2/3。

大家都知道“行百里者半九十”的道理，开始时的冲刺给人很震撼，谁又知道最后一段距离还有谁在艰难的前行？将一个系统维护好，比重新开发一个系统要难的多。

Q：开发和测试的水平有多菜？

新系统开发时，一片空白，团队人比较集中，各个角色也介入的相对较早，在干净的文档上，从头开始开发和测试，干净利索。

系统维护增加功能时，要全面的了解原来的功能和业务，开发要兼容代码，测试也要注意有没有漏掉关联的功能。团队再分散一些，人员流动大一点，业务知识得不到积累，开发和测试的质量更难保证。

维护项目组开发和测试都在巨大的压力和复杂性的前提下辛苦工作，水平真的好菜啊！

Q：维护项目的成绩在哪里？

对于新开发一个系统而言，系统做出来就是成绩。对于维护项目来说，系统不断的变得更稳定更好用，却常常被认为是本分。殊不知这两者都是工作本分，只是内容不同而已。对于维护型项目，往往只有突破性的改进才被认可，在技术推动业务有了较大突破才容易被感知。

Q：维护项目组人员的出路在哪里？

他们大多是复合型人才。他们大多精通业务，擅长用合适的技术解决业务问题，用技术推送业务的提升和管理的提升，而不是用技术解决技术问题。他们是真正用技术创造价值的人，他们没有太多的时间单纯就技术谈技术，追求技术的潮流和高精尖。对他们来说适合的就是最好的。他们是真正的实战型人才，他们的技术都经过业务的磨砺，一招一式都精雕细刻。

比之那些跟新项目的技术人员，或者单纯搞架构和组件的人，他们的技术不够高精尖；比之一线的业务人员，他们的业务不够纯熟。他们似乎是被遗忘的人，在一个容易忽视的角落，但是却发挥着技术和业务的纽带，做着最大的贡献，创造着最大的价值，真正发挥着技术的光芒。