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

我所经历的项目，确实是在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年以上，我觉得这样的项目都只会是一个失败的项目。