主题：【原创】浅谈软件项目管理 -- 河蚌

-------------------

闯江湖兄发信息想讨论一下软件项目管理软件的应用问题，我写了几段后发现大概是篇幅过长回不了，索性展开来乱谈一些在工作中的体会，还望大家拍砖。

-------------------

关于软件项目管理软件，在金融IT行业里用的不多，我们主要还是用VSS来作为项目文档和源码管理，至于更专业的软件项目管理软件，则很少去用。在金融行业的其它公司里，项目管理软件的应用情况也差不多。

曾经有人向我推销相关的软件，都被我给否了。这主要与我所在的行业相关，相对而言，金融IT行业的项目并不是很大，人数在6-20人左右，实际上不使用专业的项目管理软件，只通过实施规范和文档管理来控制，也是可以的。更主要原因是，我觉得如果项目实施中有些重要问题不解决，引进的项目管理软件就是一个昂贵的废物，如果真的强制用起来，不单不能控制项目，反而会影响项目的进度。总结起来，我觉得金融行业的软件项目管理主要有下面三个方面的问题。

首先是软件系统分析设计的问题。金融行业的软件实施，是一个结合了金融业务知识和IT信息技术的综合性小门类，其成败中的关键因素，在于对业务的理解以及系统设计等技术因素。我们现在的大多数软件实施，面临的主要问题，就是没有人能够把握住业务需求，而能够将业务需求变成系统设计的人，则更是十分稀缺。和这个问题比起来，项目的管理反而是次要的。而在实际的工作中，大多数项目也许表象是管理混乱造成失败，而实质却是由于项目中缺乏合格的分析设计人员，造成业务需求没有整理清楚，以及模块没有设计清楚。用一句话来总结很多项目，就是”一群乱七八糟的人，做着一些乌七八糟的事“。

而除了设计问题，另一个原因是项目的测试问题。在金融IT实施的大多数项目组中，都没有测试人员这一组成。公司人员一般负责设计和编码，而测试，则是由银行来完成，对于四大行而言，这不是问题，但对于中小银行，实际上他们并没有能力做到测试，这就意味着功能测试的缺位，软件的质量只能由业务测试来检验，甚至到实际运行时去检验。金融行业的软件实施，往往就是在公司里打造一个初始版本（甚至最大可能是拿另一项目的完结版本），再到一个具体的项目里面去完成，实际的测试工作是由银行业务人员来完成的。所以我们经常开玩笑说，第一个去上某个软件的银行，其实就是超级冤大头（当然，四大行都有实力当这样的冤大头，而他们找公司，还有另外的商务上的考虑），出钱，出力，出人，最后做出来的系统还有一堆问题，但却为公司增加了利润、完善了产品、锻炼了队伍。

项目实施的问题是一个方面，另一个方面则是金融IT公司内部的组织架构。几乎没有哪个金融IT公司有专职的测试部门和测试人员，质量保证部门倒是有，但对项目过程中的控制，则既无能力也无动力去做。这个现象，与上面的项目实施机制有关系，但更主要是因为成本的因素造成的。对于金融IT公司而言，主要的软件实施方式是项目组到客户现场实施，这样技术人员往往是分散的（有点包工队的性质），而且每个项目在方方面面都有着特殊点，很难总结出统一的实施流程来。但项目这样分散进行的后果，就使得公司的项目实施人员相对紧张，因此，更不可能去养一群不编程只来测试功能的人了。

当然，无论是测试和质保部门的无作为，还是不进行全面的项目管理，都不是上述的理由可以推托的。实际上，随着行业的发展，各大公司都认识到项目主导体制的劣势，也开始在规范产品研发体制和 项目实施体制上下功夫，开始试着成立研发部、加强质保部，其实大家都知道这是一个重大的缺陷。但在商言商，任何一个部门的成立，都是有财务压力下，测试部门到目前为止都无法找到合适的定位，也没有找到与实施部门结合的最佳途径，因此这个部门在项目主导制下是很难成立起来的。而既然在软件公司的基础组织架构上就有缺腿，因此全面的项目管理也就无从谈起。

基于上面的行业背景，有时候你不能去正面强行改变这种环境，那就只有尝试着改变其它的东西。因此，相对于到项目里加强项目管理和推行项目管理理软件，我觉得，更应该重视应用产品研发以及辅助开发工具及平台的研发。而做这些工作的主要目的就是要减少项目中的人数，这样就可以减少项目中的管理成本。项目组人少了，就可以面对面地交流，有什么问题，项目经理可以很快发现，即时纠正，很多需要文档往来的东西，通过简短的交流就可以完成了。实际上，我也十分不喜欢项目中有所谓专职项目经理，即只管分配任务和成员协调，而对项目的技术一无所知的人。

当然重视应用产品研发和开发平台研发的终极目标，则是要变现在的项目主导制为产品主导制。我们分析过，同一个系统在不同银行的版本，差别其实不到 20%，如果我们按照产品主导制来重构公司的技术体系，是可以大幅度的减少项目的工作量的。实际上很多金融行业中更为专业的公司，已经是这样做的，而且成效很大。比如做信贷管理的安硕和以前做网银的易诚，都是这个方面的姣姣者。当然，产品主导制无法在公司推广开，与北上广地区公司的人员流动性过大有很大的关系，有时候，真的，不是别人想不到（或者说不是别人比你傻），只是环境不允许罢了。

