超级战大爷日本软件工程师.docx

《超级战大爷日本软件工程师.docx》由会员分享，可在线阅读，更多相关《超级战大爷日本软件工程师.docx（82页珍藏版）》请在三一办公上搜索。

1、日本软件开发的度量取向根据意识：言而有据的诉求 判断基于事实，承诺源自依据。日本软件企业在软件开发过程中让人感觉到一种习惯性的根据意识：立足于数据而不是假设之上。规模估算、进度估算、成本估算、人员估算，都需要说明理由，而不是仅仅凭借经验甚至感觉作出判断；进度调整、质量评估、费用超支、人员追加，仍然需要提出变更的原因，不管这种变更是否对企业有利；项目意见、作业提案、选择建议、管理流程，都需要通过调查分析阐述各自的依据。尽可能排除直观感觉可能带来的误差甚至错误，通过切实有效的数据来反映事实状况，并通过这些数据来判断发展趋势，作到“言之有据”。因为面对客户的需求，不能主观随意地作出判断或者抛出承诺，

2、而没有相应的根据，否则顾客将会感到“不安”。这就是软件开发者的根据意识。根据意识源自危机意识，日本似乎与生俱来的危机感促使其在软件开发过程中尽量排除风险，而排除风险就必须基于科学的决策，必须拥有根据，而不是凭空决策。精度管理：敏感的数据倾向危险出在管理上，魔鬼藏在精度中。精度表现着对事物认识的深入程度，不管是软件成熟度模型，还是六西格玛，都表达着对高精度管理的诉求。日本软件开发过程中对精度的要求包括项目计划精度、工数估算精度、进程控制精度、缺陷统计精度、成本控制精度、品质控制精度等等，力求通过数据来描述和分析问题。特别是在项目规模、项目缺陷、累计工数、需求变更、测试和审查等方面，更加注重精度管

3、理，更加注重度量。以前，日本企业的规模估算等方面依赖于KDD，即勘(Kan：直觉)、经验(Keiken)、度胸(Dokyou：胆识)，但这种情况已经被基于数据和科学方法的精度管理所取代。数据敏感，具有较好的数据分析和判断能力，这已经逐渐成为现代企业管理者的基本资质要求。如果分析和判断建立在准确数据的基础之上，那么精度管理就获得了必要的操作依托。软件开发计划与实绩管理就是最明显的精度管理：精度意味着实绩与计划的吻合程度，如果实绩与计划相去甚远，那么其计划精度就存在问题。当软件品质中融入精度管理的时候，精度管理就成为与软件品质改善并驾齐驱的主线。可视作业：工具的灵活运用可视化作业能在作业的效率和质

4、量上给项目团队带来惊喜。日本软件企业在软件开发过程中注重作业过程中的可视化，追求项目成果的可预见性、项目问题的可追溯性、项目绩效的可评价性，利用各种软件开发工具来阐明现状、沟通思想、分析问题和团队作业，防微杜渐，通过新旧七大工具以及Microsoft Project等工具推动可视化，并在数据、图表、模型等的熟练使用方面拥有相当的根基。项目管理方面的“看板”就是典型。工具是用来处理其他事务的手段或器材。灵活运用工具解决实际问题的能力，对管理层人员来说至关重要：没有对软件开发过程的可见度就无法管理；而没有对事物进行适当的度量，也无法进行有效和高效的管理。软件工程的方法论主要在提供可见度方面下工夫，

5、从多个角度推动可视作业，对软件开发的绩效发挥着越来越重要的作用。 日本软件企业的开发管理概况一、日本软件企业的发展概况日本软件企业起步于上世纪60年代末70年代初。当时起步的绝大部分软件企业均源自母公司的软件开发部门。在80年代经历了一个平稳的发展期后，90年代初日本软件企业达到了发展的高峰期，不少现在的大型软件企业正是在这个时期急剧壮大，直至问鼎日本信息产业界。此后90年代中期，日本软件企业不断整合，涌现了不少经整合而成的”巨无霸”，YahooBB、富士通株便是其中的代表。近 90年代末期，日本经济大萧条，银根紧缩，日本软件企业为了保持或获取更大的利润空间，纷纷将开发业务转至海外。加之中国劳

6、动力便宜，地理上曾与日本依水相连，文化上与中国息息相通，于是大量日本软件企业纷纷涌入中国寻找合作开发商，使目前的中国对日软件外包输出呈现一片欣欣向荣蓬勃发展的局面。二、日本软件行业的特点日本软件行业从规模上说，体现为众多大型企业与小型企业竞相并存的局面，而非像中国以大多小型软件企业为主导的情形。 从分工方式上来说，大型企业主要从事上流设计（需求分析，概要设计，系统测试和维护），小型企业主要从事底层的工作（详细设计及编码测试）。大小软件企业分工合作，互补其短，非常有利于节省成本和提高效率，同时大家都有利可图。这与国内企业“一条龙”的开发方式显然大相径庭。有人不禁会发问：”为什么这么一个小国家有如

