引:IT公司要想和国际软件公司接轨，或是按他们的标准操作，还是要多考虑一下公司自身的实力和东西方文化差异所带来的影响
笔者所在的公司经过多年的发展，软件利润颇丰，产品相对较多，文档也是五花八门，代码风格有80%还算相同。公司的技术管理者被不同的风格和标准规范所困，一直想做好编程规范、文档标准化和管理标准化。
公司以所在城市的最高工资引进一位高级人才张某，月薪相当于北京的1.8万。张某是个研究生，在国内非常知名的软件公司和国际知名的银行工作过，跟老总及几个技术管理者都非常熟。作为空降兵，他直接成为公司新签的近3000万元项目的领导者。公司希望以此项目为基点，开始标准化的管理。
张某来后，公司给予了最高的支持，基本上按他的提议和理念进行，让他管理整个团队。包括程序的界面风格、各种标准的制定、开发人员的招聘、相关人员的配合、数据库的修改、需求文档的规范、测试人员的流程等等，几乎所有的标准，都按他之前所在大公司的标准进行。
措施一：建立严格的需求文档格式制度。张某提出了一套需求文档编写规范，宣称公司主管技术的最高领导也决定采用这种模式，来重新编写所有的需求文档。他要求系统分析员按他所提格式重新编写需求说明书，于是系统分析员连日赶工，将所有的需求文档写出来，又按照后面提的要求将所有的文档独立成无数的小文档。
结果：新格式强调的是和系统的交互操作，非常类似于操作手册，每个界面都按增删改查的模式编写，搞得系统分析员竟不知道含有业务逻辑的文档该往哪里放，要重点强调的也只能用红字标明。
旧需求说明书中，原本非常简单的两三文字硬是扩展成了两页，公司领导后期也发现不对劲，将部分公用的提取出去，整理成一页。公司里，在IT界中享有颇高荣誉的系统分析员成了文档整理专员。
措施二：公司建立了严格的需求文档审查制度。系统分析员写出来的文档需分配给相应的开发人员审查，每个小模块一个人，然后全部的模块再由公司里最熟悉业务的几个人审查。需求文档有错的要在QA文档中记录，用Word提供的版本来管理每个模块的需求文档的版本，需求有错的文档修改后再分配给相应的人员，再提交给最熟悉业务的人员审查。如果不断发现新问题，就不断进行这个循环。
结果：一个月了，一个模块的需求还没有完成，由于文档太长，有些人看了半天没看明白关键业务在哪里；有些人看着看着就看晕了，读完了所有的文字后，竟忘记了自己读这文档是做什么用的。到最后，所有的人员看文档都要系统分析员到场，除了数据字典外，要指出他们关心的业务点在哪里，没有漏掉就好。最后，这件事情大家也就不了了之。
措施三：建立完整的测试用例记录文档。由开发人员编写此类文档提交测试，用例界面上要求在两个组件中录入两个数字，在第三个组件中显示两个数字相加的和；要求将各种情况都记录下来，包括A和B的各种字符类型的组合排列、空值、各种提示是否正确，还有各种操作是否规范及异常管理等。
结果：开发人员写个程序只需一分钟，写个文档却要花一天。公司还处于发展阶段，还没有到用钱来砸人的地步，所以这个制度只执行了三天就终止了。老员工根本就没理会过，虽然这个提议在某些时候非常有用，但可能还不适合国内的软件公司。
新官上任三把火，都烧了起来，只可惜火太大，烧得太快，一下子就烧完了。两个半月过去了，公司3000万元项目的需求文档重写了三次。重写的并不是业务逻辑内容，而是文档编写的标准和规范的变更，而项目到目前为止，一个字节的代码都还没有开始编写。
领导为他顶着市场部、管理层的压力支持他的工作。开发部因为以前的旧项目太多，每个人的手里都有无数的工作，而目前这个项目的需求有不少要重新讨论，乐得轻松。因为需求没有定下来，需求文档还没有完成，其他的工作自然优先。
这个局面，公司中下层销售人员早就骂翻天了，只是公司不是自己的，他们的话也不会传到公司高层的耳朵里，只能在茶余饭后骂一通出出气。
所以在国内，很多东西并不能盲目追求国际标准。虽然笔者所在的公司也明白，故而没有引入CMM之类，而是引进人才帮助公司达成标准化的过程，只可惜事与愿违，浪费了不少时间，也付出了更多的管理成本，还导致了市场机会的流失。
笔者知道，一些软件公司进入发展期后，都会开始标准化管理，其中不少大公司都以劳民伤财、不了了之告终。主要原因在于，管理者单方面要求标准化，而忽视了公司的资金和人员规模，忽视了员工培训机制，企业本身又急功近利。IT公司要想和国际软件公司接轨，或是按他们的标准操作，还是要多考虑一下公司自身的实力和东西方文化差异所带来的影响。(it168) |
