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

不过感觉楼主的软件开发经历还是比较局限于比较小规模的软件。我说一下我的一些观点，我其实项目管理经验很少，欢迎大家讨论：

1.VSS似乎应该规到“版本管理”而非“项目管理”软件类里。这个类别里还有CVS，SVN,git，Clearcase等等。其中数clearcase最专业（当然也最费钱）。我认为这类软件的版本管理作用主要体现在2方面，一是多人协作，一是版本记录.前者不用说，后者之上还有branch, tag,mainstream之类的概念，再之上又衍生出一些稍高层的作用，比如Clearcase提供的UCM，这个东西已经可以帮助到项目管理了。我觉得这种软件对那种大规模，新版本会不断持续，质量要求高的软件特别有用。对那种10个人以下一两个月开发搞定的事，可能更像一个源文件存储器而已。

2. 概要设计的粒度问题，我过去的经历里还没经历过设计粒度到2天开发周期的情况，那里的概要真的很概要。而且，概要设计之下的详细设计也没遇到过设计的某个模块可以到2天开发周期的粒度。我只听说过日本公司会搞的这么变态。但我有一个疑问，因为需求变更会比较多，往往前面设计阶段越细，返工的代价越大。能解决这个问题，就我从理论上所知，Agile可以，即快速原型，快速迭代。

我以前在一个比较规范的公司里做，需求到开发阶段之后基本上不可能再发生变化，但这往往导致的后果是，一个需求从客户那列出来到最后产品到客户那里，需要2年以上的时间。这样的时间对很多客户和公司都是无法想象的。这也是项目管理一个比较麻烦的地方，在进度/质量/需求之间找平衡,我个人觉得这是在管理好团队这件事之外最难的事。你不太可能让同时你的客户和你的老板满意，如果是真的，那你的下属可能被你压榨的太历害了.

我所经历的项目，确实是在20人以下的比较多，在这样的项目中，主要的项目交流是通过面对面的方式进行的，专业的项目控制软件不用也可以。而VSS则主要是用来做文档的管理（当年过CMM时人家培训SCM时就是用这个），而CVS和SVN，则是现在的WEB/JAVA端的开发人员用来做源码管理的。所以说，在软件项目控制上，真的比较原始。

概要设计划分出的模块要到2天的粒度是我的经验。你说的“概要真的很概要”，我有点没看明白，是说这个粒度粗了还是细了。看你后面的意思，似乎是这个粒度太细了。但我认为，只有保证你的设计做到这个粒度，才会保证项目能够按计划比较稳定的进行。

在我的项目经验里，如果交给程序员的一个任务，时间在1周左右，就意味着可能会有1周的变化量。我们的项目编程周期都是以周为单位展开的，即任务不跨周。如果任务时长是1周，意味着，是在周末提交，而如果此时程序员说，本周没有做完，项目管理者的选择只能是让他承诺还有几天能完成，1周的工作延迟一般都会是2天，而如果2天还没有做完，那么就意味着工作会延迟1周左右。而当1周延迟再做不完，此时项目管理者，将面临一个两难选择，是将此人的任务交给别人，还是让此人继续把模块做完。

只有将模块细分到2天左右的工作量，交给程序员时，才能真正做到有效监控，2天的任务，其变化天在半天左右，而这所谓的半天，一般并不是延迟影响下面的任务，而是通过当天的加班来搞定。如果延迟的时间里再完不成，意味着程序员可能并不称职，那么项目管理者可以很容易地做出决定，将此任务布置给其它程序员。

在概要设计中将模块细分到2天左右，并不是一个很难的事情。这里面大概有个误区，我不认为概要设计是所谓系统的模块粗分，而是认为，概要设计的工作就是已经将模块分割到位了，只是在此阶段，你不需要把模块的详细程序流程画出来或者写出伪码（这两个是详细设计的活儿），而只是列好模块清单、数据结构（数据库）说明，并为每一个模块定义好输入、输出和简要的处理过程描述（IPO）。按照这样方法，那么这个概要设计工作，对于有200个模块的系统来说，一个人可以在两周左右就能完成。