7、此大的软件需求”。首先从经济生产方面看，日本产业经济的高度自动化和信息化是一个强有劲的动力。其次在日本人观念中，行业软件的概念比较淡薄（社会上标准的被广泛运用的诸如微软操作系统这样的软件除外），量身定做的模式比较容易受到大众青睐。实际上，日本很多软件企业的盈利大部分来自系统维护、优化、改造等这样的售后服务。与之相反，这样的观念在中国却很难被客户接受。在日本，企业的终生客户比例非常高，因此日本的IT企业一般都有比较固定的客户群，因此企业营运相对来说也比较稳定。此外日本的软件企业一般都有自己的一套经过多年实践总结出来的开发流程和开发规范，在一般性的软件开发时按部就班地进行，做到尽量不出差错。相比之

8、下，国内的软件企业往往心高气傲，好高骛远，不重视平时的技术经验积累，因此也就难以作大成为大企业。三、日本企业的经营特点相对欧美企业而言，日本软件企业在经营上体现出下列几个特点：1. 盈利目标和利益分配：日本企业更加注重于产品的市场占有率，同时也比较重视新产品比重。在利益分配方面，兼顾股东利益、员工利益和社会利益的三者结合。从根本上讲，由于员工利益能够得到保障，所以在日本终生雇佣制能够主导日本企业的用人机制。2. 企业战略：日本企业非常重视营业资源长期累积，采取的是高质量产品战略而非新产品战略。不过最近几年这种战略观念开始受到冲击并逐步向新产品战略转化。3. 技术：日本企业一般从应用角度出发，技

9、术难度不高。企业不少技术均来自于模仿抄袭和改造。由于日本法律的原因，许多国外先进技术被日本企业侵权后引发纠纷大多只能草草收场。这在IBM控告富士通侵权一案上得到了突出的体现。4. 组织构造：日本企业的组织比较注重整体观念，采取有机的组织方式，很少采用事业部制。不过近年来，日本大中型IT企业的组织机构正在由原来的”职能划分”向”业务领域划分”转变。5. 组织方式：采用了不同于欧美企业的集体决策机制，集思广益，从而能够调动员工的积极性，同时也会出现”决策滞留”的低效率现象。此外企业内的所有成员共享企业的经营、技术等方面信息，对于欧美企业来说，这是比较难以想象的。6. 经营者个性：日本企业并不太看中

10、经营者的技术能力，拥有良好人际关系的员工常常被青睐并作为候选人员。技术能力突出的员工通常是作为顾问专家这样一种形式得到提拔。四、日本软件企业的开发组织模式非事业部制的日本软件企业一般采用的是”经营开发后勤”这样一个模式来从事软件开发。这一点跟中国国内的软件比较相似（图1）。但要指出的是这里的”后勤”范围很广，包括企业的员工培训和发展计划，系统审计，信息化，企业经营等，与国内不同，日本的大中型IT企业均设有信息推进部这样一个由专业技能非常突出的人员构成的部门，专门从事企业信息化、软件复用体系构建、帮助中心（Helpdesk）、人才育成体系构建这样的”后勤工作”。也正是”后勤”方面资金投入、建设力

11、度等方面的差距，决定了中日软件企业实力对比上的根本差距。图1日本企业的组织模式五、日本企业的项目开发管理日本企业的开发管理，讲究中规中矩，非常重视文档的规范化管理，力求做到”凡事必求有据”，体现一个”稳”字。下面以富士通SDEM（软件开发环境方法）为一典型，说明日本企业的项目开发流程。SDEM是日本富士通根据CMM标准，结合自身二十多年的经验提出的软件开发管理体系标准。它全面兼容CMM与ISO9000，甚至在某些部分超过现有国际标准，在日本享有盛誉并为众多的大中型IT企业所效尤。SDEM的要旨是以时间为横坐标，以文档为纵坐标。根据项目时间的推移，对某个项目阶段的需要进行的项目活动和书写的工程文

12、档进行定义，从而达到整个项目的开发管理。从形式上与CMM3较为类似。SDEM的理念是从不同项目干系人的角度（视图）看待开发。用户看到的是企业的业务和可系统化的对象（即现实世界）。项目开发着看到的是开发支援活动和项目管理活动（即电脑世界）。双方通过可交付的软件（广义概念，开发未完成时指的是文档）和硬件作为两个世界的接口，并在每个开发阶段得以定义和实现。随着项目阶段的推移，用户的业务和可系统化对象得到进一步细化和实现，这同时也体现了”由顶自下，逐步求精”这样一种开发思路。图2 SDEM视图SDEM分为五个流程，其中契约流程和组织流程贯穿于整个项目阶段。项目阶段包括分为企画、开发及维护三个流程。1.

