对日开发-详细设计的经验

式样书项目总结

今天我写这篇文章，最主要的目的就是想让大家分享下我的项目经验，希望大家以后少走弯路。能给各位带来好处的话，那我真的是很荣幸。

其实各位，一看上面的题目就知道，我是做什么的了。不错，我就是想讲讲做日本项目的经验。现在国内对日外包一直是如火如荼，沿海城市纷纷提供优惠的政策，把一些的大的企业引进到自己的城市，都想在这个对日市场上分得一杯羹。在这样的大环境下，懂日语和技术的人才就逐渐的吃香了。

现在我就说下对日开发的流程。对日开发的流程基本上分为下面的几个阶段，全体计划，要件定义，基本设计，实装，单体测试，结合测试，受入支援等。基本设计分为概要设计和详细设计。国内大部分接到的都是实装，其实也就是写代码这一块。但是从整个软件工程学的角度讲，这个部分是最不值钱的部分。估计一个 100 万的项目，代码这块也就 30 万最多了。所以一般实力差不多的公司都会接详细设计，还有后面的测试以及维护的部分全部接过来。

其实，我做的这个项目是一个改造的项目，就是把 vb 开发的系统移植到浏览器上，用 java 做。我详细说说做设计这部分，公司当时接的时候把详细设计都接了过来。因为目前经济不景气，所以老板在预算方面做的也是很少的，成本控制的很严格。我们的详细设计是按照机能来分的，大概 90 本左右吧。刚开始是另外一个同事来管这一块的。但是这个同事有一点轻敌的意识。当时他说详细设计随便写一写，就可以了。所以为后来的失败埋下了伏笔。用了 4 个人写详细设计，其中 2 个是日语一点都不会的。用汉语写的。他说找翻译给翻译下就可以了。详细设计的模板也没有，这样写了一个月后，问题接踵而至。因为和日本客户的联络，还有一个日本的窗口。客户每次都来的时候，检查详细设计，都会提出很多问题。导致项目差点失败。做日本项目的朋友都知道，日本人对于任何事情都是很认真的，精益求精，要求很严格。尤其像详细设计这样的东西，客户挑的问题主要是写法上不同意。 例如设置焦点。 有的用的是 セットする。 有的用的是 設定する。 还有有效和无效，有的用 true 和 false 。全角数字和半角数字，标点符号的全角和半角，假名的全角和半角，句子结束时用句号等。其实这些东西在中国人看来，真的是没有什么的。例如全角和半角，看起来都是数字。但是实际上差别还是很大的。日本人都很仔细的扣这些东西。除了上面列举的这些以外，还有 excel 格式方面的，日本人似乎对 excel 都很精通，都是顶级的高手。因此对这个要求也很严格。例如打印的区域，头部，尾部设置，预览时的百分率，边框线，一条线有没有断线，对齐方式等。日本人都很严格。现在分析原因，首先不应该让不懂日语的人来写详细设计，虽然公司有翻译。如果翻译把每个人写的都翻译过去，翻译只是学习日语的，对代码不懂，在翻译的时候要花费大量的时间做调查，更多时候是找写详细设计的人员确认意思是否正确。这样的话浪费了别人的时间。原来的人写这个用了 1 天，但是翻译用了 2 天，这样翻译会很累，而且翻译的不一定正确，最主要的是还有写法上的不统一。这个就是一个最大的错误。另外 2 个人用日语写的，但是每个人的写文档的习惯和爱好不同，使用的词汇也会不同，这样写出来的东西也有差异。所以后来客户说我们基础的东西做的太差了，每次过来都是挑格式上的问题，根本没有时间看逻辑，项目的精髓所在。这样写了大约 30 本左右的东西就废掉了，造成了人员的浪费，项目的成本又增加了。

