对日软件项目的一点看法 第一篇

对日软件项目的一点看法 第一篇
　
现在对日软件项目的数量正在急速的扩大之中。有在国内最
先涉足该领域的大连，沈阳等城市的一些企业。还有后起之秀
北京，上海，青岛，杭州，西安等城市的企业。对这些做
外包软件的企业而言，最敏感的恐怕就是汇率了。随着人民币
的走强，会打压这些企业的盈利空间。而人民币走强在长时间
看来是一个无法避免的事实。如何长期保障利润的持续增长，
是现在就要纳入长期战略规划里考虑的课题。
　
为什么一些早期就开始进行对日开发项目的公司成长到现在
遭遇了发展瓶颈呢？这些公司在达到一定的规模后，遇到了
不同程度的人员管理费用不断增加，业务没有办法进一步扩大，
没有自己的自主知识产权产品，员工的流动量加大等一系列
问题。虽然有些公司尝试着改变这一状况，但效果并不理想。
　
其实，这和对日软件项目的基本特点是分不开的。目前的对日
软件开发具有以下两个特点。
特点 1 就是很多项目的上流设计都在日本完成，下流开发在中国
进行。由于设计部分主要在日本完成。开发过程中，中国公司
无法培养自己的业务开发团队。这对于一个公司的长远发展是
非常不利的。而且这种上下分明的开发环境也很难留住优秀的
人才。
特点 2 就是对日软件业务的开发内容一般来讲都是一个大系统里
的小小一部分，而且都是以低层次的编码为主。由此导致公司
没有办法积累一个完整系统的开发经验。这里指的完整系统是
从客户调研开始到现场测试结束的整个过程。包括，硬件，软件
所有支持设备的运用调试。很多东西，如果你没有一个感性的
认识是无法理解其具体的操作内容的。
　
我周围有很多优秀的中国工程师，无论是基础知识和技术能力
都是非常优秀的。我可以肯定在这两点上绝对不比日本的工程师
差。但差距就在于实际接触过的东西和经历不一样。这方面的
距离是无法用其他的手段替代的。而且，随着时间的推移这种
差距会越来越大。
　
我曾经经历的一个项目，数据库的结构设计是由一名中国工程师
完成的。而且是通过了 Oracle 认证的白金级工程师。但开发到
最后的测试阶段，发现数据达到 3 万条时，数据库的操作速度非常
慢，要花费将近 30 分钟。逻辑上都是正确的但就是效率很低。在
查了问题的原因之后发现，原来数据库的设计书里把数据量很大
的 5 个表进行关联检索，而且是先把表联接后再进行条件检索。
我们把这段设计改成了先按每个表进行条件检索后再联接的方式。
结果平均检索速度提高到了 3 秒。当然有些条件下处理速度还是
很慢，但主要的条件检索已经达到标准。到了这个阶段也是没有
办法的办法。这并不表示我们的工程师笨，而是因为我们的知识
都是来自书本，没有经过实践的考验和吸收。为什么？因为没有
机会，而日本工程师则有机会从设计开始到应用进行一整套的开发，
并从中吸取经验，带到下一次开发中。
　
还有一次我到一个日本汽车零部件生产厂商的现场进行调试，我们
做的只是一个仓库的管理系统。但该现场的仓库自动化程度非常高。
很多测试手段都是我从来没有体验过的。可以用大开眼界来形容，
而这些测试手段，也肯定是通过长期的积累慢慢形成的。
　
以上讨论了很多对日软件业务的特点和问题点，我们如何弥补这种
客观条件造成的差距是一个亟待解决的课题。