13、 契约流程契约流程分为两个方面：购入和供给。购入流程是开发实体为了能够进行项目开发需要向”资源提供商”（包括本公司其他部门或开发小组）”购入”资源的过程。流程中涉及了资源（人、财物）申请提案、预算书和批准文书等文档。供给流程则是针对客户的提案、合同签订等应该进行的活动以及涉及的文档。通过上述两个流程的综合，项目有关客户、成本方面的因素便一目了然。同时也为开发提供了相应的依据。2. 组织流程组织流程则包括组织管理流程和系统审计流程两个并行流程。组织流程是企业针对该次项目开发实施一系列管理、开发支援活动。中间包括了事业计划、员工培训等内容。它的好处在于开发组只需专心开发，”你要什么，我就给您什么”

14、。从而减少项目管理者的工作量，同时在内部成本核算等方面也显得极为便捷。系统审计流程由独立于项目开发人员的第三者来进行。它的主要任务在于对所有实施阶段中的项目开发效率，开发进度，资源等方面进行追踪，然后通过书面报告的方式向项目管理者提出改善建议。使项目管理更加全面和高效地得以执行。3. 企画流程企画流程包括信息化构想立案（VP）和系统企画（SP）两个流程。每个流程均分为企画立案和项目推进两方面内容。信息化构想立案针对的是公司项目方针，项目间的计划过程。在这个流程里，公司的经营管理者对目前公司内的项目进行计划，调整开发组织结构。系统企画则是针对特定的某一个项目制订的方针、投资效果分析以及过去同类项

15、目的业务总结等。通过该流程，开发人员对即将从事的项目形成大体轮廓，并界定原有可复用资产（包括文档、人员、经验等）。SDEM的企画流程分别从企业级和项目级对具体项目进行早期统筹安排，强调整体效应，这一点非常值得国内借鉴。4. 开发流程与瀑布模型极其类似，富士通SDEM将开发流程分为系统分析（SA）、用户界面设计（UI）、系统设计（SS）、详细设计（PS）、程序编码（PG）、程序测试（PT）、集成测试（IT）、系统测试（ST）和运用测试（OT）九个环节。每个环节均包含业务、业务式样、应用、软硬件需求、开发支援和项目管理六个视图。每个视图与具体的文档或过程相对应，均以相应活动的完成或文档的生成作为视

16、图的里程碑。5. 应用维护流程应用维护流程（ME）再现了日本的终身服务理念。在日式软件开发中，应用维护作为软件开发流程的一部分也是最重要的一部分得以重视。系统一旦交付使用，将有专人会同客户，对专门人员进行培训、同时对系统的使用进行评估，提出评估报告，总结经验教训，并提出改善方案。较大型的系统在运营期间一般由开发商专人或聘人进行维护，直至系统报废为止。当然，维护费用还是比较可观的。实际上，不少日本IT企业营业利润的主要来源很大一部分是客户系统的维护和优化。图3 SDEM模型（V模型）六、日本企业的信息推进上面曾提到日本的大中型IT企业均设有信息推进部这样一个一级部门。信息推进在日本企业具起着极其

17、重要的作用。它覆盖了日本企业信息化的所有方面。企业级软件复用的实施，开发流程的改进。企业现有项目经验、技术的整理分类，根据企业和项目的需要会同人事部实施人才战略等等，都属于信息推进部的职责。信息推进部定期从各个开发和业务部门收集有关资料和信息，经分析处理后向各部门提出指导性建议或进行相关的人力或技术支援。在一些较小的公司，则成立信息技术推进室这样一个类似部门，由工作多年并拥有各种高级资格的技术、管理人员构成，直接由社长领导，共同对企业的信息化战略进行规划和实施。信息推进活动的实施，使得企业的技术和经验能够迅速的到提升和积累。对企业来说，它提高了企业整体的运营能力。对具体项目开发来说，它提高了项

18、目的开发效率，降低了开发成本和开发风险。从上面SDEM的例子我们可以看出，日本IT企业的项目管理和国内的管理从本质上来说区别在于一个”态度问题”。日式项目管理对涉及的过程和文档规定了极其严格的次序和样式，要求开发人员严格执行。从国内来说，绝大部分IT企业均打着软件工程幌子，在具体施行方面，开发人员往往是视而不见或是”上有政策，下有对策”。其次，日本的IT企业比较重视经验，技术等方面的积累，舍得花大量的人力和物力投入这样一些让国人感觉比?quot;虚”的方面去（即信息推进），这也是国内IT企业很难作大的原因之一太注重眼前利益而忽略企业长期发展的需求，没有积累和沉淀，因此很难发展壮大。日本企业的开

