关于"ソフトウェアの品質革新の進め方"一文的读后感，原文为日文，本人日语水平有限，所以翻译的内容加上了自己的见解，
会有和原文的不同请见谅和指正。
读后感是本人对于原文中提出问题的个人想法，会有不对的地方，也希望和有见解的朋友多多交流。
原文很大，我只列出原文一些有代表性的地方，如下是第一部分。dskra@博客园
1、 日本－中国Offshore开发的品质事例和产生问题
事例・・・从日本方面看中国Offshore开发的暴露的种种问题
-----------读后感--------------
事例中的整个问题为：
1. 式样变更实现的漏洞过多，期待的实现总是没有按照自己的方式实现，作出的程序没有用处。
2. 通过电话会议断断续续的探讨出现的问题。是问题的话，在[式样书第N页的XXX处记载过XXX]。XXX可以在什么时候作完，XXX在DD日期不能完成。
3.最后由日方领导访华后磋商后解决问题。PL接受全部的变更，调整其他子系统的纳期，总算开始问题的调查和修复了。经过详细的调查是其他子系统的逻辑处理的地方，在全系统有多数的业务常识和业务处理步骤的误解，错误的起因暴露了。因为达成协议，日方开始全系统的测试，业务问题几乎全部误解。在中国，进行一个一个误解的说明和实施方法的变更。
本事例主要暴露的是项目沟通障碍而出现的问题和最糟糕的解决结果。
在事例中可以发现开发PL对于日方的式样理解出现了偏差，越到制作的后期偏差越大，最终达到到无法解决的状况。
出现这种情况最后只有两条路可走：
1.项目暂停 (项目完蛋了)
2.找出式样理解错误的所有机能，重新理解、重新制作、重新测试。 （双方产生信任裂痕）
项目一般都是幸运的，经过双方领导的协商（技术方面，商务方面），选择了后者。
为什么项目会出现这么严重的后果呢？问题出在谁身上？
首先是因为项目PL对该系统的业务流程没有充分理解，造成后期开发过程中的偏差。
其次是问题直到无法挽回后，双发才开始正视问题，解决问题。
一般情况在一个项目中，客户需求和式样编写、DB设计都是由日方的1名SE来负责，中方会由1名项目PL对式样和技术进行总体把握的，所以项目的成败主要取决于他们的工作素质，工作态度和工作策略。
由于语言和文化的障碍，SE和PL之间的沟通有一个很大的挑战，如何才能让他们对项目的理解，思路一致呢？在项目组中，你说的每句话，你的组员100%听懂了吗？100%按照你的想法执行了吗？一般会有一点问题吧。中文沟通都存在分歧，何况是和你完全不认识的日方沟通呢。有经验的PL会通过积累的项目经验和对SE的长期合作配合来解决。但是如果你遇到的是一无所知的新领域，接触的也是从没有合作的新SE，这该怎么办呢？按照过去的开发经验理解新的专业领域和业务流程？不懂如何和没有磨合期的SE沟通呢？他明白你问的问题吗？他回答的问题你明白吗？SE的式样设计就一定对吗？你的式样理解就一定对吗？复查，有没有人或方法来对沟通的结果进行复查，来保证式样和实现都向着好的方向进行呢？有没有对专业领域和业务流程的短期培训呢？PL和SE对于专业领域和业务流程的认识越接近，业务处理的思路就越接近，所产生的问题就会越少。不理解的东西一定要想办法搞明白，整体的业务流程要顺畅，其中总会有些复杂的逻辑处理在编写式样时表述不清或者表达的不全面，一定要在开发前或开发中把式样中发现的问题和式样遗漏的事项提出(通过邮件，网络会议)，并由双方通过文字确认问题的处理结果。我想如何还有遗漏的问题话就属于双方共同的责任了。
当然以上指的是SE和PL都是高手的最理想情况，很多时候日方的SE或者中方的PL在现实都是存在自己不擅长的领域，在遇到问题的时候该如果处理呢？
首先寻求自己亲友团的帮助，可以是项目组的成员，公司的牛人，网上的求助。总结出几条后向对方提出解决方案，供客户挑选。
(绝对不能发信说“在开发中我们发现了下记问题，您看怎么办好呢？”，这是不符责任的表现，不到山穷水尽我是不会说的！）
有的时候客户也会给你几种解决方案，让你挑选看你如何挑选了。
提案时大多数人都是站在自己的角度上考虑问题，对方不一定会接受。想要让对方接受的话一定要站在对方的角度上考虑，找到这么做对对方的好处。
一般情况日方的提案比中方的提案更容易接受，谁叫他们是客户呢，占主动权。
好了就说这么多了，开发中遇到的问题也是多种多样的。有些问题也是难以避免的。
总体上我觉得中方出现再大的问题也是可以解决的，反而如果日方在式样设计上发生了大问题，那么就是大问题了，甚至可以导致项目的流产。
(我就遇到过由于日方能力不足，而导致纳期一直延后，发生了关联很大的需求变更，最后1个月的生死加班大战，项目完蛋)
日本人也是鱼龙混杂，有高手，有庸人的。遇到庸人的话，项目就会很累、很累……