既然外包，就不会是把工作包分配给本企业内部的团队来完成，就是由非本企业的组织、企业、团队来完成，以正式合同方式来管理。

攻击2点：
1。每个公司都有自己的团队氛围和工作方法，如果把团队移出这个环境，团队的工作绩效会受到影响（PMBOK中专门论述了环境之于项目成功的重要性）
2。把外组织团队引入本公司，会对管理带来一些问题，比如成本算法，比如公司内部的敏感资源，比如在对比中导致员工可能跳槽。。。

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com

对方辩友提到"既然外包，就不会是把工作包分配给本企业内部的团队来完成"
我方非常同意.无论外包人员在哪里工作,只要是他来工作,就算作外包.这与我方提到的请外包到公司内部的观点不谋而合,毕竟只是地点不同,但活还是由外包方来做.

对方辩友又提到团队与环境的关系,不错呀.正是考虑到外包团队远离委托公司的环境与氛围,从而导致两者脱节的情况,我方提出将外包团队引入本公司内进行开发.古人道:近水楼台先得月.在软件开发的项目中,沟通成了主要的问题之一.将部分软件或者功能,一脚踢给外包人员,不再理睬,很难想像这能产生多大的价值.外包也是由一般人来完成的,他们不可能仅凭几份文档在短时间做出完美的软件.如果都是天才,为什么公司不去把他们挖过来?外包人员的工资,当然由外包公司提供,委托方仅提供场所与环境.

对方还提到了,如果不将外包团队引进公司,只要提供访问接口,其他封装.这是多么完美的理论,多么单纯的想法呀.将文档和接口冷冰冰的扔给外包方."你去做吧.做好做坏都是你,你就别在这烦我了."项目管理的含义难道就是将责任推出去,为自己明哲保身吗?我方不敢同意这一点,将外包团队引入公司,开通适量的权限,并且按实际重要等级将网络封闭,这样即可以使外包团队与我方的开发方向,开发风格,开发思路相吻合,又可以保证关键内容不会外泄.相比之下,这比将资料丢给外包方,是否更合理一些?

对方的逻辑真的让我方大开眼界,"抢劫要考虑身体是否强壮,要考虑带枪,但结论是不要抢劫."为什么不要去抢劫呢?对方是考虑到,抢劫是违反道德的.还是考虑到,抢劫是有风险的.最后对方给出的明确的答案:如果你不能控制风险,就不要做.对方的意思太明确了,抢劫就要算好时机,抢就带好枪,抢就抢个大款....要不就别抢劫.

我们不评价抢劫与外包的关系,就风险而言,对方是否混乱了一些事实?任何一本项目管理的书都是将风险进行分类,比如进度风险,质量风险,资金风险等等.而我方谈到的进度风险是影响项目的主要风险之一.但对方为什么却看不懂我方的文字,却认为我方提的是所有的风险?项目的高风险,会来自很多方面,因为它本身就是由多个风险组成.外包风险只是一种.作为项目经理,不会因为项目有风险就取消这个项目,这不符合项目管理的精髓.而是要通过一些办法来降低各项风险.本次辨论的前提,公司需要将产品或功能外包.这是前提,那么由此产生的外包风险应该如何处理呢?是否有一些方法将此风险降低一下呢?因为我方提出将外包团队引入公司,会降低风险.而不是对方臆测的因为害怕外包风险,就不外包了.如果对方总是觉得这个辨题是"公司该不该外包",那我方也没有其它方法来反驳了,那就开再一个论题吧.

外包,不是说将产品和时间限制交给对方,然后自己就万事大吉了,就等着收货.这是不现实的.举一个例子,在服装生产过程中,一件服装要经过设计,织布,染色,特殊加工,制衣等多个环节,一般的服装销售公司是没有一系列的工厂与设备,那怎么办?外包,将每一个环节都外包给其它工厂.然后呢?公司会派人"跟单".所谓跟单就是时刻检查外包工厂的进展,质量是否合格,是在监视对方的时间和精力的投入.如果像对方所言,交给外包厂,什么事都不管了.那你是省心了,如果工厂不能按时交货,如果工厂按货的质量有问题,那时再手足无措吗?

综上所述,我方的前提,我方的观点很明确.如果公司需要外包,那么引进外包团队是一项好的做法.

Steve

好像辩论的焦点在于，工作是让公司以往的人来完成的，一个观点是把这部分工作整体外包，所以，公司自己只用通过对合同/财务/进度/质量评价/验收标准进行管理。另一个观点则是让外公司的人员到自己这里和自己公司的员工一起工作。

