2007年上半年实习总结（草稿）

  07年2月—9月在公司实习做了两个外包项目。一直没有写总结，今天抽了点时间先大致记录一下，以给自己以后的工作积累些经验。

两个项目都是外包项目，都是NEC发给我们的上游公司，再转包给我们公司的。

两个项目都是struts + jsp + eclipse + oracle + ajax。两者在技术上的区别只有在前段js的应用和后段的DB处理上稍微有点区别。第一个项目的js主要用于处理页面的输入控制，而第二个项目不仅处理输入控制，还大量利用了ajax技术。在后台DB处理的上，第一个项目利用了一个叫blend的OR mapping框架，在批量处理数据的时候使用了PL/SQL，而第二个项目只要涉及到数据的写操作，全部用了PL/SQL，这在技术上对我们的技术人员增加很大的难度。

第一项目是一个pos系统。我们做的是日本最大的石油公司的零售店系统的一部分。

这个系统的设计都是在日方做好的，设计书也算比较完善，所以做起来还比较顺利。由于这是我的第一项目，刚开始的时候进展较慢，但后面慢慢地就好了。

而且这个项目总共只做了两个多月。

第二个项目是一个会计项目。也是一个非常大的项目，其中我们公司承包了一大部分。

 

这里主要谈一下第二个项目的项目管理方面的问题。

1、 人员安排。

这个项目的新手特别多。项目组共有 人。1个项目经理（同时负责另外一个项目）；1个联络员，相当于项目组长，负责与日方的联络，整合代码，分配任务；其他10来个人就全都是写代码的了（在后期的时候从其他项目组抽调了几个测试人员）。这10来个即使人员，其中只有4个做个struts项目，其他人中只有一个对java比较熟，其他人也就对java入门而已。

于是项目组将这些新手分别分给了4个有过struts经验的人，平均每人分得了一两个。这样就把一个项目组分成了几个小组（事实上是没有这样的，只不过这里为了叙述清楚，这样表达而已）。这是一个很好的决定。可问题出在了后面分配任务上了。一般来说，每本业务都有一个难度，从1到5，其中5时最难的。我们分任务的时候是项目经理和组长根据组员的能力来定的，一般这样分配是没有问题的。但这次由于新招员工很多，而经理对他们的能力也并不是很了解，所以分配的时候工期估计得就会不准确，最后造成他们整天的加班。

另外一个严重的问题就是，分配业务的时候把几个相似的人物同时分配给了几个新手，这样造成的后果就是，他们都在等待对方把相似的业务现完成，然后自己可以少写点代码。但结果是这几个可能对这个相似的业务都不熟悉，结果造成这几个人都没有进展。正确的分配方法应该是把这些相似的任务分配给一个熟手和几个生手，这样有熟手带头，生手跟着做，从而使项目的可控性有所保证。

同时也不得不说一声，这次招到新员工后，没有时间进行培训，就放进项目组进行开发，极大地增加了项目的风险。

2、 进度管理

在开始的时候，给每个员工分配了任务后都有一个时间进度。但是由于新手的业务基本在规定的时间内完成，而且根本就无法预测这些业务能在什么时间内完成。一致一个月后，整个项目已经没有了时间观念。造成这个严重滞后的原因就是设计方每天都要更改设计书好几次造成的。这个问题后来终于反映到我们的上游公司那了，并使之把矛头指向了那三家设计公司。但我们公司在这个过程中与日方的沟通显然存在问题。如果能够早点把问题都确定的话，我们的开发将会容易进行很多。

3、 时间管理

公司有个非常不好的毛病是，每天下午提交代码后，都要由日方经过确认后，我们才能下班。而每次的提交都难免会有这样那样的bug，而我们的上游公司总是要求我们都改正确后，才能确认。而上游公司确认的人员往往只有一个人，这样我们这边的所有人都必须在公司等待他的确认而不能正常下班，在这个等待的过程中，我们的人员又不能干其他事情。对员工来说，这种无意义的加班是让人心烦的；对公司而言，也增加了成本。

所以，公司应该跟我们的上游公司沟通协商，我们当天提交的代码，他们第二天确认，确认后的Bug票发给我们，我们再修改。这样将会节省我们很多时间。

4、 任务分配

这个其实应该与人员安排在一块。这里主要说一下，当某些人的任务出现滞后的应急措施。在这个项目中，由于新手太多，而他们的任务大多无法按时完成，而且可能出现严重滞后。在这种情况下，组长总是把那部分工作交给已经完成任务的人去做。这样对已经完成任务的员工很大的消极作用。因为熟手在接到任务时，总是会按照安排的日程去分配自己的时间。本来在这种对日外包公司中，对每个员工的任务都是超过的。但熟手为了自己早点下班，为了周末能够休息，总是会不遗余力地完成任务。可能当熟手毫不容易完成自己的任务后，却发现还有更多的任务在等待自己。一次、两次，熟手的积极性就被严重的打击了。于是为了避免再接到莫名期末的任务，熟手们也就开始学着拖延时间……。而同时，新手们发现他们完成的任务如果无法按时完成，还有其他人顶着，这也在某种程度上降低了他们的积极性。

 

       总之，在公司实习的第二个项目让人心身憔悴。这个原因是多方面的。首先就是我们的管理存在问题，如上所述。其次，就是设计方的问题。这次的设计是由三个日本小公司分别完成的，而且设计和开发是并行的。这种开发模式，可以极大地缩短软件的开发周期，但对双方的沟通要求极其高。在这个项目中，我们都是n个公司（3个设计公司，n-3个开发公司）通过同一个上一个上游公司沟通，而这n个下游公司之间是没有直接沟通的。我们的上游公司与NEC公司沟通，NEC公司再与最终的目标客户沟通。

最终客户

NEC

承包公司

这样的结构非常严重的造成了我们的沟通不畅，在加上语言上的原因。致使有很多工作都是重复地一会儿改成这个，一会儿改成那样。主要问题大概如下：

1． 比如是否在每个业务块内使用公共文件，比如TMUtil.js, SMUtils.js…；

2． 日期和金额的显示格式以及检查的严格度等等；

3． 还有数据库的样本数据，以及数据字典在不同的公司也不一致，比如在某些公司的文档里显示帐目ID的长度为8位，有些又只有4位…；

4． 框架也确定。这个项目为了减少页面的刷新，使用了iframe。在刚开始的时候由于没有涉及到修改明细部分，所以没有发现问题。但在开发的过程的过程中，发现如果要修改iframe中的数据但却在主页面中修改时，无法获得iframe中表单的值。最后还要修改整个技术框架，这个至少造成了好几天滞后。

 

 

最后说一下，日本公司的管理。

毋庸置疑，中国企业和日本企业的管理水平基本不再同一水平。一个最根本的区别就是，对制度的执行力度。日企会对指定的制度严格执行，而中方企业则会想方设法使自己最快地获得效率。最终的结果是中国企业的短视行为阻碍了自身的发展。几个例子：日方一旦确定一个技术方案后，比如所用开发工具，所用数据库，所用服务器，以及所有软件的版本，都必须完全保持一致，还有开发的流程也必须完成保持一致。如果规定了每次修改代码后都要打包再运行，而如果利用插件可以不打包再执行，这样是不允许的。