3.6做好工作总结 在项目进行的过程中，我们要不断去整理自己的工作情况和做好总结，这样以来，无论是在自己的技术还是其它方面，都会对我们有很大的提高，在长期的积累后，无论是我们个人能力，，还是我们的团队能力都会有很大的提高。 担当的第二个项目基本算是结束了，回头看来其中有很多的问题，今天总结一下。
由于是对日外包项目，所以难免要和日本方面有所交流，这个里面的套头可是很多的。外包项目，设计都是日本那边做好的，所以对于中国公司来说，这里面就存在对于业务的理解问题，同时还要面对设计书中大量各式各样的错误和设计上的缺陷。其实式样书和设计上有问题都是可以理解的，就算是微软也不可能一次就设计出完美的软件，但是对于外包项目来说，这些问题往往是很头疼的，因为一个小小的问题往往会浪费开发人员很多时间去分析和找寻错误的证据，等确定是设计问题后才能反映到日方，进而修改，在发过来，在开发，其中时间的浪费不言而喻。最恶心的是，日方的设计漏洞一堆，那么只能无奈的陷入式样变更的泥潭，这个对于外包开发来说是最可怕的。
说完对方的问题，自己公司的问题也不能掉以轻心。这次项目失败之处就在于开发的目的没有很好的定位，通俗的讲软件开发的目的是为了创造出一个能带来利润的产品，外包项目也是这样。但是，对于开发人员来说开发的目的在于能够提供给测试人
员一个合格的能测试的程序。我认为这点是十分重要的，因为只有能测试的程序才是看得见摸得着的。并且，对于项目来说，不同于产品。时间是固定的，尤其日本人那个让人郁闷的纳期，所以外包项目开发的目的就在于开发出能够测试的程序。 既然目的确定，那么在实现这个目的过程中要注意一些问题。从这次项目来看，一个问题就是程序是中日双发共同开发，并且日方开发的程序出于业务的中间部分。在这样的情况下，获取完成的业务程序是非常重要的，它是业务流制作的基础，是测试的保证。
还有就是在工作进度安排上，从业务的流程上来看应该大家共同从业务的初始程序开始开发，但是出于效率的目的，往往会安排一个人做一个业务模块，那么就出现一个问题，业务 数据往往不能在开始之初就进行制作。这个问题往往使得开发系统中、后部分的开发人员不能得到足够的数据进行单体测试，这个问题还有待于解决。 项目完成总结3
对于一个已经进场半年的一个小项目，回顾以往，总会有许多要耐人寻味的地方。
首先要感谢业主给我们这样一个平台，感谢甲方对我们的支持与信任!
项目工作完成总结报告
