学历教务系统项目管理经验之谈

       从事远程学历教育的教学教务管理平台的开发、管理多年，一直想把遇到的挫折和感悟和同行分享，于是集中几天时间整理出这篇文章，希望能对在这一行业奋斗的兄弟姐妹有所启发。文章中的一些观点也许有所偏激，但却是我的心声，欢迎批评指正。由于整个教学教务平台内容十分庞杂，本文涉及到的内容主要是教务管理方面。

       在国内学历教育教务管理平台是非常有特色的，由于此行业对政策相当敏感，教育部一纸政令就可能使平台发生翻天覆地的变化，而平台的主要用户——学校，迫于招生压力，会在政策允许或者没有禁止的地方绞尽脑汁，想出种种奇招来扩大生源，留住学生，无形中也会对平台造成很大影响。大部分作教务管理平台的公司类型分成两种，一种是以产品为主，根据常规的教务管理流程设计出一套平台，此类平台大都包含了通用的教务管理流程，但不会涉及到过细的内容，因为细节意味着学校的个性化，既然是产品就不能有个性化。另一类是以服务为主，往往是和某个学校合作，为校方定制平台，这样就可以把学校的个性化最大化满足。两类平台各有利弊，前者优点是对于一个软件产品而言，扩展性、健壮性、移植性很好，这会让软件开发人员感觉很好，但对于学校，无法满足其个性化要求，换句话说无法让客户满意。后者优点是尽量满足客户个性化要求，客户的需求能够及时地实现，缺点是这套平台的扩展性、移植性非常差，而健壮性也会受到很大影响，原因很简单，尽量满足客户需求就意味着要放弃一些软件工程本身应该严格遵守的约定。这对于开发人员来说是很郁闷的。实际上几乎所有的公司都在尝试在这两类平台之间取得一个平衡点，作产品的公司也会给客户定制化，做服务的公司也希望能整合多个服务平台，以便降低维护成本。然而这个平衡点的位置却是仁者见仁智者见智，个人认为要定位最佳平衡点需要项目管理者、开发、需求三方面一同努力。

 

管理者

此处并非特指项目经理，在国内很多公司，项目经理往往没有实权，当客户的要求与系统的稳定性出现冲突的时候，最终的结果往往是妥协。所以这里的管理者是指真正有权利控制项目的方向的，应该是项目总负责人。

1、   由于学历教务平台的业务复杂性，往往从平台诞生到最后成熟，会存在一个不断提升得过程，这个过程最初一般是在平台上打补丁，使之不断完善，但到了一定阶段，会遇到瓶颈，这种瓶颈产生的原因很多，最常见的原因是业务不断变化，造成需求不断变化，进而影响平台不断变化，最后发现原有的平台已经无法再继续打补丁了，或者说打补丁的代价过大，造成维护成本过高，这是就有必要重新设计一套基于未来可预见业务变化的新平台。这时管理者有可能犯的错误是找几个技术高手，封闭几个月，用最新的技术把新平台做出来。这种观点往往不是管理者自身产生的，而是由技术人员提出的。有可能产生以下几个问题：

l         这些技术高手是否熟悉原有平台，如果是，此问题不存在，否则，让完全不了解老平台的人来作新平台，无法使用以往的经验，会重复以往的错误。

l         新技术是否必需？其实不管是什么语言或者最新的什么架构，目的都是为了开发的方便，使开发的效率提高，功能增强，但对于用户来说，没有必要非要换新技术，因为对于教务管理系统，用户最关心的是业务逻辑而不是用户体验，即使对于客户有限的用户体验方面的要求而言，不论使用什么技术基本都可以实现，只是实现的方法不同，是否便捷的问题。而为了开发方便贸然使用新技术，会存在对于新技术了解不深造成工期拖延的风险。

l         管理者不懂技术，往往希望几个人一努力，就可以在短时间内做出一套全新的平台，并且可以屏蔽原有平台的弊端。殊不知，软件工程是一个非常系统的工程，从客户需求整理、需求分析、整体设计、技术预演、详细设计、编码、测试、部署，各个环节都必不可少，任何一个环节的失误都可能造成整个项目的失败。但管理者往往不重视需求、测试环节，他们更看重编码，所以往往要求技术团队在一段时间内封闭工作，认为这样就能把进度提前，其实在软件项目的整个生命周期中，编码只占很小一部分，大部分应该在前期的需求搜集、分析、整体设计还有测试，而这些环节几乎没有什么方法快速实现，所以封闭除了造成项目质量下降之外没有什么好处。

2、   客户要求和项目质量之间的取舍。