后来老板让我进这个项目，当时我就在想怎么做好这个事情呢。确实很棘手的问题。想让 4 个人写的东西都完全一模一样，是不可能的，他们刚开始写完在检查的时候都是用眼睛看的。人再仔细也有遗漏的地方，只要让日本人查到，指摘出来就是要扣钱的。很严格的客户。所以必须把好质量这个关口，这样才能出精品。得到客户的信任，和客户建立良好的信誉关系，为以后能接到项目做好铺垫。在这里我觉得有必要谈下关于标准化的问题，所有的日本项目都是，做之前先做好共同的东西，例如异常处理等，要写的格式完全一样，这就是标准化，这样做的目的就是为了便于以后的维护。假如过了几年之后，人家客户要升级系统，找到原来的代码和文档，查找起来也很方便的。我在日本工作的时候对这些东西是深有体会。好了有了标准化的概念以后，就要来实现这个标准化。首先第一步是做好模板，我们分了 7 个 sheet ，分别是表纸，画面，项目定义， jsp ，初期化，按钮处理，共同处理。然后在日语的书写方面我专门整理了一个文档。例如刚才说的设置，统一为 設定する。 数字全部是半角，句子结尾全部是句号等。对这些细节做了详细的规定。这样日语书写方面就统一了。但是这样规定了，后来的检查却是很麻烦的，而且很可能疏漏。这种情况下，我觉得工具应该发挥很大的作用了。因为都是在 excel 中写的，所以要使用 excel 的开发语言 vba 。本人对 vba 还是很熟悉的。根据客户提到的东西，我做了一个 checklist ，里面把需要检查的项目都罗列了出来。大概罗列了 150 多个项目，都是特别细的。这样的话从根本上避免了格式上的错误。例如检查句尾的句号，全角数字等。都用 vba 实现。每次同事写完后，直接运行我的 vba 插件，把错误查找完，然后自己改正。这样我再检查的时候就是看看有没有逻辑上的错，格式上的基本上是没有了。 后来客户来了后，发现再也找不到格式上的错误了，对本人很是佩服，一直说 すごい 。 这个真的就是工具的力量吧，减少了重复性劳动，提高了效率，最主要是节约了成本，以前检查的时候看一本要很长时间，现在用我的工具就 ok 了。这样我们交给客户的东西就是精品了，我算是为老板把住了质量这个关口。

各位，到这里文章就算写完了，其实我就是想说的是工具的力量，工具能很大的提高生产效率。磨刀不误砍柴工。各位以后做东西的时候，多想想用工具。真的我个人一直这么认为，虽然可能开始的时候开发工具的时间会长点，但是一旦工具完成后，它会使生产效率得到很大的提高。文章是个人的一点总结，有不足的地方，请大家多多谅解。

对日开发-详细设计的经验相关推荐

日企面试官谈赴日开发工作
如果不是被自己的公司派驻到日本,靠个人赴日开发工作有以下几种方式. 一,语言完全没有问题的话可以自己联系企业.但是大多数日本企业都比较保守,不擅长与国外求职者直接沟通.希望有第三方(人才公司)做担保才 ...
方维团购系统二次开发，项目经验
方维团购系统二次开发,项目经验基于方维团购4.2系统上进行二次开发在保留方维系统绝大部分现有功能下,二次开发内容包含以下几大部分: 1. 会员账号系统 2. 资金返现返券系统(代金券.账户余额.返 ...
有道云笔记蒋炜航：敏捷开发的实战经验
网易有道笔记负责人谈敏捷开发的实战经验:什么时候适合使用"敏捷开发"呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师:二.团队内有一名合适的Scrum Master. 作 ...
2019-安卓开发环境搭建-经验分享-Eclipse（主要内容）+Android Studio
2019-安卓开发环境搭建-经验分享-Eclipse(主要内容)+Android Studio 0. 引言 1. 常见问题 2. 配置安卓开发环境 2.1 准备 JDK 环境 2.1.1 下载 JDK ...
python2.7开发photoshop一些经验
python2.7开发photoshop一些经验开发背景原因:由于项目汇交的时候许多的成果需要转为pdf.tiff等,而且有严格的分辨率.压缩格式的要求,还要保证清晰度,因此许多的转换软件无法做到 ...
十余年软件开发经历，经验总结和程序一览（涉及Socket、WPF、vc++、CAD、图像、GIS）...
十余年软件开发经历,经验总结和程序一览(涉及Socket.WPF.vc++.CAD.图像.GIS) 前言本文主要介绍我开发的几款软件产品,大概介绍一下功能.可以让读者了解本人的开发能力,所擅长的方面 ...
UI设计开发移动客户端流程经验
UI设计开发移动客户端流程经验和pc端网站的设计和开发相比,移动客户端的开发工作,对绝大多数人来说,绝对是一个崭新的行当. 那么,当我们每天在iphone上,在各种安卓在各种pad上习以为常的 ...
京东运维开发工程师一面经验总结2020
京东运维开发工程师一面经验总结2020 自我介绍提问环节反问环节总结第一次面试,找的是实习岗位.做一下简单的记录.面试方一共有三个人.其中有一位是收我简历联系我面试的,另外两个面试的时候进行一 ...
蒋炜航：敏捷开发的实战经验
什么时候算时机成熟呢?我们的经验是需要两点:一.团队有三名或以上的研发工程师:二.团队内有一名合适的Scrum Master. AD:WOT2015 互联网运维与开发者大会热销抢票网易有道笔记负责 ...

对日开发-详细设计的经验

对日开发-详细设计的经验相关推荐

最新文章

热门文章