19、发管理模式，的确值得我们借鉴和学习。全球IT实力排名，美国第1，日本第2，中国第46 从下几个方面来分析一下： 1、软件方面中国和日本其实没法比较，中国的盗版业足可以摧毁任何开发人员的信心，除非是非市贩领域的专业软件也许还有些市场。 2、至于硬件方面，同属于制造业，这是日本的强项，IBM昔日IT行业的一家垄断就是给日立、富士通、东芝等几家日本公司瓦解掉的。 3、人才方面，这一点是日本的真正劣势，和印度小学要求乘法表背到20乘20，中国小学的应试教育相比，日本小学和初中的数学教育很差，如果不上私塾的话可以说数学就是一塌糊涂，这导致日本理科人才的缺少，而且相对于中国的大学来说，开设计算机系的学校太

20、少，这方面的专业人才不足，加上高龄少子化的社会问题，后续人才的培养基本上指望不上。日本的公司又是终生雇用制，大部分不愿意换工作，限制了人才的流动性。 东大，早稻田的毕业生大部分都进了日本的大公司，和所有行业一样，不管你多牛，新人工资20万日元左右。 4、市场方面，这方面资料数据没有，不好说，不过日本IT行业需求肯定不会比中国小。举例来说，日本某大银行采购软件的规模是以万套来计，每套几百万日元，这种活儿只有NEC，富士通等大公司能接到，然后倒好几次手才到中国公司。 5、在人才市场需求方面中国的问题是大学群立，大量开设了计算机类的专业，导致就职市场的相对萎缩，供大于求。日本恰恰相反，没动过电脑的人

21、进公司做SE这种事在中国估计要当笑话说的。这才需要从中国引进人才。 6、观念方面，在日本IT工作被分为技术职，营业职，管理职三种，管理职和中国的概念一样，营业职和中国国的市场部一样，但是技术职并非只会技术，而是分为上流工程和下流工程，上流工程就是去和客户谈需求，日本的客户估计是世界上最苛刻，最有个性的客户，在日本通用软件没有市场，各行各业的软件式样复杂，变更频繁，沟通极其重要。搞上流工程的人理解和表达能力要好，而且拥有多年的开发经验和某行业的业务经验。搞下流工程的就是咱们这边的技术人员，会写详细设计，会编码。日本人认为详细设计以后的工作是可以通过框架，规范，review，以及日本人天生的服从指

22、挥的天性来做好的，所以组织一群精英开发框架。 日本人的代码注释很详细，而且有履历，可以生成漂亮的javadoc（函数相关的数据表，属性文件，示例代码都有）。各个项目组靠javadoc在开发开始之前确认接口。 除非代码可以自动转换为容易理解的图形图表，否则文档就是不可缺少的，因为业务逻辑很难从代码中完全把握的。 7、虽然日本人普遍英文不好，但是他们集中少数英语好的人，专门翻译英文文档，翻译得很精准，日文版的jdk javadoc早就有了，中文版的似乎刚刚出来。日本的计算机书可能不如中国的种类多，但是绝对没有糊弄事儿的。日本的技术网站往往采用xoops或者pukiwiki，由一帮业余爱好者维护，重

23、复建设比较少，有利于提高教程的统一度和正确性。而日本的商业IT网站，都是聘请专家来做专栏。 8、日本网络速度快，可以达到100兆光纤到户，月额不过合人民币300元，硬件也很便宜，尤其是二手硬件，一台8成新二手刀片机也就人民币3000块钱，所以很多server爱好者都在家里架设服务器，这就给linux提供了生存土壤。 9，有一种说法是日本人不善于创新，说对了一半，日本人在计算机基础理论上是缺少创新，不过他们的强项是造物。理论可以学习，可以引进，但是要想生产出合格的产品并非那么容易，在这方面日本人的精细其他国家很难和其相比。德国人发明了莱卡相机，日本人研究了几十年，然后大规模产品化，现在全世界都在

24、用日本的单反数码相机。日本人认为中国人是最善于经商的，日本人之善于制造，只是由于制造的质量太好，所以用过的人不得不接着用，表现出来好像日本人很会经商。日本人对于自己的制造技术十分自信，前些日子日本航空公司的波音飞机出事，好多日本人都说美国货靠不住，还不如日本自己造。 随着日本新一代的叛逆，劳动力的减少，IT开发工作的乏味和加班，越来越多的人开始反抗，有人撰写了人月将使工程师越来越差，有人发明了ruby等等。传统的终身制被打破，满大街的招聘广告，求职网站如雨后春笋般冒出来。 现在中日的IT实力对比，有点像抗日战争时期，中国是内耗严重，装备差，环境设施差，信息封锁，人员参差不齐，有少部分黄埔精锐，