”需求在开发阶段不发生变化“，这个要求在企业集成软件项目中是不可能实现的，这个和公司规不规范没有什么关系。如果一个软件是面向消费者的商业软件，需求在开发阶段不发生变化是可能的，因为需求的主导者本身就是公司的另一个部门，控制权是公司内部（当然即使是这样，实际上商业软件在开发中需求发生重大变化的例子仍然比比皆是）。而集成软件项目，需求是由客户决定，在实施过程中将需求继续深化，是一件很正常的事情。这也是我在主帖中认为项目管理应该把需求变更作为一个正常情况来处理而不是作为特例来限制的主要原因。

我的意见，项目管理，不是追求所谓的需求不变动、设计不变动。“需求到开发阶段之后就不会变化”，这其实就是软件工程瀑布法的基本思想，可为什么那么多人推崇原型法而反对瀑布法，就是因为瀑布法中阶段成果在下一阶段不能变更的做法，是不现实的。有句话，叫做”在商言商“，脱离商业环境去追求软件项目管理，意义不大。比如你说需求从客户提出到最终产品实现，需求2年以上的时间，如果这是公司的做法，我倒认为这已经不是软件项目控制问题，而是公司管理的问题了。这样的过程，按中国一句老话，叫“黄瓜菜都凉了”。在目前市场变化这么剧烈的情况下，这样的反应，在中国就是自掘坟墓。

其实我挺欣赏《人月神话》和微软《快速软件开发》里面的观点，按主治医生方式的软件项目组织构成是我很欣赏的，而快速软件开发中对于项目进程的预判，也真是我深有同感的经验。

在我看来，软件项目的开发人员如果做到30人以上，其管理成本和人员协调上的工作已经超越了软件实现所花费的精力。也许是金融行业的软件工程控制得真不太好，我所经历或者遇到过的40人以上的项目，没有不延期的。而且这些项目在我看来，如果项目组成员之间足够了解的话，实际上20人已经足够了。

因此，在我看来，如果是一个很大的软件系统，我倒建议，在项目策划阶段，就将这个软件，划分成几个子系统，分阶段实现，当然，这种方法只适用于管理软件（毕竟我们不能让过程控制软件也这么做）。每一期项目的开发人员，都限制在20人以下，也许这种方式在系统启动阶段的计划上，似乎时间会长一些。但实际执行下来，效果反而会好的多。

先不说商业上的战略问题，只单就软件项目而言，在我看来，任何一个单一项目，其项目由需求开始到上线时间都是以6个月为最佳的实施周期，而其中编程实现阶段（指编码和功能测试两个阶段）不应超过4个月。如果项目整体时间超过1年，都将会有很大的延迟，而如果单一项目的计划时间在2年或者2年以上，我觉得这样的项目都只会是一个失败的项目。

在一次小交流会上，那个名字怪怪的有"教母"之称女士点评过一些公司，迭代时间，团队构成，location分布等等不合格，她老人家都不承认的。

至于我写的那些，有经验的小头目都会做，用不着什么名头 :)

这个点很有意思，老法师了：）

行业软件越来越往辅助决策这个方向走--这个是管理层关注的。

而对具体的工程师而言，出设计/结果的效率才是第一考虑。这个矛盾在整体流程变更之前，基本无解。

有个正在进行的项目就是这样。经过一段时间与工程师的交流，最后发现他们所反对的，恰是产品的优势所必然带来的代价，而这个优势，是说服大boss最关键的东西。。。

原来是只缘身在此山中。这倒是个挺好的话题。

如果换个角度，变成不是做项目，而是推销产品呢？

我以前设计做的比较粗,不做类图,开发人员是否按照设计来实现功能全靠自己codeReview,结果把自己累的半死不说,如果组里有人员变动,很多约定俗成的东西就又要再通过codeReview之后的会议形式再强调一遍(虽然有文档,但是真的会去看的实在不多),然后通过多次打回去重写,这样的方式才能完全纠正.