上面谈的都是体制问题，也可以称为形而上的东西，下面还是谈一谈形而下的东西，也就是项目管理和系统设计方面的一些具体的体会吧。

首先，要正确地看待项目过程中的需求变更。现在很多的所谓的项目控制，就是将各种变更动作文档化，其最大的目的就是希望通过加大变更流程的复杂度来打消变更者的意图。但有很多情况下，不管你愿还是不愿，问题就在那里，无法回避。关于需求变更，业务人员可以很不客气地说，这个问题是我需求时没想明白，但那又怎么样，谁他妈还能是生下来就知道一切的，这个地方不变，就意味着软件根本就没法用，那我能给你验收报告吗。需求变更，如果是增加功能，那是需要讨论的，而如果是功能流程上的变动，这往往就意味着系统的分析设计结果有问题，有时是不得不改的。

系统设计在实施过程中的微调是不可避免的，而要让缩小这种微调的影响，我觉得，最重要的是设计阶段的方法。项目的需求、设计、编码、测试这几个阶段中，最核心的是概要设计阶段，在这一阶段是承接业务与技术的关键，要完成功能模块的划分、模块IPO设计及数据结构设计这三个重要工作。概要设计的过程实际上也意味着系统的一个推演过程（未战而庙算胜者，得算多也），只要在概要设计中将模块分得足够细致（每个模块的工作量不超过2天），将模块的处理流程描述清楚，并且将数据结构（数据库）的设计定下来，那么根据模块清单就可以很方便地将任务分到程序员身上，并且可以根据进度表对程序员的编程进行严格控制。概要设计做不好，那么所有的项目控制和项目管理，实际上都是空话。

在完成设计之后，项目才能铺开来由大量技术人员完成编码。在这一阶段，项目任务清单是主导控制文档，它也是项目任务的工作计划表。它是由概要设计的功能模块清单展开来的，同时列出每一个底层模块的执行人、执行时间。每一个模块工作任务的工作量不超过两天（大多数是一天），如果超过，那么就意味着设计工作做的不细。做这个约定是必要的，因为这就意味着项目经理可以对项目日程进行更为精细的掌控，可以更容易地进行任务的调配。

目前，我们在项目中主要是通过文档来控制进度，如项目总体计划表、项目任务清单、项目测试计划、测试用例清单等。而文档管理，最主要的问题是，文档具有阶段性，过了某个阶段之后修改起来就比较麻烦，特别是没有修改日志。而且项目文档与系统之间是有映射关系的，比如模块名称其实与程序中的类名、函数名有对应关系，数据库设计文档与数据库实体有对应关系，但由于先是文档编辑来完成设计，很难将WORD或EXCEL文档直接变化成系统的程序上，这中间都需要重复性的手工工作。而在编码阶段，实际上技术细节还会有很多微调，因此，就会造成程序与文档的不一致。这些问题，有时才让我感叹，如果有一个项目管理工具能够完成这些工作，那该有多好呀。

现在，各公司都在过CMM认证。CMM2规范（项目级的）和CMM3规范（公司级），都是很好的，对于项目管理机制具有很高的借鉴意义。但CMM关键的问题（或者说这是所有规范的通病）是，这些规范在实施中，可以说是考虑了项目控制的全集，因此不可避免地要求项目组生成了大量的有很大重复性的文档（因为要发给不同部门的控制人员），从而将非技术的工作量大大增加了。如果项目进度不紧张，倒也没什么，但很多项目进度很紧时，项目成员对这些反反复复填写的东西都十分反感，最终变成能不填就不填。而质量控制人员（包括QV 和SCM）在项目中则本身就是边缘人物（有些本身就不是软件实施部门的），对于项目组成员并不具有控制力，因此最终，项目管理规范就变成了形式。项目控制文档都变成了项目结束之后突击补充，失去了原来的控制意义。

我觉得，项目管理软件，重点要解决的应该是上述这些问题，就是说，要将项目中的重复工作变成软件内部处理的事情，所有的项目要素只要项目成员输入一次，而最终可以形成各样的文档，这不但是指重复的管理文档，对于技术文档可能更为有用。比如需求说明书、概要设计、详细设计的工作，都在项目管理软件上完成，并且由这些工作成果，可以生成用户要求的设计文档，也可以直接变换成程序或者数据库脚本定义（在数据库设计上用PowerDesigner或者ERWIN是可以做到的）。这样的话，在编码阶段，需求和设计的微调，就可以在原来的工作基础上体现出来，留下控制日志，而且也利于大家协同工作。

总而言之，无论是项目管理规范还是项目管理软件，都应该是为项目提供更好的工具，为程序员提供更大的便利，而不是所谓面上的流程规范化，实际上却是工作文档化和复杂化。只要能够让技术人员感觉到便利性，能够在项目中自觉使用，那么实施规范也就会潜移默化的建立起来。

因此，如果一套项目管理软件，不能将分析设计结果内嵌进去，而还只是文档管理，那还不如用VSS更实在。

这是我的一些体会，工作多年，胡子一把，经验不多，教训不少，有些乱七八糟了，希望大家多在这方面交流。