25、人力成本低，能吃苦，但是也容易跳槽。 日本则是装备精良，人员训练有素，协作能力超强，人员流动小，肯加班，每天晚上末班车的时候是人最多的时候。且由于日本维新较早，欧美的先进技术吸收了不少。 日本后边还有美国大哥罩着，凡是有美国版的，日本版立刻就跟着出来。敏捷开发目前在日本已经开始小规模应用于生产，日本ibm,日本oracle,ec-one等大公司表明态度支持。探讨如何提高对日软件外包开发的质量 一、市场需求调查 在全球化软件外包的大市场环境下，我国对日软件外包行业迅速发展。据统计：2008年第三季度中国软件离岸外包市场规模达到45.3亿人民币，同比增长19.53%，环比上升8.79%。其中，日本

26、仍是最大的发包地，市场份额高达51.6%，比第二季度的增长0.5%。通过数据分析可以得知，日本对华发包量非常稳定，全球范围的金融危机和经济环境恶化并未对该市场带来冲击，中国正迅速成为日本软件制造、服务的最大外包基地。但在这过程中，对日软件外包存在的种种问题也在不断的涌现，如何解决对日软件外包中存在的问题，提高中国软件出口声誉，成为了迫在眉睫的事情。二、对日软件外包的特点 1.对日软件外包注重软件工程，着眼系统分析与流程设计，重视各开发阶段的目的与成果总结，明确各开发阶段的任务。 2.对日软件外包有一套固定的项目管理模式与规划方法，对于整个项目管理，受主观因素影响极小。 3.开发过程注重“报告/

27、相谈/联络”，“报告”即下属向上司汇报工作进展，“相谈”即借助集体智慧来解决一些疑难问题，“联络”即加强沟通，避免重复劳动，节省开发成本。 4.项目开发的过程也是文档积累的过程，对日软件外包特别重视文档的规范化管理，力求做到“凡事必求有据”，各项工作均有文字记载。 5.考虑问题周到全面，对于任何可能出现的问题都有未雨绸缪的处理方案。 6.对日软件开发对技术的要求不高，但对质量方面却要求非常严格。三、对日软件外包常见问题 1.中日文化差异与思维习惯不同是对日软件外包中常见的问题。如：国内PG(编码人员)对日本SE(系统工程师)在设计书中写的习惯性问题理解常常出现偏差或日本SE认为理所当然的东西是

28、不会体现在设计书中的，而国内PG却不知如何理解设计书。 2.项目交货期双方可能会对某些BUG存在分歧。中方认为日方设计书表述不明确，日方认为中方理解有偏差。 3.某些国内PG的习惯做法就是，只对日方设计书上写明的才做处理，而没详写或没有提的地方就不会作相关处理。 4.国内PG日语熟练度普遍不高，导致设计理解缓慢，耽误项目开发进度。 5.某些国内PG做事不够细致，对细节重视不够，所以经常会在字体设置、TAB顺序、颜色、光标设置等方面犯低级错误。 6.日企对涉及开发的过程和文档规定了非常严格的顺序和模板，要求开发人员严格执行。而很多国内企业文档规范化管理观念淡薄，经常系统做完了只有源码而没有任何文

29、档，在具体执行方面，国内PG往往对规范和要求的遵守不能严格到位。 7.某些国内PG喜欢追求技术创新，在开发过程中对于一些技术问题采用自己的方案，导致部分模块技术实现方式与整体要求有差异，不能达到日方设计要求。 8.国内知识产权保护意识不够强烈，屡有客户信息泄露的情况出现。 9.中方软件开发团队队伍不够稳定。四、如何提高对日软件外包开发质量 1.加强日语学习 开发人员对日本提供的文档资料的理解程度对于整个项目的开发质量与进度有直接影响。很多时候对设计文档的理解偏差会直接导致产品质量不合要求，特别是在编码过程中，如果一开始理解有偏差，到开发的中后期会走很多弯路，造成整个项目不能按时交货。因此，可以

30、多组织日语学习，加强IT日语教育，开发人员至少要达到能理解日语设计书的水平。另外，可在整个项目的人员结构中加入日语专业人员担当联络窗口，由联络窗口来担任翻译，帮助理解设计思想。通过逐步提高日语水平来确保设计理解不出现大偏差。 2.双方加强交流 软件开发不同于其他行业，受开发者设计思想影响较大，需求与设计不确定性会导致设计与编码版本不断更替。比如，M公司的Y项目，日方最终提供的设计文档版本编号为11，每次发过来新版文档，都需全部重新理解一遍，同样对于编码与测试也要至少重复对应一遍。另外日本软件企业对外发包的过程中经常出现接单后再转包出去的现象，所以经常有项目经过了几层转包才拿到的，因此，在整个项

