五千年(敝帚自珍)

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

共:💬31 🌺133
全看树展主题 · 分页首页 上页
/ 3
下页 末页
家园 【原创】浅谈软件项目管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关键词(Tags): #IT(廣雅疏證)#软件(廣雅疏證)#项目管理(廣雅疏證)元宝推荐:holycow, 版面翰林推:forsake, 通宝推:舞动人生,闯江湖,上古神兵,铁手,
家园 工具不是最重要的,但为何还使用如此古老的版本管理工具?
家园 因为它是不收钱的。

还因为他是微软的,和OFFICER产生的文档配套。

WEB/JAVA上的源代码版本控制以前用CVS,现在开始用SVN。

家园 写的不错

有些话,说的跟实际情况很相符。我们是做电信网管软件,文中说的很多问题都遇到过,整个项目做下来,往往可用性不大,但是网管软件毕竟不是给用户做创收的。其他的行业软件不是很了解,很奇怪,如果情况都类似的话,用户为什么还要做那么多软件,难道还抱有希望,或者用户参与度不够。

家园 银行的大多数软件都是有用的

这个是谈项目管理中的混乱情况,并不代表这些项目都是不成功的。大多数项目是延迟、延迟再延迟,最终还是会上线的,而且随着运维阶段不断地改BUG,还会错误越来越少,稳定度越来越高。

与此同时,公司一个产品线也会随着项目实施案例的增多,而日渐稳定,项目实施也越来越成熟。一个部门,一个产品,只要在做,总是会进步的。

但是这种机制,其实就是久病成医。

问题是,一个公司不能只做一个产品,总要开发新的产品。而一旦上新产品,马上又会重复老路,甚至对一个产品做出重大的升级,也同样是一个痛苦的过程。

我们做项目,总是希望,对于新的项目,也能借鉴过去的经验,让它能够做的足够稳定,这个体会主要也是写这些方面。

家园 git/hg更好用
家园 对业务的理解很重要却很难得到

其成败中的关键因素,在于对业务的理解以及系统设计等技术因素

这句话总结的好,而且适用于其他行业软件。行业软件的特点是最终用户往往无权决定是否使用它,而是管理层拍板买不买用不用它。

开发者很难得到真正的最终用户反馈的从而获得对业务的理解。真正用户的反馈需求也很难传递到开发。

家园 需求这个环节确实太关键了

在项目初始阶段,就需要双方确定需求的功能边界,并且通过组织架构明确需求变更的流程,其中用途之一就是限制无谓需求的追加。

我过去经历的一个失败经验是,系统委托方领导不断增加想法,而系统架构面临推倒重来的问题,问题是按照项目时间表,下一步将是系统上线试运行。这就是开始阶段需求不扎实的后果,结果是这个系统悲剧了。

家园 花好文

有个小建议:分割成不同的部分也许可以更有利于讨论

家园 关于需求分析、设计

我们现在的大多数软件实施,面临的主要问题,就是没有人能够把握住业务需求,而能够将业务需求变成系统设计的人,则更是十分稀缺。和这个问题比起来,项目的管理反而是次要的。而在实际的工作中,大多数项目也许表象是管理混乱造成失败,而实质却是由于项目中缺乏合格的分析设计人员,造成业务需求没有整理清楚,以及模块没有设计清楚。用一句话来总结很多项目,就是”一群乱七八糟的人,做着一些乌七八糟的事“。

这个现象在所有行业软件里,都是一个首要考虑的因素。这其实是个项目管理的经典问题。我举一个刚经历的例子。这个项目是严重依赖于行业的,但恰好一个懂行的PD刚跳走,所以开局有点难看。顶上来美国MM,c刚毕业没多久,对行业更是一无所知。刚开始俺也挺犯嘀咕的,不过一两周后就比较安心了。C在这两周里只做一件事--用户访谈,然后转化为用户的痛点阿,用例阿什么的。随后就好办了,一两个月为周期,不停地出原型给用户,收集反馈,几个迭代后,大事就定了。当然,如果团队里面有个行业专家就完美了,大大提高效率。

家园 中国的项目经理都不是累死的,而是郁闷死的
家园 这就是Agile吧

我的结论也是,这么搞用户最喜欢。

家园 也不是,Agile原教旨会不同意的 :)

Agile其实是把一些东西纯化后的组合技 :)

家园 需求分析确实很重要

对于我们这些已经在一个行业里面做了很多年的人来说,由于经验的积累,甚至大部分客户都已经无法和我们比深度和广度。但这反而让我们对于需求分析的理论认识是最少的,因为对于我们来说,要做一个系统,需求就在那儿,就是那个样子,大多数的客户访谈和需求交流,目的只是为了验证客户是不是也是按照我们设计的这种模式去做,是不是还有什么特殊的要求。

但是,上面这种模式实际上就是专家模式,项目需求的好坏,依赖于谈需求者的专家业务水平。这种需求交流是无法复制的,随便换一个人就可能连这样一半的效果都达不到。

而对于公司而言,最好的需求交流方式,是假定公司的谈需求者是不懂业务的,而只是通晓一套需求交流的规范(当然,此人依然要有比较高深的IT技术水平),然后根据这套规范,与客户进行访谈,并最终总结出一套完整的需求文档出来。这样的方法才是可以大规模推广的,才是可以重复的(可重复是CMM几级的标准?忘了)

我曾经在2001年短暂地做过一个邮政系统的项目,是邮区中心局的生产系统。这个项目使得我能够跳出银行业,以只懂得IT不懂业务的全新身份来进行系统设计。这个项目,让我认识到,实际上各个行业的企业,其运作流程都有很大的相似之处,而IT系统,不外是企业的实物流、数据流和凭证流进行来回的处理和输入输出。我试着将银行网络的某些运作规律,套到邮区中心局上,最终在业务深入的过程中,发现竟然也相差不大。

通过这个项目,我觉得,应该有一套方法,让只学过企业管理学而没有行业知识的人,可以很方便的了解特定企业的运作机制,并将其运作机制转换为IT系统的实现。毕竟,麦肯锡的成就还是摆在那儿,虽然他的后任者为大家贡献了无数的笑话,但是,既然跨行业的咨询可以做,跨行业的IT需求肯定也可以做。

不过,如何总结出这个方法,确实是一件很让人期待,但在目前也很令人费心思的事情。

家园 好像就是Agile哦

Agile其中一个核心观点,拥抱需求变更,用快速原型和迭代的方法不断收集和满足用户需求。你上面的描述简直就是Agile的描述文字copy过来的嘛

全看树展主题 · 分页首页 上页
/ 3
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河