99年毕业一直做国内项目，一直在小公司做，过程中走了很多弯路，虽然积累了些经验，但也都是在小公司的经验，比较局限。2000以后对日软件外包兴起到现在，很多公司已经具备了一定规模，外资不断进入，对日软件外包已经成为大连的支柱产业。由于当时自己不喜欢学日语，也没往这个方向发展，后来发现自己的路越来越难走，虽然做过企业管理，物流，政府部门等相关的软件项目，但总感觉自己做的不好，而且做的做国内项目的小规模的软件企业生存非常艰难，自己所处的环境也越来越局限，于是想找个对日软件为背景的软件企业，学学技术及管理经验，于是2007年7月来到一家对日外包为主规模500人左右的合资企业，虽然仍然在国内部，做国内项目，但也能接触到对日项目的一些内容。工作了一年半时间，很想写这这段感受，想跟同行流交流。

目前我们做国内项目跟对日项目还是有很大区别，对日项目，客户基本指定了开发工具，甚至版本都有严格要求，而我们国内除了旧系统改造项目，对新规的项目我们基本完全有自主权的。众所周知，目前我们接触到的对日的项目大部分都是有式样书的，式样书基本都很规范，对开发工具，数据库版本，应用程序框架技术等都严格的标准，一切按照式样书的标准。而且我们接触大部分都不是系统的最终用户。开发人员尤其是PG基本知道甚至也不需要系统的业务功能，只需要知道从那个表里去数据，经过什么样的处理，然后存储到那个表里，至于这个表起什么作用，数据处理的目的什么？为什么这样做？这样做的意义是什么？不需要关心，复杂的业务都写在存储过程里面，PG只需要按照式样书调用即可（PM,PL大多也只是知道如何去调用，里面具体的业务，算法也不清楚），必须要按照式样书去做，即使是式样书有问题或不合理，也要按式样书去做，只要项目按规定的纳期那品，BUG率达到规定标准以下，万事就OK!，以后再也不用管了。，我们不断的过程改进，在CMMI管理体系下工作，建立障害系统，分析BUG产生的原因，逐步消灭bug,而客户大多很满意。其实这么做也没什么不对，最小的投入，最大的收益。而且我们本来做的就是Coding工作，很多公司就是这样做的，而且我们比很多公司做的都要好。

我曾经跟一个对日PM接触过，他说：他非常不喜欢做国内项目，太操心，系统老是没完没了的问题，客户老打电话“骚扰他”非常闹心，再让他干国内项目他就辞职，说对日项目每天加班，甚至经常加班到深夜，苦点累点没关系，项目纳品后再也不用操心了，没有任何负担，心情舒畅。由于工作需要，他做了一个国内项目，需求调研，系统分析，概要设计，详细设计，制造，实施，全过程的项目，并按期交付，但当试运行的时候出现了一个问题，有一个功能客户每天可能用几十次，几百次，用起来很不方便，用户要求改，但改动这可牵扯的内容较多，当然除了这个问题还有一些其他方面小问题修改。这个系统在coding前已经做了详细的DEMO,而且给客户演示了，开会演示，很多人参加，当时没有人对功能提出任何的异议。用的时候发现不方便了，因为客户在DEMO用户无法体验使用时的感受，有些问题也想不到那么深入。后来没办法，只能按照客户需求更改，之前版本都是经过我们严格测试的，也经过客户的测试了，但修改这个功能后，刚开始没什么问题，用户也比较满意，但到了月末，所有的问题都暴露，很多重要的数据都错误的很离谱，当初测试通过的部分，也都出现了严重的错误，最后系统不得不停止，这时候项目已经拖了好几个月了，客户开始认为是我们设计不合理造成的后果，我们也据理力争认为我们之前跟你演示了，变动是客户提出的，客户还算通情达理，给我们追加了一个人月的报价。这个系统是我后来接手的，我花费很大精力才将这些错误改正，最终正式运行，但到现在为止，这个项目还是会偶尔出现问题，都是当初设计的不合理造成后果，且这个项目当初签订合同竟然是验收后免费对应一年。这些状况直接决定了这个项目投入产出比非常的低。对日项目式样书本身都是经过我们的上游客户精心设计的，他们经验非常丰富，他们做的更合理，更准确，很少会出现上述的状况，而我们只照式样书做，不考虑系统本身业务，业务设计思想，只是关注技术实现，我们也不涉及到系统实施，试运行，后期保守的工作，纳品完后跟我们没关系了。可是，当我们做国内项目，虽然也仿照对日式样书的模式去做，但我们缺乏实际的项目经验，尽管也很规范，但却出现了这么严重的后果。虽然很规范，但质量却很差，后面我将提到本人对软件质量保证的理解。