31、目过程中QA（品质保证员）的确认是非常必要的。特别是大项目，接包方与发包方更需要频繁联系沟通，在这过程中，信息经过多个节点的转送，很可能会有误读与理解偏差。而越大的项目，需求越不稳定，对于接包方来说，要一次性对所有需求分析透彻基本上不可能，再加上管理模式不一样，设计书的遗漏笔误，PG的日语理解能力较差等因素的影响，最终导致中国PG对项目的理解与日本客户或SE对于整个项目的设计思想很难完全一致。因此，在整个项目执行过程中，特别是中后期，频繁的交流沟通不可或缺，只有经过QA一问一答，才能不断修补程序，使产品最终达到客户预想效果。甚至可将中国PG派遣到日本设计现场协同开发，起到桥梁工程师的作用，同样

32、，日本也可短期派遣SE到中国开发现场提供技术支持。据了解：A公司就有3种对日派遣形式：一年以上技术签证、90天短期商务签证和一年内不限次数商务签证。同时，定期向日方报告开发进度也非常有利于日方把握开发进度与质量。在沟通方式上可以采用实时消息、语音、视频会议等多种方式进行交流沟通，充分利用网络，既保证了信息的实时传递又能节省开发成本。 3.加强对以往项目总结 通过总结以往对日软件项目开发经验，参考同类系统设计，可以积累出丰富的对日开发经验，这有利于理解新项目的设计思路，特别是可以积累代码库，避免重复工作，便于提高生产效率与质量。经调查，B公司在X项目中通过利用代码库中已有代码来构建新产品框架，开

33、发周期比以往缩短了35%，同时BUG率降低了25%。 4.建立文档体系 对日软件外包有个非常鲜明的特点：即文档非常丰富，从初期的需求分析到测试报告，都会有一整套完备的文档管理体系。如何有效的阅读与使用项目开发过程中的文档非常值得研究，因此文档管理体系的建立非常必要。对于每一天的往来文件与资料进行分门别类的汇总保存，随着项目开发的深入，也有利于对设计变更履历的把握与管理。同时，加强文档审核、翻译也是对日软件外包中要把握好的重点。文件的版本控制也可以采用如SVN（源代码托管服务）这样的版本控制软件进行管理。 5.把好程序质量关 强化质量意识。开发过程中严格要求PG按开发规约进行编码，有助于提高代码

34、可读性，便于以后BUG修改与进行代码维护。对于有SAMPLE代码参照或对实现细节有要求的，PG人员必须严格遵守，不得自作主张修改实现方法。在对日软件外包中有至少30%的时间专门用于测试，甚至在某些项目中测试与编码出现过1：1的时间比例，经验证明，很多BUG可以在测试过程中被发现。在对日软件开发中，日方通常都会提供一份TESTCASE，对于每一个可能会发现问题的测试项目都会要求进行测试，测试完成后对每一项进行CHECK，这样可有效降低程序BUG率。在开发过程中应要求完全按日方要求进行交货，包括提供测试结果物。还可考虑导入测试工具，如：BUG FINDER之类的测试工具，规范开发流程，加强代码审核

35、，导入CMM体制。以A公司为例，以往开发过程中的质量控制流程为开发准备编程机上测试单体测试结合测试（第一阶段）结合测试（第二阶段）客户交货。现在在单体测试与结合测试（第一阶段）的基础上加上测试结果复查，由其他开发人员交换检查测试结果。实践证明，在作业流程中加入复查项目后，对于整个项目的程序质量比加入复查流程前BUG发生率降低了20%。 通常对日软件外包测试过程包括：单体测试，结合测试，真实环境试运行测试。只有经过这几层测试后的程序质量才能有一个较好的保证。另外，有效的利用共通处理也有利于提高程序质量。同样一个处理，PG1与PG2的做法可能不一样，同样存在BUG风险大的问题，如果做成共通函数，再

36、由PG1和PG2去调用，由不同的人测试同一个程序，BUG的发现率就会高不少，开发的效率也随之提高。 6.加强知识产权保护管理 严格遵循商业准则，与客户及员工分别签订商业机密保证协议，确保日方商业机密及知识产权不外泄。C公司在这基础上还采取了机密文件定期统一销毁、病毒监控统一管理、电脑系统文件加密、服务器专人专职管理、门禁系统等多重方式来保证日方权益，确保情报安全。 当然，文中提到的对应方法，并不是适合每个对日软件外包公司。但总体来说，对于提高软件产品质量，提高生产效率，确保业务量应该是非常有帮助的。在目前全球经济不景气的大环境中，加强质量管理，提高企业竞争力，逆市而进，将关系到每个对日软件外包

