另外 你经常能看到的多是 Distributors ，如：
Altera 的代理 骏龙 艾瑞 等
Xilinx 的代理 安富利 好理顺 等
Lattice的代理 威健 等
这些都是比较大的分销商，还有很多未进行罗列。
2005年8月我在麻州Vicor公司（半导体制造业）做了5年CIM软件工程师后离职回国，正式跨入中国软件外包行业，直到2014年12月，这一干就将近十年。下面结合这10年的外包经历和敏捷实践，一起探讨敏捷软件外包的挑战和策略。
我与外包的10年情结
我当时在长沙创智集团（Powerise）旗下的创智国际任项目级(program)总监，有3个外包项目，其中一个项目客户是微软，当时据说是通过李开复牵线搭桥，签的项目是Business Dynamics ERP 产品的本地化。我们团队人数大约有25人，瀑布开发，我记得项目经理的一个最大的优点是每天和团队一起加班，我们对ERP业务特别是财务知识的了解少得可怜，项目做得很痛苦，这个项目微软对接负责的人对我们很有耐心。我呆了四个月因为大女儿要出生，加上当时创智集团的上市风波，我选择暂时离开创智国际，回到波士顿照顾家庭。后来这个项目，微软还是拿到新加坡去做，长沙团队解散。虽然时间不长，我感受到了软件外包的挑战和机会。
2006年7月我兼任纽英伦中华资讯网路协会(简称NECINA)主席，NECINA是北美地区影响最大，会员最广泛的非盈利华人专业人士协会之一（www.necina.org）， 借助协会的平台和干事们的努力，我发起第一届“中美外包论坛”，当年11月2-4日在波士顿成功举办，中央电视台做了报道。该论坛是北美地区第一个唯一旨在联结中国外包公司和有项目发包到中国的美国客户的一个对接平台。也算尽自己所能，没有任何报酬，尝试把中国10家企业（包括中关村园区）推向国外市场。
2006年11月-2009年3月我就职于美国Lumigent担任软件外包工程总监（甲方），先前的这个职位都是老外，干不到一年就废了，这次明确一定要雇个华人，因为供应商（ArrAy, 后来被日立收购）外包团队在广州，团队大约有30人，先是走瀑布模式，后来尝试敏捷开发，团队交付能力得到大的提升。说实话，这份工作很辛苦，没早没晚，波士顿的时差正好与国内12个小时。积累了不少外包经验，我与外包团队关系也很融洽。
后来，2008我参与策划了第二届中美外包论坛与美国麻州政府合作，以及2009第三届中美外包论坛与麻省理工学院（MIT）合作。
2009年3月我第二次回国落地苏州，在供应商新宇软件 (Dextrys)负责领导客户Avid外包项目，从最初的20-30人，一年时间快速增长到150人，敏捷招聘，建立和培育Scrum团队，采用Scrum交付软件产品，非常成功。2010年我被新宇派到上海从零开始打造新客户Endeca的中国敏捷开发团队，三年时间有机增长到45人，于2012年被甲骨文收购，我担任中国甲骨文软件研发中心软件开发总监。
2013年3月-2014年12月期间，我加入北京盛安德（ Shinetech）担任全球交付副总裁，主要参与一些主要客户的商务谈判和负责上海和苏州两个分公司，盛安德是国内非常早期的拥抱敏捷思维，专注国际服务外包的民企，公司的敏捷文化在国内独树一帜。
需要说明的是，我第二次回国在这些企业参与的所有项目都是100%采用Scrum的方法来开发和交付，这里面我们能学到什么？
1. 甲乙方同一个流程 -- Scrum
Scrum 已成为甲乙双方共同约定和遵守的项目管理（在人和事方面）流程和团队工作方式， 明确把Scrum的开发模式写在双方的合同里面。 甲乙双方停止强迫用哪一方的什么样的“最佳实践”去开发软件， 规范一个流程，一种语境。由于Scrum 强调透明性，透明性建立，开始赢得了甲乙双方的互信，包括两周迭代的劳动成果的及时展示，让客户看到了项目的真正进展。从全球来看，Scrum甚至成为母公司收购子公司后统一的工作方式和规范的流程。Jeff Sutherland (Scrum的创始人)是风险创投公司Openview （https://openviewpartners.com/）的顾问，Openview 要求他们投资的所有Start-up必须遵循敏捷价值观和按照Scrum的流程框架来工作， 不论是市场销售部门，还是运营生产部门。Scrum成为一个统一的工作方式，不用再耗时争论什么是最佳实践。我所带过的Avid, Endeca, Ralph Lauren等项目， 都在合同里明确用Scrum的开发方式。
2. 敏捷合同
合同如何签署？敏捷合同(SOW)不外乎这几种：
（1）开口合同，即只签目标和大体范围而不是具体细节的需求，签人头，人员固定。我们当时在欧美的项目签的都是固定人头，根据工程师的工作经验和年限有不同的报价。几乎每个候选人都要客户面试，按能力报价，甚至这个报价对乙方的工程师公开透明，候选人知道自己几斤几两，也知道自己的价值和客户对自己的评估反馈。甲方一个月或一个迭代结算一次。这种合同客户可提前终止，只需要提前3个月通知乙方。
（2）签收益的长线合同。近几年国内外包市场很大，我们发现国内有甲乙方一起开发某一款的互联网产品的模式，产品收益的部分比例与乙方挂钩共享，这样把甲乙方绑定在了一起，一个产品，一个团队，风险利益共担，大家成为真正的伙伴关系。
（3）按迭代用户故事点来付费，每迭代结算一次，合同时间比较灵活，当然这种情况，甲乙方已经过了磨合期，建立了长期信任的关系。
（4）固定报价的合同，这种最常见，甲方说：“就这么多预算，这些事，6个月上线，我都要”。即固定范围，固定报价，固定时间的合同（也会附上对质量的要求）。这种合同最头疼，其实签下这种合同的瞬间，就埋下了一颗“定时炸d”，甲方企图要一个“确定的”“有保障”的承诺文档，但其实只是买了一个心理上的安全或安慰，更像一个”不平等“的条约，乙方销售想的是尽快拿下单子和自己不菲的提成，也不会花太多时间评估风险，多数情况下结果是都输，nobody wins, 为什么？
√ 固定价格，如果不固定团队，乙方经常会把人当资源“换来换去“ 或”挪来挪去“，甚至有时候供应商(vendor)的一个项目经理或工程师跨多个客户和项目，表面上这个人是为甲方服务的，但实际上并不其然，客户却还在”埋单“。人不是资源，客户花时间和精力去投资在这些”人“上，可惜人员的不固定，会留有空档给供应商作假，尽管供应商也不是故意的，有时也是被迫去做，比如项目报价太低，没有利润空间。
√ 外包团队成员没有归属感，外包本来就容易造成甲乙方出现“不平等“的心理阴影，甲方强势乙方弱势，人员与项目如果不绑定，谈不上打造团队，工作小组都算不上，团队效率何以提高。客户利益得不到保证。
√ 固定报价的项目，项目晚期的普遍“风景”是：加班赶工，砍范围，延期，自动牺牲质量，团队士气低落，客户开始抱怨投诉，乙方是救火队员。
所以，尽量避免签署固定价格不固定人员的合同，如果客户非要签，也最好签一个两个阶段的合同，即1-2个月的固定时间合同+固定价格合同。至少先跑几个迭代试一下水，有些东西，只有你开始“趟水”做了，才知道“水深”，风险有多大。一到两个月的尝试，识别主要风险和“测试水深”，为签署第二阶段的固定价格的合同做好了功课。同时保护了供应商的利益，最终也是对客户负责。
那么，固定价格的项目能不能用敏捷方法来交付？答案是肯定的；
√ 需求照样排优先级，20/80 原则， 永远专注最有价值的top 20%的需求，最起码不会把重要的高价值的需求漏掉而让客户恼火，即使到项目后期迫于时间的压力，做不了的需求也是不重要的或是可有可无的。
√ 两周的迭代有产品增量的劳动成果给客户展示，寻求反馈，不会“跑偏”太多，及时校对，这样做看似增加了成本（overhead）, 但避免了弯路，避免后期发现可能的大错，甚至全部推翻重来。
√ 新来的需求如何处理？首先我们是欢迎的态度，但条件是与一个大小差不多的合同内低价值的需求置换，这样做的好处，不用改动合同总价，也不用走繁琐冗长的需求变更流程。”change for free”。大家都省事， 给客户省钱，见下图。
√ 固定价格的合同的能否提前终止？比如说客户重新评估剩余的需求没有价值或者ROI太低 ， 这时候如果突然终止合同，对供应商是一个大的损失，人员要闲置（bench time）, 也不公平。 甲乙方合同提前约定好，如果客户想提前终止合同，剩余合同价的一定比例分给供应商（比如30%余款，20%付供应商），客户也节省了预算。“Money for nothing” 这种合同迫使客户排优先级关注业务价值。对供应商来讲最好是pay-as-you-go 模式，供应商团队可以做其它更有价值的项目。
这里有必要澄清一下估算的目的，一个误区，估算不是用来报价签合同的。敏捷估算的目的是：为了跨职能团队的每一个成员在估算的过程中相互学习，对需求的理解达成共识。估算的过程是学习和对齐的过程，随着项目的推进，成员对需求的理解，知识和经验的积累，对先前的估值，团队可以重新估算，重心不是追求估算的多么精准和教你如何去估算。一句话，估算没有对错，千万不要把估算与承诺划等号。
3. Scrum角色在甲乙方的定位
多数情况下PO来自客户方，客户方的PO懂业务有行业知识，关注投资回报。但有可能会忽视供应商的利益。如果PO来自供应商，我们定义为PO proxy, 最大的问题是没有授权做决定，带来延迟成本。PO 代理成为外包团队澄清需求和问题的第一道防线(the first line of defense)。PO 代理如果没有与真正的PO在同一办公室，PO 代理变成了“中间人”，可以想象这个模式：PO-->PO proxy --> 团队；当然客户方如果没有清晰定义PO的角色，那就更麻烦，没有人对最终产品负责。PO的角色定义是关键，这个PO一定能全职在这个产品上，大多的企业没有清晰的定义PO，出现扯皮的现象，或者PO 没有power, 没有动力。
我看到的常见的一种糟糕的情况是这种的结构，业务部门（甲方）+ IT PM （甲方项目经理）+外包团队（乙方）+ 乙方项目经理；甲方有一个IT项目经理对接业务和乙方，这个IT项目经理充当中间人(middle man), 增加了沟通的成本，非常耗时。乙方项目经理大多数情况就是一个“摆设”，或是团队“监工”，或是团队的“保护伞” or “代言人”。这样外包团队很难成长。
推荐的做法是，我们鼓励客户的真正的PO和外包团队直接沟通和对话，去掉中间人。成功的PO一周至少有1/3时间花在与外包团队沟通上。
甲方的IT项目经理角色是有价值的，但要在敏捷项目上重新定位，要么是敏捷教练，辅导PO和乙方的SM, 帮助移除团队搞不定的在甲方的障碍，或者成为团队的一个成员负责甲方IT的技术，比如架构，与团队的工作集成。但不能是项目经理，什么都干都管，充当监工，最后成为“背锅侠”。
ScrumMaster和开发团队来自供应商，SM 通常来自乙方，好处都在一家公司，SM跟团队比较接近，容易辅导。乙方的SM， 我认为没有必要全职（除非客户要求全职），甚至参与一些开发工作，我带过的团队SM 都是兼职的。国内实际项目中我也看到有SM来自甲方的情况，这样SM更容易帮助团队移除障碍，也建立了与外包团队的信任和尊重。
敏捷外包团队是跨职能的，这样的好处是在开始组建Scrum 团队时，不需要打破传统职能型部门的架构，不像做产品的公司转型做敏捷还要重组，我们按照合同去招人（内招和外招），搭建多功能全职的团队。另外，回顾会可能没有必要让甲方的PO全程参加，团队有时候会因为甲方PO的存在，觉得不自在，缺乏“安全感”，要邀请PO参加部分回顾会。
4. 敏捷外包好的实践：
√ 乙方到甲方现场办公， 坐在一起。Co-location 项目已成功了一半。国内好多客户都这么做了。即使做不到，也要定期互访客户。
√ 项目启动时甲乙方所有项目成员共创产品的愿景，理解why, 把业务方，IT人员，外包团队拉在一起做一个两天的工作坊。这样做可能很“豪华”，但收益远大于投入。我辅导过的几个客户都意识到这样做的必要性。
√ 团队在Sprint 计划会议上留有Slack time 5-10%。有一个案例，甲方的SM 鼓励外包团队有10% 的创新和自主时间, 外包团队非常高兴，生产效率反而提高很多。
√ 建立超越团队级别的障碍看板，主要给甲方看， 甲方的IT经理主要专注帮团队解决这些问题。问题可视化是关键，最好客户方的人员跟进。
√ 保证每个迭代PO与团队的需求梳理会持续进行，不打“折扣”。挑选一个合格称职的PO，PO参加迭代计划会议，澄清目标，迭代中不会玩“消失”。
√ 甲方不要微观管理乙方团队每个人的工作，把微观管理交给团队自身来管理。
√ 物理和电子工具的辅助使用，不要放弃物理白板。
5. 敏捷外包文化 – 长期的产品伙伴关系
√ 甲乙方是Joint Venue 的伙伴关系，树立一个产品，一个目标，一个团队，真正的伙伴关系的思维，大家都在一条船上，一起使力“划桨”，停止合同“游戏”，结束各为其主的想法。步调一致，和谐共赢。减少合同谈判和续约的成本，也不用花时间再寻找其他供应商。
√ Scrum的五个价值观成为我们一起工作的文化。特别是尊重的文化。甲乙方的项目关系虽然我们隶属于不同的组织，不影响我们对敏捷原则的拥抱和践行，对一个产品的忠诚度。
√ 项目启动时甲乙方都要邀请在敏捷项目上的成员参加至少一天的基本培训。定期讨论和理解敏捷价值观和原则，对我们的行为意味着什么。敏捷项目上的每个成员buy-in 敏捷理念，过去几年我辅导的客户不仅培训自己的IT团队，开始敦促供应商做敏捷培训，这是双方的事情。
实际上2012年我一手打造的Endeca中国敏捷开发外包团队被甲骨文收购，就是一开始定位我们是做产品的伙伴关系，外包团队对产品的深刻理解，与客户同事关系的融洽，客户文化驱动和做事的方式方法的潜移默化，最终双方得到了认同。
最后总结一下我对敏捷外包趋势的观察：
（1） 外包项目完全可以用敏捷开发。Scrum肯定对外包项目交付好处多多，透明性加倍增加客户的信任。Scrum讲究的就是诚信(honesty), 若没有诚信，甲乙方如何做生意？
（2） 即使是固定价格的项目也不阻止你尝试用敏捷方法交付价值给客户。尽管可能客户还是传统思维，但不要指望客户先改变或以此为借口“我们做不了敏捷”，乙方要想想能做什么赢得甲方的信任？敏捷开发是你马上下手的地方。
（3） 与传统外包相比，敏捷开发已经成为乙方的商业模式和竞争优势，供应商如具备敏捷开发的经验更容易拿单，更有在签署合理公平的合同上的话语权。供应商（乙方）要抓住时机，下功夫投资打造你的敏捷团队，这就是你的资产(Capital Asset)。
（4） 团队一旦采用敏捷开发模式，很少愿意再回到旧的瀑布模式。
Jim Wang
写于2020年5月4日疫情期间
参考资料：
（1）A Scrum Book: The Spirit of the Game 1st Edition， by Jeff Sutherland, James O. Coplien, Kiro Harada, Joseph Yoder, June Kim, Jens Østergaard etc.
（2） Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams
Jeff Sutherland, Ph.D. Guido Schoonheim，Maurits Rijk
Module的工程师主要分成两大类：制程（工艺）和设备。也就是所谓PE和EE。基本上无论哪个Module都会有这样的两类工程师。工作如下：
设备工程师主要负责的是机台的状况，他们要保持机台始终处于比较良好的Status，从而提高机台的利用率。TSMC在最忙的时候曾经把机台的利用率提到到了110%以上，这样就需要缩短机台设计的PM时间，缩短机台的Monitor时间，减小Down机的几率。
这样设备工程师的压力就很大。设备工程师的On Call通常就是来自于此。如果大家都是混得比较资深的EE，那由于晚上都有设备值班，小问题都能够被处理掉，而大问题也没法处理，可以第二天白天来做。但如果是一群没有足够经验的EE，那么每个人都只能专精几种机台。
结果就是遇到不熟悉的机台出问题，就只好Call人了。半导体,芯片,设计,版图,芯片,制造,工艺,制程,封装,测试，EE在Fab中待的时间要比PE长，有很多routine的工作，比如PM。EE的问题相对简单。
EE有很多机会接触有毒的气体、辐射和化学药品，也容易遭受侵害。Fab里很多耸人听闻传说中的主人公都是EE。记住一条Fab的铁律，任何不明身份的液体都可以默认为是HF溶液，千万不要去胡乱摸。此外特别的区域会有特别的注意事项，各自要注意。
EE主要和PE以及厂务（FAC）的弟兄打交道。不太会直接面对PIE这种Module比较讨厌的人物，也和TD的弟兄没有什么大的过节。由于是机台的使用者，Vendor会常常来和EE搞好关系，如果公司许可，可以有很多的饭局。酒量要锻炼。
EE的工作很累，但并不很复杂，如果加入了一个不错的集体，也可以过的很快活。硕士以及以上学历的弟兄一般不会有机会加入EE的行列，工科的本科/大专毕业生可以绰绰有余的胜任EE的工作。EE做久了如果没有什么兴趣可以想办法转去做PE，如果想赚钱，做Vendor也不错。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）