很多管理者都遇到过这样的情形，业务部门和技术部门掐架，业务说很早之前要的功能至今没有实现，技术部门说业务部门的需求不合情理，自相矛盾，会对整个系统造成不可预知的危害。这时管理者采取的态度可能是，将两个部门负责人找来，促膝长谈，业务负责人说这个功能很重要，可以大大提高工作效率，降低失误率，必须要，技术负责人说，此功能太危险，没有分析清楚它所造成的影响之前不能做。管理者可能会说，公司今年的利润指标还差不少，所有部门都在努力，业务部门是第一线人员，技术部门是后勤，保障必须跟上，如果你没有足够的理由说服我，就得做。此时技术部门只能委曲求全，最后的结果是功能实现，业务部门使用一段时间后，发现了种种问题，技术负责人当初预言的问题逐一出现了，但是第一步已经走出去了，只能硬着头皮继续往下走，系统继续打补丁，系统稳定性每况愈下。这里我们不能怪技术负责人没有坚持原则，也不能怪客户乱提需求，重要的是在于管理者，管理者不能以不懂技术为由，就对技术否决权持消极的态度，国内软件公司大都重业务轻技术，原因很简单，业务是利润的直接制造者，而技术只是服务于业务，即使违背了技术人员的意愿，平台还是照样运行，不稳定？没关系，有技术人员呢，他们就是干这个的。而业务的意见则要重视，因为他们是利润的直接制造者。这里不是在挑管理者的毛病，至少对于管理者而言，一言一行直接关系到项目的成败，没把事情弄懂之前不要凭感觉办事。

 

开发者

以下是几点忠告

1.对于临时需求能不加功能的尽量不加功能，做成功能就意味着要给用户使用，而用户不是技术人员，不会按照常规出牌。

2.如果没有足够的资源就别指望做一个大而全的平台，面对不规范的用户，这是自讨苦吃。还不如完善现有平台，去满足用户的需要。要更实际些。

3.不要迷信新技术，新技术不会减少多少工作量，最重要的是业务，恰当的使用现有技术，要更实际些。

4.面向对象的设计方式，要辩证的看，不是哪里都适用的。

5.对于一个频繁发生变化的系统，维护成本是非常重要的指标。

6.页面不要考虑太多的重用，否则过多的逻辑会使维护成本太大。

7.适当使用开闭原则。

8.不要太乐观，几乎所有的项目都因不可预知原因而延期。

9.数据库上尽量少用外键关联，否则就是在底层把业务紧密地藕合在一起了，而要尽量采用业务层控制，这样灵活性更好，当然它的缺陷是无法保证数据完整性，但对于灵活的需求，只能如此。

10. 任务计划不能仅以客户要求时间远近来排优先级，因为远的任务，可能工作量很大，反倒是紧急的任务。

11.严格执行代码版本管理，在频繁发生变动的系统中尤为重要。

12.人不是越多越好，沟通不畅造成的麻烦往往比缺少人力资源的后果更麻烦。

 

需求分析

这个岗位要做好很难，他同时要具备丰富的业务知识与娴熟的沟通技巧。他对于整个项目至关重要，首先他要面对客户，挖掘需求，而不是简单的传达，然后系统分析业务，避免造成拆东墙补西墙的结果，再者还要和开发者沟通，将业务传达出去，任何一个环节出现纰漏都会造成恶果。

需求常犯的错误：

1、  简单听取客户要求，不假思索，就传达给开发。客户所说的未必就是他们想要的，有的客户提的要求很零散，乍一听好像是个很小的问题，如果照着作了，就会发现他们又提出新的要求，理由很简单，当初没想到。还有一种客户了解业务比较深，他们会从设计的角度考虑，提出貌似很合理的改动，仔细了解后会发现，他们想要的东西与说的差别很大，因为他们认为做了这样的改动就可以出现理想中的结果，其实他们不是平台设计者，所以无法预知可能的结果，这时需求就必须纠正他们的观点，让他们明白客户只要提出他们想要的结果就行了，该怎么做是开发的事情。

2、  对客户要求分析不深，没有了解要求背后的要求。客户不是专家，他们需要引导，需求文档绝不仅仅是客户要求的汇总，而是客户要求的深度分析、归纳后的结果。

3、  客户至上。客户是上帝没错，不过，如果因为照顾客户而不顾平台的健康，结果也是彻底损害了上帝。客户有时会提出一些无理的要求，对任何一个系统都永远不可能完全满足客户的要求。需求必须要在平台健康和客户有好度之间决定一个平衡点，并且要引导客户认识到这个平衡点。

4、  对业务不做深度分析。需求应该是真正的业务专家，由需求分析后的功能不能产生不可预知的结果，这个要求确实很难达到。因为就连网院专家也未必清楚一个新的业务点可能产生什么样的结果，毕竟学历教育从报名到毕业数年时间，学生的所有数据都在里面，环环相扣，业务关联性太复杂了，整个教务管理系统，随便拿出一个小模块就是一个小系统，而且每个系统之间还存在着千丝万缕的联系。就业务复杂性而言，没有哪种系统能和学历教务管理相比。就因为如此，如果不考虑周全，这套系统很容易出现业务逻辑问题。

 

以上是个人的一些拙见，在实际工作中遇到的问题还要更多更复杂，不过万变不离其宗，只要管理者、开发、需求三者各司其责，做好自己该做的工作，那么再复杂的系统也一样能够成功。