- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】浅谈软件项目管理 -- 河蚌
家园 【原创】浅谈软件项目管理 -------------------
闯江湖兄发信息想讨论一下软件项目管理软件的应用问题，我写了几段后发现大概是篇幅过长回不了，索性展开来乱谈一些在工作中的体会，还望大家拍砖。
-------------------
关于软件项目管理软件，在金融IT行业里用的不多，我们主要还是用VSS来作为项目文档和源码管理，至于更专业的软件项目管理软件，则很少去用。在金融行业的其它公司里，项目管理软件的应用情况也差不多。
曾经有人向我推销相关的软件，都被我给否了。这主要与我所在的行业相关，相对而言，金融IT行业的项目并不是很大，人数在6-20人左右，实际上不使用专业的项目管理软件，只通过实施规范和文档管理来控制，也是可以的。更主要原因是，我觉得如果项目实施中有些重要问题不解决，引进的项目管理软件就是一个昂贵的废物，如果真的强制用起来，不单不能控制项目，反而会影响项目的进度。总结起来，我觉得金融行业的软件项目管理主要有下面三个方面的问题。
首先是软件系统分析设计的问题。金融行业的软件实施，是一个结合了金融业务知识和IT信息技术的综合性小门类，其成败中的关键因素，在于对业务的理解以及系统设计等技术因素。我们现在的大多数软件实施，面临的主要问题，就是没有人能够把握住业务需求，而能够将业务需求变成系统设计的人，则更是十分稀缺。和这个问题比起来，项目的管理反而是次要的。而在实际的工作中，大多数项目也许表象是管理混乱造成失败，而实质却是由于项目中缺乏合格的分析设计人员，造成业务需求没有整理清楚，以及模块没有设计清楚。用一句话来总结很多项目，就是”一群乱七八糟的人，做着一些乌七八糟的事“。
而除了设计问题，另一个原因是项目的测试问题。在金融IT实施的大多数项目组中，都没有测试人员这一组成。公司人员一般负责设计和编码，而测试，则是由银行来完成，对于四大行而言，这不是问题，但对于中小银行，实际上他们并没有能力做到测试，这就意味着功能测试的缺位，软件的质量只能由业务测试来检验，甚至到实际运行时去检验。金融行业的软件实施，往往就是在公司里打造一个初始版本（甚至最大可能是拿另一项目的完结版本），再到一个具体的项目里面去完成，实际的测试工作是由银行业务人员来完成的。所以我们经常开玩笑说，第一个去上某个软件的银行，其实就是超级冤大头（当然，四大行都有实力当这样的冤大头，而他们找公司，还有另外的商务上的考虑），出钱，出力，出人，最后做出来的系统还有一堆问题，但却为公司增加了利润、完善了产品、锻炼了队伍。
项目实施的问题是一个方面，另一个方面则是金融IT公司内部的组织架构。几乎没有哪个金融IT公司有专职的测试部门和测试人员，质量保证部门倒是有，但对项目过程中的控制，则既无能力也无动力去做。这个现象，与上面的项目实施机制有关系，但更主要是因为成本的因素造成的。对于金融IT公司而言，主要的软件实施方式是项目组到客户现场实施，这样技术人员往往是分散的（有点包工队的性质），而且每个项目在方方面面都有着特殊点，很难总结出统一的实施流程来。但项目这样分散进行的后果，就使得公司的项目实施人员相对紧张，因此，更不可能去养一群不编程只来测试功能的人了。
当然，无论是测试和质保部门的无作为，还是不进行全面的项目管理，都不是上述的理由可以推托的。实际上，随着行业的发展，各大公司都认识到项目主导体制的劣势，也开始在规范产品研发体制和 项目实施体制上下功夫，开始试着成立研发部、加强质保部，其实大家都知道这是一个重大的缺陷。但在商言商，任何一个部门的成立，都是有财务压力下，测试部门到目前为止都无法找到合适的定位，也没有找到与实施部门结合的最佳途径，因此这个部门在项目主导制下是很难成立起来的。而既然在软件公司的基础组织架构上就有缺腿，因此全面的项目管理也就无从谈起。
基于上面的行业背景，有时候你不能去正面强行改变这种环境，那就只有尝试着改变其它的东西。因此，相对于到项目里加强项目管理和推行项目管理理软件，我觉得，更应该重视应用产品研发以及辅助开发工具及平台的研发。而做这些工作的主要目的就是要减少项目中的人数，这样就可以减少项目中的管理成本。项目组人少了，就可以面对面地交流，有什么问题，项目经理可以很快发现，即时纠正，很多需要文档往来的东西，通过简短的交流就可以完成了。实际上，我也十分不喜欢项目中有所谓专职项目经理，即只管分配任务和成员协调，而对项目的技术一无所知的人。
当然重视应用产品研发和开发平台研发的终极目标，则是要变现在的项目主导制为产品主导制。我们分析过，同一个系统在不同银行的版本，差别其实不到 20%，如果我们按照产品主导制来重构公司的技术体系，是可以大幅度的减少项目的工作量的。实际上很多金融行业中更为专业的公司，已经是这样做的，而且成效很大。比如做信贷管理的安硕和以前做网银的易诚，都是这个方面的姣姣者。当然，产品主导制无法在公司推广开，与北上广地区公司的人员流动性过大有很大的关系，有时候，真的，不是别人想不到（或者说不是别人比你傻），只是环境不允许罢了。
上面谈的都是体制问题，也可以称为形而上的东西，下面还是谈一谈形而下的东西，也就是项目管理和系统设计方面的一些具体的体会吧。
首先，要正确地看待项目过程中的需求变更。现在很多的所谓的项目控制，就是将各种变更动作文档化，其最大的目的就是希望通过加大变更流程的复杂度来打消变更者的意图。但有很多情况下，不管你愿还是不愿，问题就在那里，无法回避。关于需求变更，业务人员可以很不客气地说，这个问题是我需求时没想明白，但那又怎么样，谁他妈还能是生下来就知道一切的，这个地方不变，就意味着软件根本就没法用，那我能给你验收报告吗。需求变更，如果是增加功能，那是需要讨论的，而如果是功能流程上的变动，这往往就意味着系统的分析设计结果有问题，有时是不得不改的。
系统设计在实施过程中的微调是不可避免的，而要让缩小这种微调的影响，我觉得，最重要的是设计阶段的方法。项目的需求、设计、编码、测试这几个阶段中，最核心的是概要设计阶段，在这一阶段是承接业务与技术的关键，要完成功能模块的划分、模块IPO设计及数据结构设计这三个重要工作。概要设计的过程实际上也意味着系统的一个推演过程（未战而庙算胜者，得算多也），只要在概要设计中将模块分得足够细致（每个模块的工作量不超过2天），将模块的处理流程描述清楚，并且将数据结构（数据库）的设计定下来，那么根据模块清单就可以很方便地将任务分到程序员身上，并且可以根据进度表对程序员的编程进行严格控制。概要设计做不好，那么所有的项目控制和项目管理，实际上都是空话。
在完成设计之后，项目才能铺开来由大量技术人员完成编码。在这一阶段，项目任务清单是主导控制文档，它也是项目任务的工作计划表。它是由概要设计的功能模块清单展开来的，同时列出每一个底层模块的执行人、执行时间。每一个模块工作任务的工作量不超过两天（大多数是一天），如果超过，那么就意味着设计工作做的不细。做这个约定是必要的，因为这就意味着项目经理可以对项目日程进行更为精细的掌控，可以更容易地进行任务的调配。
目前，我们在项目中主要是通过文档来控制进度，如项目总体计划表、项目任务清单、项目测试计划、测试用例清单等。而文档管理，最主要的问题是，文档具有阶段性，过了某个阶段之后修改起来就比较麻烦，特别是没有修改日志。而且项目文档与系统之间是有映射关系的，比如模块名称其实与程序中的类名、函数名有对应关系，数据库设计文档与数据库实体有对应关系，但由于先是文档编辑来完成设计，很难将WORD或EXCEL文档直接变化成系统的程序上，这中间都需要重复性的手工工作。而在编码阶段，实际上技术细节还会有很多微调，因此，就会造成程序与文档的不一致。这些问题，有时才让我感叹，如果有一个项目管理工具能够完成这些工作，那该有多好呀。
现在，各公司都在过CMM认证。CMM2规范（项目级的）和CMM3规范（公司级），都是很好的，对于项目管理机制具有很高的借鉴意义。但CMM关键的问题（或者说这是所有规范的通病）是，这些规范在实施中，可以说是考虑了项目控制的全集，因此不可避免地要求项目组生成了大量的有很大重复性的文档（因为要发给不同部门的控制人员），从而将非技术的工作量大大增加了。如果项目进度不紧张，倒也没什么，但很多项目进度很紧时，项目成员对这些反反复复填写的东西都十分反感，最终变成能不填就不填。而质量控制人员（包括QV 和SCM）在项目中则本身就是边缘人物（有些本身就不是软件实施部门的），对于项目组成员并不具有控制力，因此最终，项目管理规范就变成了形式。项目控制文档都变成了项目结束之后突击补充，失去了原来的控制意义。
我觉得，项目管理软件，重点要解决的应该是上述这些问题，就是说，要将项目中的重复工作变成软件内部处理的事情，所有的项目要素只要项目成员输入一次，而最终可以形成各样的文档，这不但是指重复的管理文档，对于技术文档可能更为有用。比如需求说明书、概要设计、详细设计的工作，都在项目管理软件上完成，并且由这些工作成果，可以生成用户要求的设计文档，也可以直接变换成程序或者数据库脚本定义（在数据库设计上用PowerDesigner或者ERWIN是可以做到的）。这样的话，在编码阶段，需求和设计的微调，就可以在原来的工作基础上体现出来，留下控制日志，而且也利于大家协同工作。
总而言之，无论是项目管理规范还是项目管理软件，都应该是为项目提供更好的工具，为程序员提供更大的便利，而不是所谓面上的流程规范化，实际上却是工作文档化和复杂化。只要能够让技术人员感觉到便利性，能够在项目中自觉使用，那么实施规范也就会潜移默化的建立起来。
因此，如果一套项目管理软件，不能将分析设计结果内嵌进去，而还只是文档管理，那还不如用VSS更实在。
这是我的一些体会，工作多年，胡子一把，经验不多，教训不少，有些乱七八糟了，希望大家多在这方面交流。
家园 这个还是很让我震惊的 但对于中小银行，实际上他们并没有能力做到测试，这就意味着功能测试的缺位，软件的质量只能由业务测试来检验，甚至到实际运行时去检验。这个到底要怎样验收啊？
中小银行也是银行啊。。。到实际运行去检验，出了事故应该算到谁的头上去？
太让我吃惊了。。。。
家园 我也很吃惊 当年在银行里工作时，做系统如履薄冰，改一个程序提交上去之前，反复测很多遍，然后上去之后还是会疑神疑鬼，都快得强迫症了。到公司之后，发现公司竟然让刚毕业的小孩子去做人民银行的现代化支付，而且竟然也没出事，这个也令我惊叹了。
错，是会犯的。但是去银行上的系统，也不是说乱写的。基本的流程还是要对的，而且也要在公司里进行测试的。正常情况下是出不了错，但是极限情况下还是可能的。交易量大时，极限情况可能出现，而中小银行，业务量小，所以程序走正常流程，出错的可能性不大。但是零星还是会出的，咱在河里写过一个系列，叫“银行的事故”，就是讲这些IT的事故。
去到银行上线的系统，一般都是经过几个案例的实际运行的，比较稳定。而新产品，出错的可能性要大的多。一般都会由公司派专人维护，出了错马上就改，银行去向客户追钱的事情，也是有多起。新闻里面，经常会出那些银行与客户的纠纷，很多是和IT系统有关系的。
家园 其实项目转产品,在实施这块的管理也是很纠结的 目前一个项目正在转产品.项目实施经理的缺少(不能把一线开发随便拉去吧）
这块不知道楼主大哥有没有想法。多个同质化但20%的需求不同的项目一起上线，一起升级。如何控制？
家园 多个同质化的项目同时上线这种还是比较多的。 比如人民银行要求上的大小额支付、银联2.0、身份核查，以及反洗钱、人行集中报送等项目，都是前几年某一阶段的重点戏。客户多的公司，可能同时开展20个以上的项目。细究起来，需求差距可以算是20%，因为主体部分是相同的，不同的只是接口部门（与银行综合业务系统的接口）。
对于这种类型的项目，公司是采用产品中心的模式来应对。在上线之前的预备期（3到6个月）研发产品，建立产品核心团队，后期在产品完成后，则开始通过培训建立实施团队。到实施时，将实施团队撒出去，每个项目多在2人左右，核心成员有时在实施团队中，有时是在家负责技术支持。然后在2个月时间完成上述项目的上线。核心成员一般既要保证自己的实施项目的成功，同时还要为其它项目提供技术支持，同时还要及时更改实施中发现的BUG，其中的辛苦那是大大的。
关于多个同质化项目的同时启动和上线，实际上专业金融产品（指以单一金融产品为主营业务）的实施商的技术运作模式就是这样的，因此这些公司是将上述的方式变成公司机制来运作的。比如专做信贷的安硕，专做网银的易诚（即宇信易诚的前身之一，国内网银的绝对垄断商）。他们都是分为产品部门和实施部门两个组成部分，到客户现场的实施团队（人数在4-6人），只负责收集客户需求和调试，而客户化编程的工作，都是由后方的产品支持团队来做的。
软件产品化的核心内容，是将系统技术框架平台化，然后尽量采用参数配置的方式实现业务逻辑。在这一产品化的过程中，在人员上会形成产品核心团队，在技术上会形成软件开发平台，项目的实施量会大大降低。在公司技术团队的支撑下，进入客户现场的团队人员素质要求会太大的降低。
长远地看，如果公司的某个产品拥有5个以上的潜在客户市场，都应该采用上述的产品中心模式。这个标准是很低的，应该说，只要是公司层面的软件产品，都会满足这个标准，也都应该采用这种模式。这也是我现在极力主张在公司组织架构上以产品经理制取代项目经理制的原因，实践起来，效果还是不错的。
现上轿现扎眼有时候会觉得有些来不及。但不管怎么说，多个同质项目上线，实行产品核心团队和实施团队相结合的办法，既是现实的选择，也恐怕是技术人员的共识。挑战也是机遇，以前也许因为各种因素无法实施，而面对危机时，大家总是会抛弃一些个人成见和利益的，倒是正好采用上述模式的时机。有这个开始，并按这条路坚持走下去，总会是一个不错的选择。
家园 完全晕倒 我不知道您是做什么金融软件的，但我也曾在这个行业混过饭吃
几个项目就没有100人以下的
最多的一个高峰时期光是测试就1000多个人
- 复 完全晕倒
家园 见到神了。 想问一下，是什么软件项目，在什么公司里做的，两联两天时代，还是四小龙时代，或者是现在。当然，如果是国外金融软件的外包，或者干脆是在国外，这个我确实不知道，我是个地地道道的土鳖，到现在也只是国内的金融IT领域混口饭吃。
到目前为止，真的还没有见识过测试有1000个人的项目，四大行的研发中心，好象也没哪一个有这么多的人员吧。即使到现在，金融领域软件员工人数能够到1000人的公司也屈指可数。我想不但我没见识过这么大的项目，河里的大多数人也没有见识过，倒是可以说说，让大家都长长见识，河里本来就是牛魔王聚会的地方。
百人以上的项目，在银行内并不少见的，很多省级银行的核心业务系统，项目人数都会到上百人。但这些毕竟是少数。我只是说大多数的项目人数，是在20到40人。我想既然是混金融的，也一定知道银行业（金融还包括证券和保险，不过除了证交所，其余的企业规模还是比银行小多了）有哪些软件和软件，列一下行业客户和要做的软件就知道银行软件项目是什么样的规模了。
银行的软件，目前主要分为几大领域，即综合业务系统（核心及总账）、渠道（综合前置、网银、ATM、CALLCENTER）、支付（银联、大小额、电票等）、报送（1104、反洗钱、金融监控、征信等）、管理软件（财务、人力资源、CRM、绩效、风险、资产负债管理、OA等）。而银行客户，除了四大行、13家全国股份制银行外，还有38家省级及中心城市商业银行，约114家二线城市商业银行，30家省级农信及10余家独立的农商行（这些数据，是去年做灾备中心方案时按省统计出来的，到现在可能有点偏差）。
银行的系统，除了综合业务系统项目人员较多外，其余项目的人数均在10到30人之间，这还是指省级银行项目，而区域性银行的项目，实施的人数多在20人以下，很多外围系统的项目人数甚至是在10人以下。
我想，啥观点都要用数据说话吧。俺一直认为，经历千人项目的人，都可以称之为神，既然有神的经历，何不说的详细一些。
家园 【讨论】很多观点心有戚戚焉 不过感觉楼主的软件开发经历还是比较局限于比较小规模的软件。我说一下我的一些观点，我其实项目管理经验很少，欢迎大家讨论：
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年以上，我觉得这样的项目都只会是一个失败的项目。
家园 到开发人员那边的任务切分越细越好 我以前设计做的比较粗,不做类图,开发人员是否按照设计来实现功能全靠自己codeReview,结果把自己累的半死不说,如果组里有人员变动,很多约定俗成的东西就又要再通过codeReview之后的会议形式再强调一遍(虽然有文档,但是真的会去看的实在不多),然后通过多次打回去重写,这样的方式才能完全纠正.
现在每次项目设计阶段我都让开发人员去做类图,然后做评审,等于一遍一遍给开发人员讲业务需求和设计思路,这样虽然在设计阶段会消耗比较多的时间,但是在开发阶段不容易出问题,任务切分也可以做的按小时计算,开发进度一目了然.codeReview也只要配合checkStyle,findBug,mi之类的工具再做抽查就可以了,基本能够保证代码质量.
家园 好的软件开发团队还是很重视需求分析、概要设计和详细设计的 在国内真正愿意沉下心来做开发前期的企业不算多，似乎国内做软件都是跟着项目走，真正愿意做产品化的不算多。
家园 做到类图级别可能需要花很长的时间了。 在项目实践中，我是这样理解的。如果只是做到模块清单，数据库设计、以及模块的IPO简要说明，这个可以称为概要设计。很多系统的概要设计可以由两三个人就搞定，而对于大多数公司来说，实际上能做设计的人也就那么几个，所以这种方式是比较切合当前的行业环境的。
在这个概要设计的基础上，可以将模块分给编程人员，由他们来完成类图的设计，然后再复审，这个我觉得可以称为详细设计。详细设计是项目中的重要环节，如果是一个全新的项目一个全新的团队的话，那么这个环节是不可省略的，即使详细设计的工作量可能与编码工作量一样多，也应该坚持，毕竟文档的可读性与程序不可同日而语，而更关键的是，详细设计是对编码的最好的约束。
不过对于大多数编程人员来说，完成类图设计是件苦差事，而且很多技术人员很不善长写文档（这还是锻炼少的原因），可能会要来回很多次还是不得要领。因此这个阶段往往要十分地花费时间。由编程人员分担的详细设计时间仍然会比集中由设计人员做的概要设计时间长很多，而由几个设计人员来完成详细设计，这工作量则大的不可想象。
因此，对于一个成型的公司和比较熟悉的领域，我觉得在项目中可以省略详细设计，而由编程人员直接根据概要设计开始写模块。这个方法的缺点是很明显的，就是上面说的，很多规范可能会被人忽视，只能再通过重复的编码审查来强调。但我觉得，这些缺陷，可以由下面两方面来弥补，一个是技术队伍的建设积累，另一个是开发平台和技术框架的积累。
微软的《快速软件开发》里那个盖房子的故事写的很经典，他深切说明了多年配合的重要性。开发项目成员，如果骨干成员是在一起共事了4、5年，那么很多规范已经成为了大家的共识，包括很多系统基础模块，都是大家平时一起做项目时，都共同研究确定的。而另一方面，软件开发平台及系统技术框架，实际上就是大家共同劳动积累很多年的产物，这个不单可以减轻工作量，更主要地是很多规范（即约定俗成的东西）已经被内置在平台里，在这个框架下做开发，实际上要求编程人员必须遵从相应的约束。
我觉得，只要有上述的基础，就可以不做类图（或者流程图），在概要设计之后，跳过详细设计直接进入编程。因为实施项目，主要是对产品进行客户化，必须在产品原有框架内完成。而产品研发项目的成员，多来自于实施项目的骨干，他们熟悉系统的框架，也有相应的业务知识。而在编码过程中，还可以通过不断地交流来将问题细化。
关于项目编码阶段的交流，我觉得也是一个关键的环节。而如何对待，实际上与公司的组织架构有关系。如果设计和编码是两个部门的话，设计人员一定会认为与编码人员交流是一件额外的苦差事。但是如果采用产品经理制，并以产品来划定部门的话，那么实际上设计人员更可能就是部门的高级经理，其本身既是编码人员的领导，同时还是编码人员的老师。在这种情况下，我想，尽可能多的在编码阶段进行交流，不但能够树立设计人员的威信，而且对于团队建设有很大的好处。
在企业组织架构里面，有明线和暗线两条，明线就是行政体系架构，部门科室，暗线则是技术传授，师徒门生。而由于IT企业的工作性质，实际上，师徒关系要比一般的企业里面更加明显地体现在上下级关系上。一个执行力很强的部门，一般来说，其技术负责人或者部门主管都同时也是技术灵魂。而这个角色，不是因为他职位高，而是因为在项目历练中，由他一手创立了技术体系，同时也带出了众多的徒弟。这样的部门，也许技术上不是最先进的，但肯定是最有效率的。
实际上，一只成熟稳定的技术队伍、一个积累了很多年的研发平台，是比项目规范更能决定项目的成败，当然这些领域都属于公司级的软件管理范畴，而不属于项目级了。
很多事情，受公司的资源限制，如果单纯在项目里面看，是无解的，成本压力在那里摆着，如果所有的项目都要尽善尽美地遵守规范的话，那公司铁定要黄铺的，因为支出会成倍的增加。这是老板不会答应的。但如果放在公司层面来考虑，确定产品发展路线和技术队伍培养计划，很多问题其实可以在不断的积累中加以解决的。
以上这些观点，可能是为不正规的软件企业组织方式在辨解，并不一定对。只是，在这很多年的工作中，所经历的公司，几乎都面临着同样的软件项目实施难题。而这些难题的解决，一种办法就是强化软件项目管理正规化，但这意味着成本的增加，更意味着要求增加公司的技术人员。实际上成本并不是不可解的，经过这几年的教训，很多老板对技术队伍的建设是舍得投入的，但金融IT行业，近十年最大的问题是技术人员的绝对短缺和大量流失，这是一个在公司层面根本无法解决的问题。所以只能走另一条路，就是从公司层面想办法，看如何能够在现有条件下走出一条生路来。
家园 中国的项目经理都不是累死的，而是郁闷死的