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

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

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

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

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

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

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

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

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

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

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

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