Onsite和Offshore的开发过程的讨论

这里有不少做过对日或对美外包的，我想请教一下，你们谁是从上往下做的？就是谁做过一个完整的项目，包括项目管理，我指的不是指收到发包材料后的工作，因为我们现在讨论的开发过程是站在项目管理方的，不是其中的某一个环节。
希望有完整的外包项目管理经验的人可以对这种开发方式的组织和特点进行评价，其中的优缺点和注意事项不亲身经历很难说清楚。

不知道你的“完整的项目”是怎样的。做外包必然只是做软件开发中的一个环节，如果所有的环节从需求，系统设计，到后期的产品发布，维护都做得话，那就不能称之为外包了。

这个帖子的本意是公司内部采用类似于外包方式的分级方式进行项目开发，从公司的角度上看，“外包”也是公司项目组内部的事情，项目还是那个项目，还是要面对怎么去管理“整个项目”，我们要讨论的是一个完整的过程，对公司而言，它要考虑怎么发包，怎么做发包文档，怎么来对发包后的开发过程和质量进行控制等等，不能站在承接开发者的角度来考虑。如果是讨论发包后的承接开发的开发商的开发过程，应该单独开一个讨论话题。

我理解他的意思是有没有做过发包方。
软件子合同倒是签过，不过对于子承包商的控制是非常非常简陋的……
正式的发包方估计要问欧美那边的公司了。

不过我所知道的一家外企（规模不大），原来是在上海这边开了一家分公司，把它的部分编码工作分派给这边做，由国外总公司做设计。
但是今年开始，他们准备把部分设计工作也交到上海这边的分公司，因为这样做更合算……

这是什么公司？

去年十一月的系分的案例分析里就有类似的问题,里面的更加特殊,他们的"低端组"和"高端组"还不在同一个地方,最后因"高端组"的设计出了严重问题而且"低端组"这边因种种原因没能及时和"高端组"交流导致项目失败

如果这样处理,那如何才能保证设计方的设计没问题,"低端组"发现了问题怎么处理或者说"低端组"怎么来发现问题?

猜想项目内部充分的交流是不可缺少的应该

这样做的风险是：
如果项目很大，比如说上百人年的项目，则抽出总体设计组的做法是有的。总体设计组负责系统总体架构设计，子系统划分，各子系统开发组负责子系统内部的详细设计，以及开发。子系统间的接口设计是由相关子系统的设计人员以及开发组一起共同设计的。我说了解的国内最大的钢铁企业的ERP系统（超过300个人年）采用的就是这种方式。你们的项目有那么大吗？

但是，子系统的开发组为什么要称为低端组呢？各子系统开发团队和一般项目的开发团队一样，同样需要合理的高低搭配比例，也不是只有PL有经验就可以了。除非每个PL只带3、4个程序员。这就有点类似于主程序员制了。而且做详细设计的人怎么可能不了解需求呢？不了解需求怎么做详细设计？或者我们对“详细设计”以及“总体设计”这两个术语的理解不一样？

所以楼组公司的问题是：
1. 项目规模是否大到需要采用这种分组方式的地步？
2. 低端和高端组的命名不妥当，容易引起误解。
3. 要求“低端组”不了解需求的期望不合理。
4. 所谓“低端组”内部的人员结构，因为没有看到airbird给出具体的数字，暂不做评价。
5. 从airbird的描述看，他们仍然采用的是瀑布模型。瀑布模型的问题就不在此赘述了。而因为采用瀑布模型，以为负责总体设计的人在总体设计以后就可以拍拍屁股走人的想法更是大错特错。这只是做领导的一厢情愿而已。

采用Offshore方式的主要目的是降低成本。Offshore项目有其特殊性，如果不了解这种特殊性，最好不要盲目照搬Offshore项目的一些做法。其特殊性主要来源于：
1. 开发团队分处不同的地理位置（而且往往相隔遥远）。
2. 开发过程中的不同阶段可能由不同公司的人来做。
Offshore项目中的很多做法都是为了适应这两个特殊性的。

Offshore开发并不能提升项目的质量和降低风险。甚至，如果对Offshore开发的特殊性不能很好的理解，并采取必要的风险控制策略，反而会增加失败的可能性。

这个叫项目整体外包，一样算外包。

大胆断言一句，按这种组织方式，项目完成时间会比高端组单独完成项目要晚很多，项目质量会低很多。低端组开发人员在开发能力上也不会有多少成长。
我们的做法是通过核心程序员带领低端程序员分小组完成工作，个人感觉这种还比较可行些。