现在每次项目设计阶段我都让开发人员去做类图,然后做评审,等于一遍一遍给开发人员讲业务需求和设计思路,这样虽然在设计阶段会消耗比较多的时间,但是在开发阶段不容易出问题,任务切分也可以做的按小时计算,开发进度一目了然.codeReview也只要配合checkStyle,findBug,mi之类的工具再做抽查就可以了,基本能够保证代码质量.

在项目实践中，我是这样理解的。如果只是做到模块清单，数据库设计、以及模块的IPO简要说明，这个可以称为概要设计。很多系统的概要设计可以由两三个人就搞定，而对于大多数公司来说，实际上能做设计的人也就那么几个，所以这种方式是比较切合当前的行业环境的。

在这个概要设计的基础上，可以将模块分给编程人员，由他们来完成类图的设计，然后再复审，这个我觉得可以称为详细设计。详细设计是项目中的重要环节，如果是一个全新的项目一个全新的团队的话，那么这个环节是不可省略的，即使详细设计的工作量可能与编码工作量一样多，也应该坚持，毕竟文档的可读性与程序不可同日而语，而更关键的是，详细设计是对编码的最好的约束。

不过对于大多数编程人员来说，完成类图设计是件苦差事，而且很多技术人员很不善长写文档（这还是锻炼少的原因），可能会要来回很多次还是不得要领。因此这个阶段往往要十分地花费时间。由编程人员分担的详细设计时间仍然会比集中由设计人员做的概要设计时间长很多，而由几个设计人员来完成详细设计，这工作量则大的不可想象。

因此，对于一个成型的公司和比较熟悉的领域，我觉得在项目中可以省略详细设计，而由编程人员直接根据概要设计开始写模块。这个方法的缺点是很明显的，就是上面说的，很多规范可能会被人忽视，只能再通过重复的编码审查来强调。但我觉得，这些缺陷，可以由下面两方面来弥补，一个是技术队伍的建设积累，另一个是开发平台和技术框架的积累。

微软的《快速软件开发》里那个盖房子的故事写的很经典，他深切说明了多年配合的重要性。开发项目成员，如果骨干成员是在一起共事了4、5年，那么很多规范已经成为了大家的共识，包括很多系统基础模块，都是大家平时一起做项目时，都共同研究确定的。而另一方面，软件开发平台及系统技术框架，实际上就是大家共同劳动积累很多年的产物，这个不单可以减轻工作量，更主要地是很多规范（即约定俗成的东西）已经被内置在平台里，在这个框架下做开发，实际上要求编程人员必须遵从相应的约束。

我觉得，只要有上述的基础，就可以不做类图（或者流程图），在概要设计之后，跳过详细设计直接进入编程。因为实施项目，主要是对产品进行客户化，必须在产品原有框架内完成。而产品研发项目的成员，多来自于实施项目的骨干，他们熟悉系统的框架，也有相应的业务知识。而在编码过程中，还可以通过不断地交流来将问题细化。

关于项目编码阶段的交流，我觉得也是一个关键的环节。而如何对待，实际上与公司的组织架构有关系。如果设计和编码是两个部门的话，设计人员一定会认为与编码人员交流是一件额外的苦差事。但是如果采用产品经理制，并以产品来划定部门的话，那么实际上设计人员更可能就是部门的高级经理，其本身既是编码人员的领导，同时还是编码人员的老师。在这种情况下，我想，尽可能多的在编码阶段进行交流，不但能够树立设计人员的威信，而且对于团队建设有很大的好处。

在企业组织架构里面，有明线和暗线两条，明线就是行政体系架构，部门科室，暗线则是技术传授，师徒门生。而由于IT企业的工作性质，实际上，师徒关系要比一般的企业里面更加明显地体现在上下级关系上。一个执行力很强的部门，一般来说，其技术负责人或者部门主管都同时也是技术灵魂。而这个角色，不是因为他职位高，而是因为在项目历练中，由他一手创立了技术体系，同时也带出了众多的徒弟。这样的部门，也许技术上不是最先进的，但肯定是最有效率的。

实际上，一只成熟稳定的技术队伍、一个积累了很多年的研发平台，是比项目规范更能决定项目的成败，当然这些领域都属于公司级的软件管理范畴，而不属于项目级了。

