本项目是一个金融项目，基本上要求一周7天每天24小时不停，既要保证普通客户的交易的顺利进行，也要保证对银行交易的顺利进行。系统一天的负载还是比较均衡的，同时也是比较高的，需要一直从银行接收外汇牌价，同时要把这些价格经过加工发送给PC画面。

      项目所采用的技术语言是这样的，PC用的画面使用AJAX,手机画面使用PHP,连接部分使用Java（RMI），这些都没太大问题。问题在核心业务处理部分。客户现有一个VB做的处理系统，客户的想法是核心业务部分不做重新开发经过简单接口修改之后直接使用。我们讨论觉得Java和VB之间的通信实现起来虽然可能，但是VB不适合做这种高负载系统的核心业务处理，不如用Java重新写，同时我们也预想到了以后可能会发生内存，线程处理等一系列问题。（非常不幸，这个预想后来成了现实）

      但是，经过项目负责人和客户在一起讨论之后，决定使用客户的方案。理由很简单，成本控制。在客户可以承受的成本限度内，这个方案是唯一可行的。

我们也曾经把提高系统可用性的期望放在服务器架构的加强上。可惜，成本决定一切。这样的一个金融项目不采用集群来保证系统的可用性是我一直到现在都耿耿于怀的。

之后出现的一些问题都让我很后悔当初没有坚持让客户再稍微付出一点成本，即使再增加一台服务器也会让项目有很大改观。

这件事情给我的教训是一定要有勇气去跟客户进行项目上的讨论甚至是争论。最重要的是要用客户所能理解的语言将采用某种技术的利弊阐述清楚。同时要弄清楚客户最关心的是什么，将自己的视角首先和客户的视角调整到一致，然后继续延伸，在相同的视角下继续按照自己的想法去进行。
描述的比较抽象，简单说来就是一要站在客户立场考虑问题，二是要学会在客户的利益和技术架构之间保持平衡。

   本系统由PC用的客户端，手机用的客户端，核心业务处理逻辑，连接模块，对银行交易系统等几部分构成。人员涉及到最终客户，以及若干个隶属于不同公司的开发团队。但是规模不是很大，几十个人月左右。

   正式运行以后，有些具体细节还要进行微调整，跟客户的交流每天还在频繁进行着，客户的运营人员还需要我们的支持，基本来说项目已经结束了。但是下一个阶段的工作又排满了日程表，我们需要对自己的产品进行升级改造，功能扩充，架构重构，同时还有一个新的交易系统需要从需求开始设计。不过，低头赶路还要抬头看路，尤其是曾经走过的路。这是自己第一次负责开发管理工作的项目。所以，这段时间争取每天抽取一点时间回顾一下本次项目开发的点点滴滴，既做一个总结，又为下一阶段的工作打下一个良好的基础。

使用 Google 的这个服务，

可以将喜欢的新闻网站的新闻都集中到一个画面里面。

可以从这里检查 GMAIL 的邮箱情况。

可以管理自己的 TODO.

可以显示日历和时间。

还有好多，自己还没有一个一个试。

不过内容集中的太多，反而会显得凌乱，所以，还是简单点好。

我用的是日文的 Google ，配置完个人门户功能后，打开搜索引擎后，画面如下

往里面追加内容的画面如下

来到日本，我总喜欢去日本的书店，因为去一个国家的书店看看，就会大致了解这个国家的国民的素质和文化。

工作的需要，最经常去计算机书籍区域看看，除了看看有没有自己需要的书之外，更多的是了解日本的 IT 技术的现状和发展趋势。

这次主要客观的以介绍书籍为主，以后会谈谈我对日本 IT 业的认识。

我想分为两个部分来讲，书籍和杂志。

先说说书籍。日本的计算机书籍特点如下

1．  对新技术的反应比较敏捷。

感触最深的就是我刚来日本的时候，那个时候，国内还没有一本 Struts 的书籍，大家看的都是电子文档。而来到日本一看，书架上摆了 不下 10 种有关 Struts 的书籍。现在也是一样， Spring,Hibernate ， Ruby 等书籍的出版，日本都比国内要早一些。

2．  简单易懂。

