关于两个外包项目的经验

转载自自己的旧space。



今年（2007年）因为导师的原因从同一家小外包公司那里接手了两份外包的工作。结果一个成功（至少在我这边看来）一个失败。总结一下还是很有好处的。
外包公司在美国，不过老板是中国人，真的很小，常驻员工据说只有7个人。拿到的外包项目通常也都是转了几手的了。第一个是在5月底接到的，历时一个多月。是一个用EclipseRCP开发的采集管理实时数据的应用程序。两个团队合作开发，一个在美国，一个在中国就是我和另一个在北京的程序员大叔。整个开发过程算是很顺利。虽然没接触过EclipseRCP，一边学习一边开发，但效果仍旧不错。在美国的Team拿到客户的需求，分出一部分来交给我们，之间用在美国的SVN服务器共享代码。那边主要负责底层采集等工作，我们四天，美国那边会发来新的需求说明，同时也会有以前功能的更改之类。就这样反复，到快暑假，基本上发给我们的功能已经都完成了，听美国那边老板说效果不错。
第二个是在暑假时候接到的，是用PHP为一个做房屋租赁生意的公司做一个网站。开发团队只是我们这边3个同学。当时说是开学前能做完，结果实际上到现在还有一大片功能没有做或者不明确。当时要做的时候客户发来一个网址说要duplicate这个网站做。结果上去一看那是个硕大无朋的全功能网站。过了一周多客户才来了详细的需求功能。其中间杂很多房地产界专业术语，很多都不明白。于是我们总结不明确需求发信去问。结果一封邮件过去半个多月一个月都没有回音。很久以后来了一个回音，是一些新的需求和文字修改之类，想来到现在我们第一次问出的问题有些还没有答案。于是很多需求我们只能猜测，完全明白的内容做出来只是很少的一部分，而且感觉也不能完成什么功能。直到最近那边客户才又来了一个长一些的回音，回答了一些问题，挑出了以前完成的一些不符合需求的功能。可是我们在学校的工作已经放不下，只好将项目转交回外包公司另找人做了。

总结这两个项目经验，想要记住几点。
1，交流非常重要。第一个项目中，我们和合作方交流非常频繁。不仅仅是大概每周的新需求。差不多每天那边都会有邮件告诉一些需要改进的部分，交流一些遇到的问题。而第二个项目的客户，接手将近半年以来总共只发过四五封邮件。无论是什么原因，这样的状态，一是让程序员感觉自己的工作对于公司来说并不重要，因而松懈。二也让程序员长期闭门造车，得不到客户的反馈而信心越来越低。
实际上说来第一个项目我们是有一点占便宜的。因为给我们需求的本身也是程序员，相当于客户真正的需求经过了一群专业程序员的过滤之后才给了我们。他们的需求非常明确，让人问不出问题。而且经常在需求中隐含某个程序模块就对应某个功能点。虽然这样并不算是传统意义上的好的需求，但必须承认效率很高。至少读过一遍以后，对于如何完成心中会有数。
2，语言。虽然第一个项目合作的团队在美国，交流都用英语，而第二个完全是我们自己弄，但成功的是第一个，说明国际合作，语言其实不是太大问题。第一个合作的小组其实组员也都是中国人。虽然发来的邮件中说的英语很有点Chinglish的味道，不过能读懂是没有问题的。而第二个项目中从邮件看客户显然也不是英语母语……不知是哪一国的“glish”了，非常的难懂。不仅是业务，很多基本的文字表述的意思我们都需要去猜测。这也是交流中很大的障碍之一。
3，程序员之间用代码交流是最快的。因为有SVN服务器的沟通，通过第一个项目也有了一点和远方程序员通过代码交流的经验。从项目开始我们之间就都可以看到对方的代码。在维持编码风格等问题上，还要费一番周折，不过有Eclipse这等强大的IDE的辅助，还是没问题的。开发中有一个事情比较有意思。中途我们遇到一个问题。我们的界面在当用户把Windows切换到大字体显示的时候好多文字就会显示不下，整个UI界面就崩坏了。原因是客户在最开始构建界面的时候应该是采用了一些可视化的编辑工具，UI组件的定位和大小都是采用的绝对的像素表示。实际上只要把UI换成手写的自动Layout，不限定大小就可以让UI界面可以伸缩了。我将我的意思和那边说了一下，后来就干脆自己动手修改他们的代码。因为大概有六七个相似的界面，于是就写了一个简单的UI框架，界面继承框架类，添加自己特殊的一些UI逻辑就可以了。代码提交以后发现那边之后的界面代码都采用了我这样的继承框架的写法，而且他们还很恰当的修改了我的框架类中一些不合理的地方，感觉很高兴。由此也应该记住。在团队合作开发的时候，尽量保持代码的简单易读，提供足够多的注释，是让团队能够顺利重用自己的代码的重要条件。