对于外包出去的项目如何进行管理？
对于外包出去的项目如何来管理呢？需求和概要设计是由我们公司来做的，详细设计还不一定，但编码一定是由外部公司来做的。对于这样情况的项目，如何来进行管理呢？主要是如何进行代码评审？是关键代码进行评审而普通代码进行抽查吗？还是有什么好的办法呢？而且这个代码评审的频度通常是多少呢？还有就是对于这样的一个项目是不是自己公司的测试团队对其进行测试会效果好一点呢？这样的项目如何来进行配置管理呢？:) 问题比较多，希望大家帮忙回答！谢谢！ 原帖由 xsnzhq 于 2009-1-4 17:08 发表 http://bbs.51testing.com/images/common/back.gif对于外包出去的项目如何来管理呢？需求和概要设计是由我们公司来做的，详细设计还不一定，但编码一定是由外部公司来做的。对于这样情况的项目，如何来进行管理呢？主要是如何进行代码评审？是关键代码进行评审而普通 ...
关于外包项目,我也接触过一些,但各个公司情况有别,针对你所说的,我简单地谈谈.
外包项目肯定要签订合同的,合同的内容应该尽量详尽,包括如何管理、遵循的过程、规范、验收标准等，如何付费（计时或计件），人员的组织和职责等，审计与检查，中止项目的情况。这些需要专门的人员来管理合同，一般发包方会委派一个接口人或经理来负责合同管理及监控，验收肯定也是由发包方组织的。
针对你所说的编码外包，在管理方面需要关注编码质量、进度（如果是计时付费的话）等，编码当然应该遵循发包方提供的编码规范，代码缺陷率要在可接受的范围内，对编码及以后的阶段也有可行的计划。
其实理想的做法是，发包方把产品质量标准详细提出后，只负责验收就可以了，当然中间也可适当关注其过程及可能的风险，以及时发现问题或风险。代码的评审发包方其实不必投入人力，但是要在中间或编码完成后进行抽检和验收。
外包对发包方来说是一种投资，所以成本最小化，利益最大化是一个非常重要的考量，不能随便答应投入已方人力，因为这是成本，这些事情要尽量由承包方去做，本方通过制定详细明确的标准和有效的监督来严把质量关。
你所说的测试自己尽量少做，可以给承包方以方法和技术方面进行指导，本方只负责编码质量的验收和验收测试就可以了，这样权利和职责就很清楚。 客户怎么要求你
你就怎么要求他们 1，前端主要还是要求外包方及时交付代码。必要时候可以随时访问到分包方的配置库。可以有选择的每天进行抽检。设计都是自己做的，做设计的人每天抽出1小时去check下代码应该没问题吧？
2，加强计划的跟踪，使研发过程透明。具体请联系我详述。
3，一方面是可以考虑自己有测试团队进行尽早的介入测试；另外一方面也可以考虑把测试和开发分包给不同的分包商，具体的操作和管理也可以联系我详述。
4，另外，对阶段交付物和最终交付物的交付准则，UAT的范围/准则，维护相关事宜需要在合同中界定清楚。具体也请联系我免费详述。呵呵。MSN: luoyaoqiu@hotmail.com 还是以结果导向为主，把本方想要的结果在合同中明确，过程监控也不放松（主要由发包方的QA承担此责任），但不建议发包方投入过多人力去做评审和工程级测试，如果还需要发包方投入较多人力，那还不如自己做算了。
回复 2# 的帖子
“外包项目肯定要签订合同的,合同的内容应该尽量详尽,包括如何管理、遵循的过程、规范、验收标准等，如何付费（计时或计件），人员的组织和职责等，审计与检查，中止项目的情况。这些需要专门的人员来管理合同，一般发包方会委派一个接口人或经理来负责合同管理及监控，验收肯定也是由发包方组织的。”您说的这些，主要是和合同有关，但通常情况，一般人是看不到合同的，如何才能了解到合同中是如何规定的呢？是需要让项目经理将内容写在计划中吗？
“你所说的测试自己尽量少做，可以给承包方以方法和技术方面进行指导，本方只负责编码质量的验收和验收测试就可以了，这样权利和职责就很清楚。”
对于这个我不是很赞同，这样一来就失去了一个发现问题的机会！同意4#所说的“一方面是可以考虑自己有测试团队进行尽早的介入测试；另外一方面也可以考虑把测试和开发分包给不同的分包商”。不知道您有没有别的想法！感谢您的回复，希望跟贴！
业务决定管理
对于外包出去的项目应该如何管理, 个人觉得具体管理的方式跟外包出去的什么业务会有比较大的关系, 什么样的业务决定了如何去管理."外包"可以帮助国内很多中小企业成长, 国内企业通过与国外技术人员的沟通和交流, 学习国外现今的开发/测试/理论/实践, 达到一定的经验积累后, 融入自己的研发/测试体系之中, 转变成自己的"资源储备", 更好的应对现在和将来的竞争对手, 是一种经验传承链条. 然而, 企业能够在众多的外包竞争者中脱颖而出, 个人觉得(可能不一定正确, 如果有任何不妥或不正确的地方, 欢迎大家指正.), 应该建立"共生"的关系. 接包方和发包方通过"共生"关系, 互惠互利, 发包方可以将项目过程中的某些环节转移到接包方, 从而降低成本, 接包方可以从接受链条中较低层次的工作开始, 积累经验, 逐渐的承接更多链条中更高层次的工作(如设计, 架构等), 通过更高质量的外包服务帮助发包方获取更多的订单或项目, 让其发展壮大, 而这样的结果就会促进发包量递增, 促使接包方通过变革或升级, 提升自己的管理水平和开发水平, 继续将"共生"关系维持在一个"双赢", 让二者都不断的持续发展.
"外包"这种商业模式, 大致存在着三个角色, 最终客户, 发包方, 接包方, 这三者在项目的实施过程中的责任应该是明确的. 可能基于发包方外包的环节有所不同. 下面以发包方外包部分编码和设计环节为例讲述一下, 发包方和接包方的管理模式.
编码几乎是所有外包首先接到的业务, 这个过程发包方会以明文的方式告知接包方团队, 代码的编写必须遵循指定的规范(变量命名, 缩进等规约), 同时还包括如何提交代码到源码服务器, 如何从源码服务器更新本地工作空间, 如何解决冲突, 何时提交代码, 何时不能提交代码, 提交代码的标准是什么等等, 这些约定都会在接包的时候收到明确的规定(如果没有, 那么存在两种可能, 1) 发包方非常信任接包方, 2) 发包方重点关注的不是编码部分), 接包方按照这些约定, 根据发包方的设计完成代码的编写, 同时满足发包方在编码前预先编写好的测试用例(单元测试级别或功能测试级别的用例, XUnit,测试驱动开发在外包中的一种实施方式). 发包方会通过autobuild来执行预编写的TestCase验证功能的实现情况, 然后根据设计对每天提交的代码进行code review(通常由发包方中由经验的高级项目经理完成), 如果发现小部分代码不符合设计的话, 会马上修改后提交, 如果发现大部分代码不符合设计的话, 会通知接包方的开发人员rewrite, 代码的验证基本上就是通过这种方式.(可能会根据发包方和接包方的紧密程度会有不同的实践和沟通方式). 这大致就是外包编码业务的沟通和管理过程.
基于良好的编码质量的基础上, 发包方很有可能会将部分的设计业务外包出来, 这时候"共生"关系算是向前推进一步了. 首先, 可能会让接包方做的设计工作是评审设计和提出设计方案这类型的, 是一个让发包方了解接包方承接设计业务的能力和工作质量的过程, 会根据接包方的能力, 分配不能级别的设计工作, 方法级别->类级别->包级别->功能级别->架构级别. 这个过程中需要发包方和接包方有一个沟通的变革, 在只承接编码业务的时候, 发包方对接包方的开发人员很可能是处于"细粒度管理"(发包方的项目经理直接管理接包方的开发人员), 到了这个阶段, 会逐步过渡到"粗粒度管理"(双方的关系中会演变成三种角色, On-shore Manager | Off-shore Manager | Developer), Off-shore Manager直接对Developer管理(代码的first review和功能盐城), 负责与On-shore Manager进行沟通(同步开发状态和进度等信息), 这里要求接包方要进行一定程度的管理变革, 具有一定的项目管理/风险管理/项目监控的能力. 大致的业务过程是这样的, 两个子过程, 提出设计和评审设计, 如果发包方直接提供设计方案的话, 接包方直接参与设计评审并提出设计的改进建议(可通过参与积累如何实施评审的经验, 如何有效的组织和进行评审, 评审的关键等等), 如果没提供, 那么通常会要求接包方按照要求提出设计方案, 然后进入双方评审, 经过沟通-评审等几次迭代后, 基线化设计方案, 进入编码环节.
当双方的信任程度达到一定层次的时候, 那么部分需求环节也有可能会交由接包方进行管理, 双方的高级工程师从项目的开始就会有相当紧密的沟通(对需求对架构对设计对后期的扩展性等), 发包方在过程中充当接包方和最终客户的需求沟通桥梁(这里用"桥梁"可能不恰当, 因为不单单是"连通"的作用). 这个环节可接触到发包方的需求管理和需求变更的流程, 为接包方的管理提高了一定的借鉴经验.
上述的三个环节不一定有明确的界限, 会有很多交叉的地方, 同时会根据发包和接包两者的紧密程度以及沟通管理方式会有不同的具体实践.
对于测试这个业务, 可能会有三种实施的方式, 1)部分测试业务由接包方的测试组或测试部完成, 测试组完成first check(功能或性能级别), 发包方进行second check(验收级别), 2)所有测试业务不外包, 由发包方自己完成, 3)外包到其他的独立测试机构. 一般情况下, 测试业务会和编码业务缠在一起. 融入了测试之后, 双方的关系又会发生部分变化, 分工和管理更细了, 演变成5个角色, On-shore Develop Manager | On-shore QC Manager | Off-shore Develop Manager | Off-shore QC Manager, 整个过程分裂成两个独立的体系: 开发体系和测试体系, 独立管理+独立职能+多向沟通, 可能会出现下面的沟通图:
On-shore Develop Manager <----> On-shore QC Manager
/| |\ /| |\
| | | |
| | | |
| | | |
\| |/ \| |/
Off-shore Develop Manager<----> Off-shore QC Manager
对于上述的过程, 会存在很多需要优化的地方, 比如如何才能让发包方更高效的清楚接包方的开发/测试状态, 如何才能更好的在"拉"的业务模式中提供更高质量的测试外包服务, 如何才能长久的维持双赢的"共生"关系, 如何才能高效的利用"共生"关系提高接包方自身的能力和文化积累以获得更大的生存空间等等, 这些都是非常值得思考的问题.
谢谢大家忍耐了上面那么冗长的文字, thanks for your reading, if anything wrong, please correct me.
Thanks again. :) 原帖由 xsnzhq 于 2009-1-5 10:47 发表 http://bbs.51testing.com/images/common/back.gif
“外包项目肯定要签订合同的,合同的内容应该尽量详尽,包括如何管理、遵循的过程、规范、验收标准等，如何付费（计时或计件），人员的组织和职责等，审计与检查，中止项目的情况。这些需要专门的人员来管理合同，一般 ...
外包项目的管理其实可能涉及多个部门和多种角色，有复杂的沟通与协调工作需要做，我不知你所说的外包项目是站在什么样的角度来来谈这件事，不同部门关注点是不一样的，但是一定得有一个人全面协调这件事，QA当然不能胜任此职。7楼的朋友谈了很多非常有价值的观点，可以参考。罗叶老大的实际操作经验比较丰富，可以与他多交流一下。
我想强调一点，必须把各方的权责在合同中定义清楚，不然出了问题在定位责任时会扯皮。另外，一定要有成本概念，如果发包方投入太多（如投大量人力去做评审和测试），这其实也是一种投入的增加，反而会增加接包方的依赖，如编码时，他们会放松质量要求，反正等发包方评审出问题或测试出问题，他们改正就可以了，这可能会使发包方越陷越深，而导致自己投入过多，而造成机会成本大增。
你所担心的问题，可以通过发包方的QA加强监控和审计，来保证过程及产品的可视性，避免较大风险。
配置管理问题，当然也是责任划分的问题，谁负责的谁来做，如达成一致的合同及变更情况，双方肯定都得管理起来，代码在交付之前当然由接包方来配置管理起来，还有其它文档那就看谁来做的，谁负责管理了。
回复 7# 的帖子
你说的太好了，太细致了！感谢您的回复，会把您的内容收藏！:) 原帖由 zhongmg108 于 2009-1-5 13:53 发表 http://bbs.51testing.com/images/common/back.gif外包项目的管理其实可能涉及多个部门和多种角色，有复杂的沟通与协调工作需要做，我不知你所说的外包项目是站在什么样的角度来来谈这件事，不同部门关注点是不一样的，但是一定得有一个人全面协调这件事，QA当然不 ...
您这次的回答很清楚，我已经明白您的意思了。很感谢！:)
回复 8# 的帖子
Comments here.外包项目的管理其实可能涉及多个部门和多种角色，有复杂的沟通与协调工作需要做，我不知你所说的外包项目是站在什么样的角度来来谈这件事，不同部门关注点是不一样的，但是一定得有一个人全面协调这件事，QA当然不能胜任此职。7楼的朋友谈了很多非常有价值的观点，可以参考。罗叶老大的实际操作经验比较丰富，可以与他多交流一下。
(
我觉得楼主这里的意思应该是站在发包方的立场上考虑的, 个人觉得这里的外包项目指的是长期的伙伴合作关系, 而不单只指一个短期项目的合作, 双方共同发展.
)
我想强调一点，必须把各方的权责在合同中定义清楚，不然出了问题在定位责任时会扯皮。
(
权责这一点, 非常同意, 不是很了解合同这一块, 不知道这一块的责任粒度可以达到怎样的粒度? 能否告知?
)
另外，一定要有成本概念，如果发包方投入太多（如投大量人力去做评审和测试），这其实也是一种投入的增加，反而会增加接包方的依赖，如编码时，他们会放松质量要求，反正等发包方评审出问题或测试出问题，他们改正就可以了，这可能会使发包方越陷越深，而导致自己投入过多，而造成机会成本大增。
(
成本这一块的确非常重要, 这里有一个问题需要可虑, 是通过早期投入小量的成本来保证后期质量比较好 还是 通过后期投入大量的成本来弥补质量比较好?举一个比较极端的例子, 比如, 发包方将一个1年工期的项目交给了接包方, 设计和编码两个过程完全有接包方完全负责, 发包方只负责需求和最后的验证(通过最后阶段的评审或测试发现问题, 然后叫接包方修复)这一块的工作, 没有过多的参与到接包方的设计和编码活动当中. 到第10个月, 发包方对接包方的第一阶段的成品进行验证, 发现系统的功能无重大问题, 但是系统的性能严重无法满足发包方向最终客户承诺的要求, 导致性能低下的根源是架构的问题, 要修复这个根源, 让成品满足最终客户的要求, 需要花3-4个月对整个系统的代码进行大型重构, 这样接包方无法如期向发包方提供满足质量要求的成品, 发包方也无法向最终客户交付满足质量要求的成品, 这就导致了这个项目的失败, 甚至连这种"共生"关系都会断裂.
可能上面的例子有些极端, 但项目失败可能是最糟糕的事情, 如果前期的少量投入能够规避或解决后期大量的风险的话, 个人觉得发包方这种投入或成本还是必要的.
在实际的操作过程中, 发包方肯定会想方设法的监控到每个人的工作状态, 每个模块的实施情况, 每个子系统的测试情况等等类似的信息, 原因就是"不信任", 发包方不会完全的信任接包方, 发包方不愿意看到最终失败的结局. 另外一个比喻, 投资者A将自己的100W资金交给了基金经理B管理, 让他去将这些资金越滚越大, 投资者A很有可能会不断的与基金经理B沟通, 了解他准备如何运用这笔资金, 投资到哪些行业, 什么时候投, 投资的比例如何, 哪些是保本的投资, 哪些是稍微进取点的投资, 还有各种投资的风险如何. 就是因为这种"不信任", 才会促使投资者A去监督基金经理B是如何运用这笔资金的. 同样, 发包方和接包方的关系也类似投资者A和基金经理B的关系, 谁都不希望最后的投资亏本. 项目失败了, 发包方损失的是金钱和信誉, 接包方损失的是除了金钱和信誉外, 损失惨重的是形象, 后者损失的更为严重, 一旦形象破裂了, 要重新所造, 将会是一个成本和投资更加巨大的工程.
正是因为这种发包方和接包方的相互依赖, 才能促进双方的相互信任, 形成长久的合作关系.
)
你所担心的问题，可以通过发包方的QA加强监控和审计，来保证过程及产品的可视性，避免较大风险。
(
QA关注的是过程, 只能保证过程实施的正确性, 但并不能保证通过过程出来的东西是都是正确的, 因为最终实施过程的还是人, 人才是执行过程的主体, 过程规范告诉开发人员要根据设计的流程去完成系统设计的工作, 但不会告诉开发人员应该使用什么技术什么框架去设计系统才能大致满足性能需求(此处的性能需求针对的是上述的例子). 没错, 这里会引入审计, 审计包括两个大方面的验证, 功能设计和物理审计, 能够保证质量的会是QC执行的功能审计, 通过评审或测试来完成, 这里涉及到发包方审计工作的切入点和切入时刻, 个人觉得发包方肯定会觉得, 越早介入越好(不会等到第10个月才介入), 这样的话这个接包方的工作在发包方的眼里是可控的, 而这种介入, 就是上面所说的不可缺少的相互依赖. 这种监控的力度有多大粒度有多细, 取决于发包方和接包方之间的"信任"程度.
)
配置管理问题，当然也是责任划分的问题，谁负责的谁来做，如达成一致的合同及变更情况，双方肯定都得管理起来，代码在交付之前当然由接包方来配置管理起来，还有其它文档那就看谁来做的，谁负责管理了。
(
配置管理这一块, 不同的发包方会有不一样的要求, 对于机密的系统(或出于知识产权和配置库安全性的考虑等等), 可能接包方要到发包方指定的地点进行开发, 所有一切都由发包方管理. 也存在完全外包的方式, 发包方只关注最终release出来的系统能否满足最终客户的需求, 而对接包方如何做这个系统不关注或关注度较低. 同意这里的观点, 双方约定好管理方式就可以了
)
面向服务的外包可能比面向项目的外包更具有竞争力.
If anything wrong, please correct me. :)
[ 本帖最后由 RYAN.D 于 2009-1-5 16:23 编辑 ]
回复 11# 的帖子
感谢大家的回答，非常感谢！但是我要重新描述一下项目的情况：需求、概要设计、详细设计都是由发包方完成，测试也是一样的，只是编码工作有接包方来完成。可以很直接的说这是个小型项目，编码的时间很短，也许２－３个月就完成。对于这样一个项目如何才能做好监控？使项目即在控制范围内有不影响项目的进度呢？可以对哪些步骤作剪裁呢？或者是不是在代码检查的方面可以频率大一些？在接包方将作好的系统移交之发包方时，我们是不是应该规定一些标准来控制移交，例如：什么情况可以拒绝接受版本之类的。
大型项目的管理大家说得很清楚了，但对于小型项目应该如何剪裁和如何控制监控的度，还是很难把握，希望大家给些建议！感谢！:) 原帖由 xsnzhq 于 2009-1-5 17:42 发表 http://bbs.51testing.com/images/common/back.gif
感谢大家的回答，非常感谢！
但是我要重新描述一下项目的情况：需求、概要设计、详细设计都是由发包方完成，测试也是一样的，只是编码工作有接包方来完成。可以很直接的说这是个小型项目，编码的时间很短，也许２－ ...
这类外包项目比较普遍，而且通常的做法类似借用外部人力，还是由已方该项目的经理来管理，需要做好人员质量和数量的控制，最好能提前做一个水平测试和能力考核，以确认其技能满足项目要求，数量不要太多；编码团队组建后，要进行必要的培训（项目背景、需求、设计的介绍，编程规范，工具实用，过程管理等）。
还是简单一点说吧，如果基本上借用人力这种形式，那么就按公司自己的项目的编码阶段控制就行了，所有东西由你们自己负责，接包方甚至不对编码质量负责，他只提供人力。而发包方要选择合适的人员，并控制好进度就可以了。这种形式的外包是最简单的，不知你们是不是采用这种外包形式?
[ 本帖最后由 zhongmg108 于 2009-1-5 18:13 编辑 ] 原帖由 zhongmg108 于 2009-1-5 18:07 发表 http://bbs.51testing.com/images/common/back.gif
这类外包项目比较普遍，而且通常的做法类似借用外部人力，还是由已方该项目的经理来管理，需要做好人员质量和数量的控制，最好能提前做一个水平测试和能力考核，以确认其技能满足项目要求，数量不要太多；编码团队 ...
由于接包方式在很远的外地，而又要对他们所编写的代码进行检查（检查是否按照我们所作的设计完成的以及编码的质量问题），这就出现了一个问题，就是应该采用什么样的方式来时时获取他们的代码呢？这洋的项目的检查频度应该是什么样的，才能既保证质量又在成本的控制范围内？
回复 14# 的帖子
具体使用什么方式跟发包方和接包方的时差有一定关系, 较为理想的状态是, 双方的时差大致相差10-12小时的话, 那么可以让接包方把他们的源码服务器公开给发包方, 提供vpn介入或publish到公网, 让发包方可以在接包方下班后对代码进行检查(有一个约定: 接包方必须每天提交可执行无编译错误的完整代码). 具体检查的频度如何决定, 取决于发包方的意愿, 可以当每天一次/每周两次/模块开发的前中后期各一次/...另外一种极端的情况, 就是双方的工作是同步进行的(0时差). 这种情况下, 同样需要接包方将源码服务器公开给发包方, 不同的是, 通过tag来给源码打上标记, 发包方每次检查的源码都是基于某个tag的, 比如, 选择每周两次的检查频度, 那么1月5号~1月9号这周就要检查2次, 分别在1月6号和1月8号, 那么发包方可以要求接包方在1月5号和1月7号下班前, 给源码打上一个类似CHK_20090105这样的tag, 并让接包方以email形式通知发包方, 发包方收到email后到接包方的服务器获取源码并进行检查, 当天下班前以email的形式将问题或信息反馈给接包方, 或由发包方的工程师直接对源码直接修改并提交.
以上两种情况都可以适当的引用tag来帮助发包方检查相对稳定的代码.
If anything wrong, please correct me. :) 原帖由 RYAN.D 于 2009-1-6 10:45 发表 http://bbs.51testing.com/images/common/back.gif
具体使用什么方式跟发包方和接包方的时差有一定关系, 较为理想的状态是, 双方的时差大致相差10-12小时的话, 那么可以让接包方把他们的源码服务器公开给发包方, 提供vpn介入或publish到公网, 让发包方可以在接包方下班 ...
恩！明白您解释的！感谢！主要就是通过他们的外网服务器来访问！:)
页:
[1]