很多事情，受公司的资源限制，如果单纯在项目里面看，是无解的，成本压力在那里摆着，如果所有的项目都要尽善尽美地遵守规范的话，那公司铁定要黄铺的，因为支出会成倍的增加。这是老板不会答应的。但如果放在公司层面来考虑，确定产品发展路线和技术队伍培养计划，很多问题其实可以在不断的积累中加以解决的。

以上这些观点，可能是为不正规的软件企业组织方式在辨解，并不一定对。只是，在这很多年的工作中，所经历的公司，几乎都面临着同样的软件项目实施难题。而这些难题的解决，一种办法就是强化软件项目管理正规化，但这意味着成本的增加，更意味着要求增加公司的技术人员。实际上成本并不是不可解的，经过这几年的教训，很多老板对技术队伍的建设是舍得投入的，但金融IT行业，近十年最大的问题是技术人员的绝对短缺和大量流失，这是一个在公司层面根本无法解决的问题。所以只能走另一条路，就是从公司层面想办法，看如何能够在现有条件下走出一条生路来。

我不知道您是做什么金融软件的，但我也曾在这个行业混过饭吃

几个项目就没有100人以下的

最多的一个高峰时期光是测试就1000多个人

想问一下，是什么软件项目，在什么公司里做的，两联两天时代，还是四小龙时代，或者是现在。当然，如果是国外金融软件的外包，或者干脆是在国外，这个我确实不知道，我是个地地道道的土鳖，到现在也只是国内的金融IT领域混口饭吃。

到目前为止，真的还没有见识过测试有1000个人的项目，四大行的研发中心，好象也没哪一个有这么多的人员吧。即使到现在，金融领域软件员工人数能够到1000人的公司也屈指可数。我想不但我没见识过这么大的项目，河里的大多数人也没有见识过，倒是可以说说，让大家都长长见识，河里本来就是牛魔王聚会的地方。

百人以上的项目，在银行内并不少见的，很多省级银行的核心业务系统，项目人数都会到上百人。但这些毕竟是少数。我只是说大多数的项目人数，是在20到40人。我想既然是混金融的，也一定知道银行业（金融还包括证券和保险，不过除了证交所，其余的企业规模还是比银行小多了）有哪些软件和软件，列一下行业客户和要做的软件就知道银行软件项目是什么样的规模了。

银行的软件，目前主要分为几大领域，即综合业务系统（核心及总账）、渠道（综合前置、网银、ATM、CALLCENTER）、支付（银联、大小额、电票等）、报送（1104、反洗钱、金融监控、征信等）、管理软件（财务、人力资源、CRM、绩效、风险、资产负债管理、OA等）。而银行客户，除了四大行、13家全国股份制银行外，还有38家省级及中心城市商业银行，约114家二线城市商业银行，30家省级农信及10余家独立的农商行（这些数据，是去年做灾备中心方案时按省统计出来的，到现在可能有点偏差）。

银行的系统，除了综合业务系统项目人员较多外，其余项目的人数均在10到30人之间，这还是指省级银行项目，而区域性银行的项目，实施的人数多在20人以下，很多外围系统的项目人数甚至是在10人以下。

我想，啥观点都要用数据说话吧。俺一直认为，经历千人项目的人，都可以称之为神，既然有神的经历，何不说的详细一些。