37、企业的生存根本，质量管理不可谓不是重中之重。 日本软件开发项目管理的特点开发阶段明确化：界定软件开发阶段日本软件企业重视软件工程，重视软件开发流程的梳理，重视软件开发阶段的界定，强调阶段性审查和结束准则，要求各阶段结束时提交相应的成果物，如项目开发计划、外部式样书、概要设计书、详细设计书、测试式样书、程序代码、单体测试、功能测试结果报告书、系统测试结果报告书、限制事项说明书、提交一览表等等。软件开发阶段审核制基于软件工程、里程碑管理、质量关控制模式，在每个阶段结束时提交该阶段的成果物并对阶段成果物进行评议控制，尽早发现问题，消除隐患。其间使用阶段性成果物一览表(成果物)、开发阶段结束条件一览表

38、(结束条件)、阶段性审查标准一览表(审查标准)。其优点如下：(1)能使项目组了解软件开发的整体过程和主要任务;(2)能在较早阶段明确和发现问题，及时作出应对，消除风险;(3)能在较早阶段试用重要的机能，并通过与顾客沟通降低不确定性可能带来的分歧;(4)便于项目管理者进行进度控制、质量控制以及费用控制;(5)确保后续作业建立在前期作业的正确和成功之上，避免隐患的延续项目管理定量化：尽量排除主观臆断日本软件企业非常重视并努力追求项目管理的定量化，强调以项目度量、产品度量、过程度量等软件度量方式通过数据说话，对软件开发进行理解、预测、评估、控制和改善。这主要源于日本人在项目管理中的根据意识：凡事需要

39、根据。要通过有限的资源实现成本、交期、质量等目标必须避免浪费，在满足顾客需求、实现项目预期的各种方案和方法中，之所以这样而不那样，就得有之所以然的根据，即必须说明理由和依据。在项目规模估算、日程控制、质量评估等方面采用定量化方法进行判断、分析和评估，以数据、图表、模型等形式对项目事项加以描绘。软件项目管理中，不仅仅需要定性的判断，还需要定量的把握、分析和决策，以排除主观臆断可能带来的负面影响。作业过程重沟通：HouRenSou沟通模式日本的国民性植根于其团体精神之中。日本的管理采取“抬神轿式”的管理，通过合作协调谋求行动的一致性，实现团队的合力。日本人彼此信任，几乎没有秘密，因为秘密就意味着罪

40、恶。日本人之间，即使平日存在派系纷争，但一旦对外或遇到重大事件，便会精诚团结，集合众智，一致对外。“日本人好比一群小鱼，他们有秩序地沿着一个方向游着，一块石子投入水中，打乱了队形，使它们突然调头，朝相反的方向游去，而队伍依然是井井有条。”团队精神的枢纽就在于沟通。日本人沟通方面的精髓在于“报联相(HouRenSou)”，这也被视为社会人的基本沟通要素。“报联相”是报告(HouKoku)、连络(RenRaku)、相谈(SouDan)这3个单词的第一个汉字的日文发音，而汉语的“菠菜”在日文中的发音就是HouRenSou，所以姑且称之为“菠菜”式沟通。在日本，沟通交流能力在很大程度上要看HouRen

41、Sou：(1)报告：“向您汇报我的工作和活动”，就是把自己工作的进展状况随时通知上司和同事，并与之分享;(2)连络：“告诉您我预定的活动”，把遇到的问题告诉同事;(3)商量：“我想借用您的智慧”，工作遇到问题时，通过向同事或者上司咨询，以集体智慧予以解决。HouRenSou作为企业推进作业的润滑剂，能通过汇报和确认防范工作失误，获得来自他人的建议，构筑企业内的信任关系，发挥团队作业的综效作用，并进而强化与顾客的信赖关系。项目开发文档化：功底深厚的本领日本在软件文档的编制和管理以及作业记录方面可谓功底深厚，并在项目开发中计划相当的作业量投入。其文档特点为：注重文件结构，规范条理;注重详尽完备，没

42、有遗漏;注重使用图表、索引以及用语解释。不管是正式的发布文档，还是日常的交流文档，都能看出日本人在文档制作方面的耐心、细心和基于用户角度的良苦用心以及文档制作的规范性习惯。日本软件开发的文档主要包括：可行性研究报告、项目开发计划、软件需求说明书、外部式样书、概要设计书、详细设计书、测试式样书、测试结果报告书、限制事项说明书、提交一览表、用户手册、在线帮助等等。文档本身就是软件产品的一部分，没有正式文档的软件开发，就不是正规标准的软件开发。文档的制作过程实际上就是梳理思维、厘清事项的过程，对项目管理非常必要;文档化能力反映着项目开发过程的能见度能力;文档化能增进项目相关人员沟通的效果;文档化能将

43、以往项目开发工作的经验用于未来的开发之中。日本人还强调记录及时、充分、准确。这些记录包括：重要邮件、会议记录、审查记录、缺陷报告、测试报告、管理台账等等。具体而言，要求：(1)与客户和其他项目组的所有往来必须有记录;(2)对所有的活动都有一个跟踪落实的过程，比如对所有的审查记录和更改请求都进行标记，通过跟踪其状态来监督落实;(3)对所有的活动，包括对文档和代码的更改都会有历史记录;(4)记录都是通过定量的数值或者专业工具加以记录，强调以数据说话，比较确保项目的安全：未雨绸缪的对策可能来源于其根深蒂固的危机意识，日本软件企业在项目开发的安全对策方面总是持小心翼翼的态度，并从预防上采取对策：(1)

