中美两国软件开发管理的比较与启示

目前国内软件业中充斥着对模式、创意的顶礼膜拜，对流程、管理、量化的无视；认为软件工程师也是吃青春饭的，持续做技术没有出息，稍有成绩就考虑向管理转，非要弄一个Manager头衔才显得牛X；实际发现无论美国、还是中国，真正成功的软件企业都是关注创意的同时，也非常关注创意的实现过程的规范化，因为只有过程规范，才能真正保证创意的实现；

推荐一本配置管理的好书：《CVS和Nightly Build技术》，清华大学出版社，杨锦方等编著。

下面是该书作者杨锦方先生的序文，因为优秀的创意与产品之间隔着巨大的鸿沟，人员、技术、流程是连接创意与产品之间的桥梁，杨锦方先生的这本书，实际分享了非常有实际使用价值的工具与方法，值得一读。

中美两国软件开发管理的比较与启示     杨锦方

    在美国学习和工作期间，我注意比较了中美两国软件公司在软件开发管理和技术方面 的不同之处。下面以我在硅谷一家从事企业语音识别平台软件开发的公司工作的经历为例， 介绍我的一些观点。
    第一，软件工程师年龄和经验的反差。我工作过的是一家NASDAQ上市公司，公司 只有5年时间，但是近一半的软件工程师、软件项目经理和软件设计师都不算很年轻，并 有着5年以上的软件开发经验(不包括在校期间的经验)。其中部分软件设计师(software architect)更是年龄在35岁以上(有的甚至已经45岁)，有着15年以上的软件开发经验。 在开发过程中，这些软件设计师的经验成为公司的宝贵财富。他们在多年开发过程中积累 的大量经验、教训能够让系统在设计阶段就避免许多后来让人走弯路的事情。权威的软件 工程专家RogerS．Pressman在他的SoftwareEngineering：口practitioner approach一书中指 出，软件质量保证体系最重要的是软件项目刚刚开始的需求和设计阶段。反观国内的软件 工程师，绝大部分是刚从学校毕业不久，而且多半的软件工程师都定位在将来做管理者， 这样，经验无法积累，低水平重复的现象就在所难免了。
    第二，软件开发管理职位设置的差异。在国内，软件公司通常只指派一位项目经理， 由他全面负责单个项目的开发和管理工作。如果项目经理不是技术高手，手下的软件工程 师们就会有牢骚，如“凭什么你没我水平高，却坐着比我高的职位，拿着比我高的薪水?” 这使得许多软件公司雇佣技术高手担任项目经理。他们中许多人缺乏管理方面的能力和意 识，由他们领导的软件开发难以实现规范化和工程化。实际上，项目管理更多的是需要管 理技能而并非开发经验，而管理水平高的人大多数并不擅长技术，更有一些管理人员原来 不是受高等计算机专业教育出身，而是半路出家。在美国，我接触过的所有软件公司(或 者有软件研发部门的计算机、通信技术公司)的软件项目小组都设有两个管理者的职位： 软件项目经理(proiectmanager)和软件设计师(softwarearchitect)。软件项目经理负责小 组人力资源、激励、非技术方面的管理，并向上级负责。软件设计师负责项目的规划设计、 技术方案选择等并为此负责。就像项目经理有一个职业发展道路，从项目经理到部门经理， 再到总经理，甚至总裁一样，软件设计师也有其职业发展道路，从软件项目小组的软件设 计师到软件部的软件设计师，再到公司的首席软件设计师。我想大多数人都注意到比尔·盖 茨的头衔，是微软公司chairman和chiefsoftwarearchitect，也就是微软公司董事长兼首席 软件设计师。可以想见，首席软件设计师的地位也是很高的。在更大规模的软件项目中， 系统工程师(systemengineer)和测试部门是单独设置的。
    第三，开发管理应用软件水平的差异。美国绝大多数软件公司的软件开发管理应用了大量的先进软件，而国内的软件开发管理几乎是纯手工操作。本来，软件公司是为所有需 要软件应用技术和解决方案的行业提供软件，其中也包括软件行业自身。具有讽刺意味的 是，国内许多从事软件开发的公司为别人提供了非常有价值的软件，创造了很高的效益， 却没有意识到(或者没有决心)自己也需要投资购买或者自行开发用于管理软件开发过程 的软件。许多美国公司根据自己的实际需要，开发用于辅助软件项目管理的软件，例如， 著名的电信设备制造商朗讯公司的大型软件工程管理软件(Sablime)就是自己开发的；许 多软件工程师自己用脚本语言写小工具，优化工作流程，提高工作效率。本书的主题CVS 系统正是从一些软件工程师在自己工作过程中写的一些脚本程序起源的。在美国，流行的 脚本语言，如Peri、BournShell／CShell、Python、TCL／TK等应用非常广泛：而在国内，这 些语言应用十分有限。
    第四，软件开发流程的差异。美国水平比较高的软件公司软件开发流程十分规范，技 术文档和使用文档非常细致，量非常大。在大项目的开发过程中，各种各样的表格更是数 不胜数。按照一位经理的说法，是“所有的事情都有文档记录”。不仅如此，美国更有technical writer(技术写作师)这个职业，许多公司聘用专门的技术写作师完成部分技术文档和使用 文档，尤其是给最终用户使用的使用指南一类的文档，更需要专业水平才能达到实用和易 用。国内这方面的差距较大：软件工程师视文档为负担：项目经理本身是软件工程师出身， 更加没有动力实施这些规范；公司老总可能又不懂软件开发管理。于是低水平现状是想躲 都躲不掉了。
    可喜的是，目前CMM认证正逐渐地在国内流行起来，有越来越多的软件公司重视流 程。更重要的是，不把通过CMM认证作为目的，而是真正贯彻规范和经过实践证实有效 的软件流程。不过，对于许多规模小、实力不强的公司而言，CMM认证负担太重，而且 不一定实用。记得有一位中型软件公司的老总对我说，“CMM那些东西全都是文档，不管 用。”这件事情可以得出三个结论：一是CMM这种先进管理技术真正得到认同还有一个过 程，二是CMM的实用价值在一些管理阶段还不是太大，三是CMM可能的确需要进行适 当的改造以适合中国的国情。
    我接触过国内许多软件公司，这些公司中的绝大部分其开发管理的混乱状况让我非常 吃惊。我也一直听到这样的议论，“国内绝大部分的软件公司都是软件作坊，基础不行，软 件业怎么发展壮大?”我相信造成国内软件业落后的原因是多方面的，但是，我们的确需 要认真思考如何补上提高软件开发管理水平这一课。
    有人说，中国的软件工程技术水平低下和中国人的特点有关系。我认为这是无稽之谈， 是为管理水平过于低下找借口。在国外，同样是中国人做软件工程师，同样是中国人做软件研发管理，为什么他们做得那么出色，赢得同事们的尊敬?
    我接触到的中小型软件公司大部分都抱着提高开发管理水平的美好愿望，也有些公司在进行着各种努力。例如，CMM正在一些中、大型软件企业中兴起。但是，CMM流程模 型引入的代价很高，而且在水平很低的情况下过分强调CMM中的模型恐怕也没有太大价值。CMM的有效实施实际上是建立在强大的CASE工具基础之上的。
    我在美国软件公司的工作经历告诉我，有一些非常有价值，实施起来代价相对较低的 技术，能够帮助国内许许多多的软件公司走出作坊时代，进入软件开发流程化的阶段。这 就是我们准备写作出版“软件研发管理技术丛书”的主要目的。真切地希望这套丛书能够 为广大软件工程师和软件公司带来实实在在的变化。