措施二：公司建立了严格的需求文档审查制度。系统分析员写出来的文档需分配给相应的开发人员审查，每个小模块一个人，然后全部的模块再由公司里最熟悉业务的几个人审查。需求文档有错的要在QA文档中记录，用Word提供的版本来管理每个模块的需求文档的版本，需求有错的文档修改后再分配给相应的人员，再提交给最熟悉业务的人员审查。如果不断发现新问题，就不断进行这个循环。

　　结果：一个月了，一个模块的需求还没有完成，由于文档太长，有些人看了半天没看明白关键业务在哪里；有些人看着看着就看晕了，读完了所有的文字后，竟忘记了自己读这文档是做什么用的。到最后，所有的人员看文档都要系统分析员到场，除了数据字典外，要指出他们关心的业务点在哪里，没有漏掉就好。最后，这件事情大家也就不了了之。

　　措施三：建立完整的测试用例记录文档。由开发人员编写此类文档提交测试，用例界面上要求在两个组件中录入两个数字，在第三个组件中显示两个数字相加的和；要求将各种情况都记录下来，包括A和B的各种字符类型的组合排列、空值、各种提示是否正确，还有各种操作是否规范及异常管理等。

　　结果：开发人员写个程序只需一分钟，写个文档却要花一天。公司还处于发展阶段，还没有到用钱来砸人的地步，所以这个制度只执行了三天就终止了。老员工根本就没理会过，虽然这个提议在某些时候非常有用，但可能还不适合国内的软件公司。

　　新官上任三把火，都烧了起来，只可惜火太大，烧得太快，一下子就烧完了。两个半月过去了，公司3000万元项目的需求文档重写了三次。重写的并不是业务逻辑内容，而是文档编写的标准和规范的变更，而项目到目前为止，一个字节的代码都还没有开始编写。

　　领导为他顶着市场部、管理层的压力支持他的工作。开发部因为以前的旧项目太多，每个人的手里都有无数的工作，而目前这个项目的需求有不少要重新讨论，乐得轻松。因为需求没有定下来，需求文档还没有完成，其他的工作自然优先。

　　这个局面，公司中下层销售人员早就骂翻天了，只是公司不是自己的，他们的话也不会传到公司高层的耳朵里，只能在茶余饭后骂一通出出气。

　　所以在国内，很多东西并不能盲目追求国际标准。虽然笔者所在的公司也明白，故而没有引入CMM之类，而是引进人才帮助公司达成标准化的过程，只可惜事与愿违，浪费了不少时间，也付出了更多的管理成本，还导致了市场机会的流失。

　　笔者知道，一些软件公司进入发展期后，都会开始标准化管理，其中不少大公司都以劳民伤财、不了了之告终。主要原因在于，管理者单方面要求标准化，而忽视了公司的资金和人员规模，忽视了员工培训机制，企业本身又急功近利。IT公司要想和国际软件公司接轨，或是按他们的标准操作，还是要多考虑一下公司自身的实力和东西方文化差异所带来的影响。