这是日本的计算机书籍给我的最主要的印象，也是我喜欢读日本计算机书籍的主要原因。我总认为，如果真的掌握了一种技术或者知识，你就会用最简单易懂的语言和方式让别人也明白。在国内念大学的时候，曾经在学校的图书馆看到一本日本人写的介绍机器人书，当时丰富的图片和简单得说明，就深深地吸引了我。日本的计算机书籍作者基本上都是各个大公司的资深技术人员，他们写的书，简单易懂，很少有书籍是长篇大论的，基本上每本书里面都有大量的图表和例子，让人一看就懂，而且作为技术人员，他们知道读者最需要哪方面的知识，在哪方面会容易迷惑，会犯错误，这些都在书籍里面作为重点有所体现。同时，通过精美的彩色排版印刷，让读者读起来更舒服。最近买了一本介绍 HTML,CSS 和 javaScript 的书，它通过页面颜色的差别就能让你轻松知道一个 Tag 都被哪些浏览器支持。

3．  外文书籍少，翻译过来的书籍质量高。

普通的日本的书店里面基本看不到类似于国内的影印版的 IT 书籍，这里面很大的原因我想是日本人的英语水平比较低，他们直接读英文的书籍比较费劲，另一个原因就是他们日本人自己写的书，已经足够他们获取自己需要的知识了。外文的书籍，只能在大型的书店里面找到，而且都是原版，比普通的日本书要贵很多。日本也有很多翻译过来的书籍，但是与国内比较，普遍水平要高，我注意到，译者也都是一些大公司的资深技术人员，像日本 IBM 的资深架构师等等。我高兴的是，最近国内书籍的翻译水平也显著提高，前一阵回国，买了一本 JavaEye 翻译的那本众所周知的经典，读起来还是感觉很好的，另外 Ajax In Action 翻译的也不错。都是明白技术的人翻译的，感觉就是不一样。

4．  购书方式简单便捷。

在日本买书，除了书店之外，就是通过购书网站，主要的是日本的亚马逊，基本上今天网上订购后，后天就能收到书，付款方式多种多样，有货到付款，有信用卡结算等等。这些都跟日本的个人信用管理和物流的发达分不开的。

5．  涉及的领域更广泛

日本的 IT 书籍涉及的技术领域跟国内基本差不多，但是在领域知识和技术人员的教育方面，日本的书籍要丰富的多。在计算机书籍里面，领域知识是一个很大的部分，这部分书籍主要讲解的是作为技术人员应该掌握的领域知识，具体来说包括金融，会计，物流等等。而国内鲜有这方面的书籍，在日本，一个合格的 SE 必须是要具备相当的业务知识的，业务知识的核心，就是会计，好多日本的技术人员都有会计三级的资格证明。同时，日本人的观念里面，不懂业务就不会做出令客户满意的软件的，这一点的认识上，国内和日本还是有一定的差别的。在技术人员的教育方面，有很多讲解一个技术人员应该如何工作，如何学习新技术，如何增强自己的沟通能力的书。（我写过的程序员能力的连载也是来自于这种书籍，可惜那本书借给朋友了，还回来后以后会继续写下去）。我想如果中国也多点这种书籍，那么会对我们的工作有不少帮助。

IT 杂志

分类齐全，种类繁多，内容实用。

个人观点认为，在中国适合技术人员读的杂志只有 “ 程序员 ” 一本杂志，在日本，不论是从事的哪一个技术领域总可以找到属于自己的那个领域的技术杂志。从编程语言上分，有专门讲述 Java 的 “JavaWorld”, 有专门讲述 .Net 的 ”Windows”, 从操作系统上分，有 Linux 的杂志， Mac OS 的杂志和 Window 的杂志，从技术领域上分，除了编程语言，有专门讲述数据库技术的 ”DB Magzine”, 有专门讲述网络知识的 ”NetWork”, 从软件开发流程上分，有专门讲述架构设计的 , 有专门讲述需求定义的，有专门讲述测试的。另外还有各种综合性比较强的杂志，像 ” 日经 Systems” 。我现在正订阅它，所以我想重点介绍一下“日经 Systems ”。“日经 Systems ”里面每一期大约会有三个特集，涉及的有项目管理，开发现场的问题解决等等，同时还有 10 篇左右的连载，涉及开发现场问题的解决，新知识的讲座（ SOA 等等），新产品的试用和验证（例如， Hibernate 的不同操作的执行效率），领域知识的讲解（最近以会计知识为主），工作技巧（例如，如何开会，使用 MindMap, 管理时间）等等，还有一部分内容是会议记录，一些重要的会议的有意义的发言会列出来。更可贵的是，每一期总有一些案例，所谓案例就是介绍哪一个企业使用什么技术构筑了什么样的系统。总的来说，日本的杂志的信息量很大，从企业的管理层到下面的编码人员，总有一款适合您。

