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

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