目前一个项目正在转产品.项目实施经理的缺少(不能把一线开发随便拉去吧）

这块不知道楼主大哥有没有想法。多个同质化但20%的需求不同的项目一起上线，一起升级。如何控制？

比如人民银行要求上的大小额支付、银联2.0、身份核查，以及反洗钱、人行集中报送等项目，都是前几年某一阶段的重点戏。客户多的公司，可能同时开展20个以上的项目。细究起来，需求差距可以算是20%，因为主体部分是相同的，不同的只是接口部门（与银行综合业务系统的接口）。

对于这种类型的项目，公司是采用产品中心的模式来应对。在上线之前的预备期（3到6个月）研发产品，建立产品核心团队，后期在产品完成后，则开始通过培训建立实施团队。到实施时，将实施团队撒出去，每个项目多在2人左右，核心成员有时在实施团队中，有时是在家负责技术支持。然后在2个月时间完成上述项目的上线。核心成员一般既要保证自己的实施项目的成功，同时还要为其它项目提供技术支持，同时还要及时更改实施中发现的BUG，其中的辛苦那是大大的。

关于多个同质化项目的同时启动和上线，实际上专业金融产品（指以单一金融产品为主营业务）的实施商的技术运作模式就是这样的，因此这些公司是将上述的方式变成公司机制来运作的。比如专做信贷的安硕，专做网银的易诚（即宇信易诚的前身之一，国内网银的绝对垄断商）。他们都是分为产品部门和实施部门两个组成部分，到客户现场的实施团队（人数在4-6人），只负责收集客户需求和调试，而客户化编程的工作，都是由后方的产品支持团队来做的。

软件产品化的核心内容，是将系统技术框架平台化，然后尽量采用参数配置的方式实现业务逻辑。在这一产品化的过程中，在人员上会形成产品核心团队，在技术上会形成软件开发平台，项目的实施量会大大降低。在公司技术团队的支撑下，进入客户现场的团队人员素质要求会太大的降低。

长远地看，如果公司的某个产品拥有5个以上的潜在客户市场，都应该采用上述的产品中心模式。这个标准是很低的，应该说，只要是公司层面的软件产品，都会满足这个标准，也都应该采用这种模式。这也是我现在极力主张在公司组织架构上以产品经理制取代项目经理制的原因，实践起来，效果还是不错的。

现上轿现扎眼有时候会觉得有些来不及。但不管怎么说，多个同质项目上线，实行产品核心团队和实施团队相结合的办法，既是现实的选择，也恐怕是技术人员的共识。挑战也是机遇，以前也许因为各种因素无法实施，而面对危机时，大家总是会抛弃一些个人成见和利益的，倒是正好采用上述模式的时机。有这个开始，并按这条路坚持走下去，总会是一个不错的选择。

现在一般都说核心银行系统

举例来说，一个四大行的核心银行系统

开发人员也是几百号，还多亏业务定制已经做完了

基本上有6000多只交易，100,000左右测试案例

在原来没有自动化测试的时代

上千测试人员很正常呀，至于测试人员来源，都是分行抽调

我在里面算是一个角色吧

原来做另外一家四大行的综合业务系统的时候也都是上千的测试人员

再举一个例子，另外一个四大行的网银

开发人员大概100多，测试人员更多，这都是很正常的

连股份制银行BPR的开发人员都超过100了

如不出意外，马上就不用在这个行业混了，可以做些不那么费心的纯粹技术工作

到时候跟大家分享一下吧

这个到底要怎样验收啊？

中小银行也是银行啊。。。到实际运行去检验，出了事故应该算到谁的头上去？

太让我吃惊了。。。。

当年在银行里工作时，做系统如履薄冰，改一个程序提交上去之前，反复测很多遍，然后上去之后还是会疑神疑鬼，都快得强迫症了。到公司之后，发现公司竟然让刚毕业的小孩子去做人民银行的现代化支付，而且竟然也没出事，这个也令我惊叹了。

错，是会犯的。但是去银行上的系统，也不是说乱写的。基本的流程还是要对的，而且也要在公司里进行测试的。正常情况下是出不了错，但是极限情况下还是可能的。交易量大时，极限情况可能出现，而中小银行，业务量小，所以程序走正常流程，出错的可能性不大。但是零星还是会出的，咱在河里写过一个系列，叫“银行的事故”，就是讲这些IT的事故。

去到银行上线的系统，一般都是经过几个案例的实际运行的，比较稳定。而新产品，出错的可能性要大的多。一般都会由公司派专人维护，出了错马上就改，银行去向客户追钱的事情，也是有多起。新闻里面，经常会出那些银行与客户的纠纷，很多是和IT系统有关系的。

给你的use case都跑通了大部分情况也就覆盖了，一般用户不会胡搞瞎搞都是按部就班地干活，这就省了一大块心。