44、注重软件开发作业环境的安全，关注项目相关人员的进出制度以及项目信息的披露范围;(2)注重项目开发数据的备份，以及严格的审批登记制度，避免因为意外情形甚至不可抗力带来的损失和破坏;(3)注重病毒防范，采取严格的多重病毒防范措施，避免病毒感染可能带来的威胁和损失;(4)注重数据传输过程中的加密，防止信息被窃;(5)专人负责软件开发安全问题，全方位采取预防措施，并在发现问题征兆时及时报告，彻底清除存在的隐患。软件开发安全在没有出现问题时常常并不引人注目，但是一旦发生，后果难以预料。从预防上着手，这是确保项目安全的首要选择。关注项目管理者：成败系于管理者日本软件企业非常关注项目管理者的能力，认为项目管

45、理者是决定项目成败的关键人员，特别是比较复杂的项目，其成败更多依赖于项目管理者的知识、技能、经验和才干。作为软件开发项目的综合统辖者，日本软件企业认为项目管理者必须具备如下能力：(1)拥有软件开发项目管理的正确的理念和态度，而技术并不是最关键要素;(2)准确把握软件项目的开发流程、进展状况、约束条件、项目成员的能力;(3)确立项目事项的优先级并按照项目的优先级适当安排人员的能力;(4)严守交期的意识和捍卫交期的能力;(5)及早阅读不测事件的能力，以及将不良影响降低到最小限度的工夫;(6)与项目相关者的良好的沟通技能，包括与顾客、上司、项目组成员以及其他相关人员的沟通能力;(7)熟悉软件开发质量

46、保证并持续提升软件质量的能力;(8)软件开发过程中有条不紊的文档化能力以及富有根据的提案能力。准确、客观。外包开发专案的管理案例专案外包有很多优点，但最主要的一点也许并不是爲了降低开发成本，而是爲了解决企业内部人力资源的限制，使得企业不用招聘新员工就可以上马大型专案。本文作者在专案管理方面有十多年的实践经验，他将爲我们举例说明曾经面临的困境，接着条分缕析找到原因并指出解决方法。 一次失败的经历 在亚洲四小龙经济全盛时期，笔者在某公司亚太区总部负责该区的软体发展。爲了应付业务迅速增长所带来的需求，公司在各地都需要进行一些大型专案，包括主机的转换与安装、应用系统开发等专案。总公司要求我们把部分开发

47、工作外包，这样一来可以降低开发成本，同时也爲了能在这一段时间内保证有足够人力来完成专案。最後，我们决定利用公司本身的资源在区内各电脑中心内进行软体核心功能模组的开发，周边功能模组则实行外包。 我们选择了菲律宾和泰国这两地的软体企业来协助开发部分应用软体，因爲这两个地区有大批新兴的软体企业，所需的开发费用只是专案基线的四分之一而已。首先，我们对两地一些有规模的软体企业进行严格审核，包括对这些企业的技术人员数量、技术水平、财务状况、可靠性等各方面进行深入的评估，然後在每地选择一家从事外包。我们制定了有关程式的规格说明，然後把这些说明交给对方进行编程和模组测试。 当接到第一批交回的程式时，我们从测试

48、报告中已经发现结果跟我们的期待有很多不同之处。我们在进行测试过程中发现有些程式不能跟核心模组连接，更有些程式不能在主机上运行。我们除了对交回程式的质量感觉失望之外，更知道这会全面影响整个专案的进度。 建立良好合作模式 外包开发的软体不能达到企业的质量要求，我们往往会在第一时间把罪过推给外包商。但实际经验告诉我们，很多失败的原因是企业本身没有提供一套完整的软体系统规格说明、没有跟进开发的进度、没有定期与外包商沟通与协调、没有在开始时建立好质量指标和测试流程或者没有做出适当的技术和开发环境的评估。但最重要的一点，是没有在决定软体外包时处理好双方合作模式与关系的建立。 软件开发网 千万不要认爲软体外包可以减少企业的管理时间。相反，外包专案有时需要双倍的管理时间。在我们决定外包软体发展的时候，我们首要决定是整个应用系统的开发由外包商承包，还是只有部分应用模组的程式交由外包商编写。前者需要管理整个外包专案的生命周期，跟企业内部软体发展的管理没有差异，只是开发的地点、环境和资源比较陌生而已;後者则需要了解企业本身是否能提供优质的规格说明、是否能够提供外包商所需的质