敏捷软件外包的挑战与策略
10年我和外包之间的复杂关系
当时我是长沙Powerise集团旗下的创智国际的项目总监，有三个外包项目。项目客户之一是微软。当时说是通过李开复，项目是Business Dynamics ERP产品的本地化。我们团队大概有25个人，瀑布开发。我记得项目经理最大的一个好处就是每天和团队一起加班。我们对ERP业务，尤其是财务知识知之甚少，项目很痛苦。负责这个项目的人对我们很有耐心。因为大女儿要出生，又因为当时创智集团的上市风波，我呆了四个月，选择暂时离开创智国际，回波士顿照顾家人。后来这个项目被微软拿到新加坡，长沙团队解散。虽然时间不长，但我感受到了软件外包的挑战和机遇。
2006年7月，我还是新英格兰中国信息网络协会(简称NECINA)的主席，该协会是北美最具影响力的非营利性中文专业协会之一(www.necina.org)。在协会的平台帮助和干事们的努力下，我发起了首届“中美外包论坛”，于10月2-4日在波士顿165438成功举办，并被央视报道。本次论坛是华北地区首个也是唯一一个对接平台，旨在对接美国外包公司和到中国承包工程的美国客户。我竭尽全力把国内10家企业(包括中关村园区)推向国外市场，没有任何报酬。
165438+2006年10月至2009年3月，我在美国Lumigent工作，担任软件外包工程总监(甲方)。之前的职位都是外地人，一年之内就废了。这一次，很明显我们必须雇佣一个中国人，因为供应商(ArrAy，后被日立收购)的外包团队在广州，团队大概有30人。首先，它采用瀑布模式。说实话，这份工作很辛苦，不早不晚。波士顿和中国的时差刚好是12小时。积累了很多外包经验，和外包团队关系也很好。
后来在2008年参与策划了与马萨诸塞州政府合作的第二届中美外包论坛，2009年参与策划了与MIT合作的第三届中美外包论坛。
2009年3月，我第二次回国，登陆苏州，做新宇软件的供应商。(Dextrys)负责领导客户的Avid外包项目，一年内从最初的20-30人迅速增加到65，438+050人。它在敏捷招聘、建立和培养Scrum团队以及采用Scrum交付软件产品方面非常成功。2010年，我被新宇派到中国敏捷开发团队，从零开始打造新客户Endeca。三年时间，我有机增长到45人。2012年，我被甲骨文收购。我担任中国甲骨文软件R&D中心的软件开发总监。
2013年3月至2014年2月，我在北京加入Shinetech，担任全球交付副总裁，主要参与一些大客户的商务谈判，负责上海和苏州两个分公司。Shine Tech是中国很早的民营企业，专注于国际服务外包，其敏捷文化在中国独树一帜。
需要说明的是，我第二次回国时在这些企业参与的所有项目，都是100%用Scrum方法开发和交付的。我们能从中学到什么？
1.？甲乙双方流程一样-？混乱
Scrum已经成为双方约定并遵守的项目管理(就人和事而言)流程和团队工作模式，Scrum的开发模式在双方的合同中写得很清楚。甲方和乙方应该停止强迫使用哪一方的“最佳实践”来开发软件，并标准化一个过程和一个上下文。因为Scrum强调透明和透明建立，赢得了甲乙双方的互信，包括两周迭代的劳动成果的及时展示，让客户看到项目的真实进展。从全球范围来看，Scrum甚至已经成为母公司收购子公司后的统一工作方法和标准化流程。Jeff Sutherland(Scrum的创始人)是风险投资公司Openview (/)的顾问。Openview要求他们投资的所有初创企业都必须遵循敏捷价值观，按照Scrum的流程框架工作，无论是市场部还是运营生产部。Scrum已经成为一种统一的工作方式，没有必要花时间争论什么是最佳实践。我带了Avid，Endeca，Ralph Lauren等项目。合同中明确使用了Scrum的开发方法。
2.？敏捷合同
怎么签合同？敏捷合同(SOW)无非就是这些:
(1)无固定期限合同，即只签目标和大致范围的要求，不签具体细节，签负责人，定人员。当时我们在欧美的项目都是签固定头的，根据工程师的工作经验和年限有不同的报价。几乎每个候选人都要接受客户的面试，根据自己的能力报价。甚至这个报价对乙方工程师也是公开透明的。应聘者知道自己的分量，自己的价值，以及客户对自己评价的反馈。甲方每月结算一次或一次迭代结算一次。这种合同可以由客户提前终止，客户只需提前3个月通知乙方。
(2)签订收入长期合同。近年来，国内外包市场非常大。我们发现国内有一种模式是甲乙双方共同开发某一类互联网产品，产品收益的一部分和乙方挂钩，这样甲乙双方绑定在一起，一个产品，一个团队，风险利益共享，大家成为真正的伙伴关系。
(3)按照迭代用户的故事点付费，每次迭代结算一次，签约时间更灵活。当然，在这种情况下，甲乙双方已经过了磨合期，建立了长期的信任关系。
(4)固定报价的合同，这是最常见的，甲方说“我要这么多预算的这些东西，六个月就上线”。即定范围、定报价、定时间的合同(质量要求也会附上)。这种合同是最头疼的。其实在签订这种合同的那一刻就埋下了一颗“定时炸弹”。甲方试图得到一个“确定的”、“有保证的”承诺文件，实际上只是买了一个心理上的安全感或安慰，更像是一个“不平等”的条约。乙方要卖的是尽快拿下订单和自己的高佣金，不会花太多时间评估风险。在大多数情况下，结果是。
√?如果价格固定，如果团队不固定，乙方往往会作为资源“换人”或“搬家”，有时甚至供应商的一个项目经理或工程师横跨多个客户和项目。表面上这个人是在为甲方服务，实际上并非如此，客户还是在“买单”。人不是资源。客户花费时间和精力投资于这些“人”。可惜人员不固定，给供应商作弊留下了空隙，即使供应商不是故意的，有时候也是被迫的，比如项目报价太低，没有利润空间。
√?外包团队成员没有归属感，外包容易造成甲乙双方“不对等”的心理阴影，如果甲方强，乙方弱，人和项目不绑定，就不可能建立团队和工作小组，那么团队效率如何提高？客户的利益得不到保障。
√?对于固定报价的项目，项目后期常见的“风景”是:加班加点，削减范围，拖延时间，自动牺牲质量，团队士气低落，客户开始抱怨，乙方是消防员。
所以尽量避免给可变固定价格的人签合同。如果客户非要签，不如签两阶段合同，即1-2个月的固定时间合同+固定价格合同。至少先跑几次迭代试试水。有些事情，你要开始“涉”才会知道“水深”，才会知道风险有多大。经过一两个月的尝试，我确定了主要风险并“试水深”，为签订第二阶段固定价格合同做足了功课。同时保护供应商的利益，最终对客户负责。
那么，一个固定价格的项目能以敏捷的方式交付吗？答案是肯定的；
√?需求还是优先的，20/80？原则:永远专注于最有价值的前20%的需求，最起码不会错过重要的高价值需求，惹恼客户。即使我们在项目结束时迫于时间压力，那些做不到的需求也是不重要的或者可有可无的。
√?两周迭代有产品的增量劳动成果展示给客户，寻求反馈，不要“偏离”太多，及时校对。这看似增加了成本(开销)，却避免了走弯路，避免了后期可能出现的大错误，甚至全部推翻。
√?如何应对新的需求？首先，我们是欢迎的，但条件是，在类似规模的合同中，用一个低价值的需求来替代。这样做的好处是不需要更改合同总价，也不需要经历繁琐冗长的需求变更过程。“免费更换”.大家为客户省事省钱，如下图。
√?固定价格合同可以提前终止吗？比如对客户来说，重新评估剩余需求毫无价值或者ROI太低？这时候如果突然终止合同，对供应商来说是一个很大的损失，对人员闲置板凳时间也不公平。？甲乙双方的合同是事先约定的。如果客户要提前终止合同，剩余合同价格的一定比例会分给供应商(比如余额的30%，20%付给供应商)，客户也会节省预算。类似“不劳而获”的合同迫使客户优先考虑商业价值。对于供应商来说，最好的模式是现收现付，供应商团队可以做其他更有价值的项目。
这里有必要澄清一下估算的目的，一个误区，估算不是用来报价和签合同的。敏捷评估的目的是:让跨职能团队的每个成员在评估过程中互相学习，并达成对需求的* * *理解。评估的过程是一个学习和调整的过程。随着项目的进展，成员对需求的了解和知识经验的积累，团队可以重新估算之前的估算，重点不在于估算有多准确，也不在于怎么教你估算。总之，没有对错的估计。永远不要将评估等同于承诺。
3.？Scrum角色在甲方和乙方的定位
大多数情况下，PO来源于客户，客户的PO了解业务和行业知识，注重投资回报。但可能会忽略供应商的利益。如果采购订单来自供应商，我们将其定义为采购订单代理。最大的问题是没有授权做决定，带来了延迟成本。PO agent成为外包团队澄清需求和问题的第一道防线。如果PO代理与真实PO不在同一个办公室，PO代理就成了“中间人”。想象一下这个模型:PO-> PO proxy-& gt；？团队；当然，如果客户没有明确PO的角色，那就更麻烦了，最终产品也没人负责。PO的角色定义是关键。这个采购订单肯定能够全职处理这个产品。大多数企业对PO没有一个明确的定义，存在扯皮现象，或者说PO没有权力，没有动力。
我看到的一个常见的不好的情况就是这种结构，业务部门(甲方)+IT PM(甲方项目经理)+外包团队(乙方)+？乙方项目经理；甲方有一个IT项目经理连接业务和乙方，这个IT项目经理作为中间人，增加了沟通的成本，非常耗时。大多数情况下，乙方的项目经理是一个“摆设”，或者是一个团队的“主管”，或者是一个团队的“保护伞”，或者是“代言人”。这使得外包团队很难成长。
推荐的做法是，我们鼓励客户的真实PO直接和外包团队沟通对话，去掉中间人。一个成功的采购订单至少要花1/3的时间与外包团队沟通。
甲方的IT项目经理这个角色是有价值的，但是在敏捷项目中需要重新定位。要么scrum master辅导PO和乙方的SM，帮助清除团队在甲方处理不了的障碍，要么成为团队的一员，负责甲方的IT技术，比如架构，融入团队的工作。但你不能做项目经理，什么都管，充当监工，最后变成“背锅人”。
ScrumMaster和开发团队来自供应商，SM一般来自乙方，利益都在一家公司。SM离团队近，容易教练。乙方的SM？我觉得没必要全职(除非客户要求全职)，甚至可以参与一些开发工作。我带过的所有SM的团队都是兼职。在实际的国内项目中，我也看到SM来自甲方，这让SM更容易帮助团队扫除障碍，与外包团队建立信任和尊重。
敏捷外包团队是跨职能的。这样做的好处是，当我们开始组建Scrum团队时，不需要打破传统职能部门的架构，不像做产品的公司要向敏捷转型，进行重组。我们根据合同(内部招聘和外部招聘)招聘人员，建立一个多功能的全职团队。此外，甲方采购订单可能没有必要参加整个回顾会。有时候团队因为甲方PO的存在而感到不舒服，缺乏“安全感”，需要邀请PO参加一些回顾会。
4.敏捷外包的良好实践:
√?乙方到甲方现场办公，坐在一起。同地办公项目已经成功了一半。国内很多客户都是这么做的。即使不能，也要定期和客户互访。
√?项目启动时，甲乙双方所有项目成员创建一个产品愿景，明白为什么，把业务方、IT人员、外包团队召集起来，做一个两天的工作坊。这可能很“奢侈”，但收益远远大于投入。我辅导过的几个客户都意识到这样做的必要性。
√?团队在Sprint计划会议上留下了5-10%的松弛时间。一种情况，甲方的SM鼓励外包团队有10%？外包团队对创新和独立时间非常满意，但生产效率提高了很多。
√?建立超越团队层面的障碍广告牌，主要针对甲方，甲方的IT经理主要以帮助团队解决这些问题为主。问题的可视化是关键，最好是客户的人员跟进。
√?保证PO的每次迭代和团队的需求梳理持续进行，不“打折”。选择一个合格的PO，PO参加迭代规划会，明确目标，不要在迭代中玩“消失”。
√?甲方不想微观管理乙方团队每个人的工作，而是把微观管理留给团队本身。
√?辅助使用实体和电子工具，不要放弃实体白板。
？5.？敏捷外包文化——长期产品合作伙伴关系
√?甲方和乙方是共同场地的伙伴关系，并建立一个产品，一个目标，一个团队和一个真正的伙伴关系的想法。大家都在一条船上，一起划船，停止合同“游戏”，结束独立的想法。步调一致，和谐必胜。降低合同谈判和续签的成本，不用花时间寻找其他供应商。
√?Scrum的五个价值观成为我们一起工作的文化。尤其是尊重的文化。甲方和乙方的项目关系虽然我们属于不同的组织，但这并不影响我们对敏捷原则的拥抱和实践以及对一个产品的忠诚。
√?项目启动时，甲乙双方应邀请敏捷项目成员参加至少一天的基础培训。定期讨论和理解敏捷价值观和原则，以及它们对我们行为的意义。敏捷项目的每个成员都有买入敏捷的想法。在过去的几年里，我辅导的客户不仅培训了他们的IT团队，还开始督促供应商做敏捷培训，这是双方的事情。
事实上，2012年，我亲手打造的Endeca中国敏捷开发外包团队被甲骨文收购，也就是在一开始，我们的定位是产品合作伙伴关系，外包团队对产品理解深刻，与客户和同事关系融洽，做事方式方法潜移默化受到客户文化的驱动，最终双方都认可。
最后，我总结了我对敏捷外包趋势的观察:
(1)?外包项目可以灵活开发。Scrum一定会有利于外包项目的交付，透明度会让客户的信任度加倍。Scrum注重诚实。没有诚信，甲乙双方怎么做生意？
(2)?即使是固定价格的项目也不会阻止你尝试以敏捷的方式向客户交付价值。虽然客户可能还有传统思维，但是不要指望客户会先改变或者以此为借口“我们不能敏捷”。乙方怎样做才能赢得甲方的信任？敏捷开发是你马上开始的地方。
(3)?与传统外包相比，敏捷开发已经成为乙方的商业模式和竞争优势。有敏捷开发经验的供应商更容易接单，在签订合理公平的合同上更有话语权。供应商(乙方)应该抓住机会，努力打造你的敏捷团队，这是你的资本资产。
(4)?团队一旦采用敏捷开发模式，就很少愿意回到旧的瀑布模式。
吉姆·王？
2020年5月4日疫情期间写的？
参考资料:
(1)一本Scrum书:游戏的精神？1st版，由？杰夫·萨瑟兰？詹姆斯·o·科普林？Kiro Harada？约瑟夫·约德？琼·金？延斯。斯特加德？等等。？
(2)完全分布式Scrum:复制本地生产力和质量？离岸团队
杰夫·萨瑟兰，吉多·舍恩海姆博士，毛里茨·里克