今天和大家聊一个职业生涯中接手的软件项目维护工作，在其中发现的问题，以及问题的前因后果。

这个项目是一个学生报名管理系统，录入学员信息、报名信息，以及其他相关信息，然后再生成一些财务统计报表和学员信息报表，本身的结构和逻辑并不是特别复杂。

发现的问题是——数据结构设计错误，进而导致项目不能正常实现功能、难以维护、无法升级，最终导致软件变成了一个残缺的产品，最终下线停用。

下面我具体描述一下问题。现实中大家都知道，当前中国家长普遍有给子女报补习班的情况，而且一般有多次报班的记录，比如小明的父母给小明报了一个数学补习班，可能过了一段时间以后，又报了英文和钢琴的补习班（这个软件项目的甲方有很多课程）。那么在实际使用此类软件系统的时候，一般的逻辑应该是先录入学员的信息，然后在这个学员信息的基础上进行报课操作。这就是简单的一对多的数据关系，一条学员信息对应多条报课信息。

但是这个项目的开发人员设计成了每次报名直接录入学员信息加课程信息，没有结构上的区分。

而且为了方便，学员的联系方式一栏填写格式是自由填写。

后果一：在后期的使用中校方查找、维护学员信息十分不便，比如想改动学员的联系方式，就需要查询出所有学员的报名记录，逐条修改，而且只能根据姓名查询，然后根据联系方式判断，因为联系方式录入混乱无法通过它来查询学员信息。

后果二：报表功能无效，比如校方想统计报名两次以上的学生数量，需要增加一个报名频次统计，然后做对应的营销策划。由于设计结构的原因，没有学员信息唯一性的依据，学员同名、联系方式录入混乱的情况很多。没有唯一性就没有办法针对唯一的学员信息统计频次。

后果三：维护升级难以进行，因为数据结构的原因，后期使用中多处不便，甲方和我们维护方都想对系统做升级处理，但是基础数据结构的问题，导致我们无法把唯一的学员信息抽取出来。最终项目无法在根源上做升级补救。

这个项目的最终结果大家可想而至。在梳理这个项目的开发管理的过程中，我们不难发现：程序人员缺少基本的数据结构概念，项目管理人员缺少需求分析和同类项目的了解。因为不管这两方哪一方是合格的，都能很大概率上避免这个重要的结构问题。这里我没有提到测试方，是因为中小型项目中，测试工作其实大部分是由设计师、程序员、项目经理、客服、客户分摊的，而在这样的测试人员构成里需要负起责任的还是程序员和项目经理。

总结这个案子，希望行业内能保留更多的有经验的技术和项目管理人才，让他们更关注项目品质而不是产出，对行业现状和企业产品品质的提升都有好处。而作为甲方更多的要关注到具体的项目参与者的资质经验，程序员要有一定的项目经验或者后备支持，项目经理最好有技术背景，这样对项目的成功就会有一定的保证。