参加的都是工作中涉及外包开发的人员。大部分是日本人，有三个中国人。

讲师是在外包开发领域具有丰富经验的咨询顾问。

学习研讨会的目的，是知识共享，问题的提出和解决对策的研究。讲师讲课的时间和课堂讨论各占一半，气氛比较热烈。

这次研讨会的题目是“外包开发中的新的常识”，主要就最近在外包开发中出现的一些新的变化进行了讲解和讨论。信息的来源是涉及外包工作的一些热心者的意见。

本人参加的目的是进一步准确地把握日本客户的想法和正在苦恼的问题和扩大人脉关系。

现将学习内容总结如下。

1．  中方外包公司的变化

1.1   合作伙伴关系进一步强化。

1.2   技术实力和管理水平有很大提高

1.3   作为桥梁和关键角色的 BSE 依然紧缺

2．  日本对中方外包公司选择标准的变化

2.1 很多日本公司希望选择一个固定的合作伙伴

2.2 根据公司的人才水平进行选择。（日语能力，技术水平，品质意识等等）

2.3 对以往的开发成绩更加详细的进行调研。

3 ．外包成功经验谈

       3.1 Review 的认真实施

       3.2 开发流程的改善

       3.3 建立长期的合作关系。

       3.4 采用合乎实际的人才培养的策略。（减少员工的离职率）

4 ．一些亟待探索的问题。

       4.1 将维护的工作拿到中国来做。需要中方公司员工能很快的理解业务需求，并对运用管理有所了解。

       4.2 将 XP 等新的开发方式引入外包开发中。

1．  需求分析与提案。

日本的公司十分重视信息系统在企业运作中的作用，很多时候，他们将解决企业经营中的各种问题的手段诉诸于引进良好的 IT 系统。所以，现在的日本企业开发一个系统，更多的要求开发商能对自己企业所面临的问题进行分析，提出一个好的解决方案。所以，需求定义的出发点不是将现有的业务简单的用 IT 技术进行整合，而是使用 IT 技术来解决企业中的各种问题。开发商要能理解客户所面临的问题，并能提出解决办法，这种要求，是最近一段时期才提出来的，并成为一种趋势。

这个阶段比较重要的工作是分析客户的业务，进行业务建模，理解并发掘客户现在面临的问题，提出改进的模型，以及运行时的管理。

好像这些工作应该是咨询顾问来做的，但是，现在已经都成为对 SE 的要求了。（注意，中国人对 SE 的要求和日本人对 SE 的要求是不一样的）

提交的文档是需求定义式样书等。

2．  外部设计（也叫基本设计）。所谓外部，就是面向外部的用户的设计，不需要关心程序的具体实现。

包括业务流程的定义，架构的划分，数据库的设计（ ER 图和数据字典等），画面的设计（画面的布局和迁移），对外接口的设计等等。

提交的文档是外部设计式样书等。

3．  内部设计（也叫详细设计）。就是程序内部的设计了，根据外部设计的成果物进行设计工作。

根据架构和数据库设计以及画面设计，进行具体的功能划分，物理数据库的设计，算法的设计，输入输出的设计等等。

提交的文档是内部设计式样书等。

4．  编码。

良好的编码风格和注释都是必要的要求。对单元测试的要求，各个公司不一样，但是或多或少都做一些，只是程度不同而已。

5．  系统和综合测试。

6．  运行。这里面涉及到运行管理等跟客户业务密切相关的问题。

面向对象的一些开发方法，也都可以在这些不同的阶段里面找到自己的位置。像用例的设计就可以归到外部设计阶段。

总的来说，日本企业很多还是以瀑布开发为主。这里面的原因有很多，一个是比较好管理，一个是日本人都比较习惯了，改成别的开发方式，很难习惯。但是，由此产生的弊端，也显而易见。所以，很多企业也重视起来迭代开发，并不断尝试。同时，日本一些比较著名的 IT 企业像日立，富士通， NTT,NEC 等都积累了一些自己的开发流程，他们对 CMM 到没有什么过多的追求，很少看到哪一个日本企业炫耀自己通过了 CMM 多少级。他们认为，自己的管理流程和要求似乎比 CMM 更好，更严格。

测试啊测试，真的很有挑战啊！很多人都认为测试没什么，可是笨寻思一下，测试高手同时也是技术高手，因为不可能做完所有的测试，更不要妄想，所以他一定要明白系统会在什么地方出毛病，哪里有风险，哪里就是重点。