我的观点是，
如果工作内容有明确的定义，自己公司也没有培养capability的计划，同时，有过外包管理的经验，并且有符合一定条件的承包者，那么，整体外包是一个选择。

我基本上是反对让外包公司的人来自己公司工作的。唯一的例外就是我们没有这样的skill，所以，请一两个专家，一个月pay上4-5万，但是，项目结束了也就bye-bye了。让外包公司的大量工作人员进入自己公司，在工作方式，企业文化上有很多的不协调的地方，所以，会给管理上带来更多的overhead。同时，在合同制定上也会有
更多的细节需要讨论。比如，在上班的时候，如果出现意外受伤，谁的责任，谁负担医疗费，等等，都要讨论清楚。

我们用事实说法
案例
某行业公司A正在开发一套行业ERP系统, 其中对一块业务M模块不是很熟悉, 于是找到外地一家公司B(小公司), B熟悉这个行业, 也特别在M这个模块系统上很有业绩, 做过很成熟的产品和成功的应用于其他的项目
于是A把模块M交给B来作, 也就是我们通常说的项目外包.
A有一下问题:
  1  B在外地, 交流不方便
  2  项目控制不能保证
  3  不能学习到M的内在(希望以后自己做)
解决方案:
  把B负责这个外包项目的人员进入A公司(5个人, 1个负责人, 3个程序员, 1个美工), B公司的老大也经常过来开个会就不列入人员之内了, 这些人也是B公司的主要人员了.
代价:
  提供吃住和出差补贴
时间:
  3个月(合同)
过程描述
  由于B的团队进入A公司, A就把B的看作一个自己的团队, 按照自己的工作作风要求B, B也是很爽快(也许痛苦)接收了这种工作方式(工作方式:封闭式开发, 每天夜里基本上都是到2点, 早上8点上班, 工作和休息, 吃在同一个楼上), 没有详细的设计文档, 没有严格的里程碑, B以来就忙于给A做其他的工作(比如协助开发其他模块, 整理M模块需求等等), 时间一晃三个月就到了, 项目是没有完成, 关键问题在A(A,B公司领导也都认可), A要求继续做下去. 合作也继续进行下去.
半年后
  A的M项目没有顺利完成
  B公司解散
原因
  A的M项目, 
    没有详细的需求和设计文档
    需求的随意变更和增加
    没有关键时间点的控制, 即使有也只是流于形式, 延期就延期了
    没有让B全身投入到M项目中
    没有考虑到B的人员感受, 经常听到, 你再不回来我们就byebye的声音(另外一半的声音)
    打破了B原有的工作模式和管理制度
    ............
  
  B公司解散, 不在我们这次讨论范围之内, 就不谈了.

这里的例子也正好印证了zhf_karen和camer前面谈论观点的正确性

如果:
    项目外包给B, 不引入B人员, 情况会怎样呢
推测:
    A至少会想法出一份需求说明书的, 其他的都可以交给B做, 毕竟B有丰富的经验和成熟的团队
    A会设置关键的点来查看进度, 从而确定是否按照进度进行.这个直接关系到费用的问题, B会权利保证进度的
    A的需求变更和增加也不会那么容易和随便. 这样会影响B的进度, 同时A也会好好整理需求了
    A不用额外付给B出差补贴, 吃住的费用
    A不用管理B的人员,共同的目标是模块M
    A的M模块至少不会到半年后还没有完成(三个月的计划)
    
    B如果没有按照需求说明书做出来, 也没有理由推脱
    B团队也不会解散

说明
没有特别注明攻守标志的认为是观, 这就是wml前面帖子是观方的由来.

修改: 刚才颜色没有显示出来, 先更正

我方也用"事实"说话.

B公司解散后,人员全部被C公司雇佣.C公司依然以这些人马做外包项目.考虑到A公司与B公司成员打过交道,因此重新与A公司谈判.A公司也吸取了前次的教训,将C公司拒之门外,仅将所谓的需求文档交给C公司.

由于A公司根本对M不熟悉,所开的需求文档不符合实际.C公司人员不愿与A公司人员沟通.然后在数月后,C公司交出了一份"符合"A公司要求的东西.虽然不能用,但A公司文档所写的东西,都在上面.而没写的东西,也没有出现...可想而知,A公司最终倒闭了.

我方也不用分析什么了.有兴趣的话,多编一点而矣...

Steve