Onsite和Offshore的开发过程的讨论

to:chengren

你说的PMBOK我不但看过，而且背过，不但背了，而且还通过了。

作为一个正牌的PMP，我相信自己对于PM还是有发言权的。

我之所以说那帮老总是出于恐惧，并不是因为“外包”这样的开发模式没有用，而是因为“仅仅是听说外包有用，就打算在自己公司内部模仿！”

所谓外包，在一切技术问题需要谈论之前，在一切管理问题需要谈论之前，首先需要谈的是法律问题！是经济问题！是合同问题！而这一切，当一个公司打算在公司内部模仿时，这都几乎是不可能的！

至于失败的例子，我也没听说近年来软件工程领域出现了“名为外包的银弹”，外包能够减少失败吗？不见得啊！

那么为什么那些跨国公司还这么热衷于外包呢？因为便宜啊！至少失败的成本要低很多的。要不他们怎么不在自己的公司里搞外包呢？

感觉大家的阶级观念太强了，应该是和受的教育有关系吧。偶感觉国外的公司一般是分工不同而已，很少有等级之分。老外做事情比较讲究逻辑性和形式化，这和他们的思维方式有关系。一件事情合理就可以去做，然后形式化为过程，背后有管理理论和经验支持。外包存在即合理，它有它存在的背景和约束条件。如果一味的模仿而管理跟不上会死的很难看。是否可以采用外包模式一定要根据公司的情况来定，。。。等于没说

其实楼主公司的问题是存在的，一个公司里面肯定会存在熟手和生手。而楼主公司领导的处理方式不怎么高明，分成两个组织带来的并不是效率，而是沟通的高昂成本，明显不符合管理思想，而且这样的组织结构如何应付变更也是个大问题。感觉他们领导是用腰部以下考虑问题。
通常可以采用专家组和培训组的方式解决问题，专家组是由全部熟手组成，可以全速评估工作进度。培训组附属专家组，由部分熟手和生手组成，有熟手帮带生手上路，折扣工作进度。这种方式即可以应付项目压力又可以迅速完成生手到熟手的过渡。 不用置疑，我们公司实践过，而且印象里xp的一个专家也建议这样解决此类问题

说没底倒是真的。算是效仿外包模式的一种尝试

外包的软件的的运作方式大多数是划分高低端的。职责划分理论上说有助于集中资源，提高效率，保证质量。但是有一个前提：业务模式固定，项目特点固定，架构固定。很多情况下，客户会要求你使用他们的架构，框架进行对方的外包项目开发，同时，严格的规范一直到约束倒你编码中的一个空格。即便不使用对方的框架或者架构，客户也会对你的开发进行严格的规范。并且，外包和承包方的权利和责任十分明确，即高端组的变动，必须走变动流程，必须对承包方负责任（追加费用）。所以，所谓的集中资源，提高效率，保证质量，这都是必须建立在规范的条条框框里的。
对于高低端组的问题：对于高端组显然要求很高，必须有很强的控制能力和总体把握能力，底端组的士气问题也是必须考虑的因素。更重要的就是两个组之间的接口，必须有足够的规范，文档来解决。

to partech：（我发现庄表伟的这种方式比引用好使，嘿嘿）

如果你希望你在做工作流产品的选择时候，你对市面上所有的工作流产品的细节都掌握，那我也实在无话可说了：）

（但在项目初期，谁也不知道这个技术是否有现成的可用。）既然是这个样子，我想更加为我所说的 贵项目的失败与 开发模式无关而与PM有关作了一个注脚吧？

其实如果你愿意更加详细的描述一下这个项目，例如组织构成，诸如项目经理、项目的设计开发人员、客户、老板等各个在不同阶段的期望与工作，以及该项目最后的总结等等，作为一个案例大家一起分析分析，可能比你我这样高来高去的放空炮，给论坛上的各位兄弟的帮助会更大一些。

最后，我非常赞同阁下所说的 选对人 的这种说法。我想任何的管理应该都是以选对人作为基础的：）

to 庄表伟:
向pmp实践者致敬。

我非常同意一点的是没有外包的银弹这种说法，至少软件设计不会因为外包而变得更简单（相反的是工作量肯定是增加了），但是同时如您所说，外包，确实让失败的成本降低了。

可是对于一个公司在内部按照可以做外包的方式去工作，由于其内部成本可能的变化不大，这样做的意义在哪里呢？那就需要我们看看是不是还有其他可以引诱老板作出这种决定的因素，不错 eway同志 其实已经给出了答案“建立在规范的条条框框”，建立起一套成本风险可预估的工作流程的框架，在这样的框架中，在项目紧急的时候，遇到进度问题的时候，可以通过向项目增派人手的手段解决问题。 我想这样的老板至少比让开发人员玩命加班更值得尊重。

请举一个项目delay了一个以上的里程碑后，通过增派人手后如期完成的实际案例吧

简单的问一句，兄弟你没有做过对日外包的项目吧？

我不是PMP的实践者，恰恰相反，我考出PMP之后，就再也没有回去过。

正是因为深入的理解，使我明白软件开发的项目，不能用PMP那样的通用项目管理的办法来进行。

……哪怕有人这么干了之后，成功过。

没，只做过对美外包……