本文是敏捷外包工程系列的第二篇。（，，，）
敏捷开发整体上适合小团队、产品研发（所以才有product owner一称）的环境，而外包软件开发中常常存在的则相反，因此在创建团队的时候要充分认识到这一点。
Product Owner产品负责人的人选
听到无数次有人说“我们的Product Owner就是客户，因为所有需求都是客户提的”，其实这样做极度危险。
Scrum开发理念提出前的环境大致如此：一小群开发人员（3～9人），内有项目经理发号施令，外有销售人员指手画脚，团队加班加点苦不堪言。因此Scrum提出了要自组织的概念，接下来发生的故事大致如此：自组织需要代价；结果导致分权；开发组获得的权力是计划与技术；开发组放弃了需求管理权。剩下的是，谁应该得到需求管理权？
在产品研发环境中，这一职责自然地落到产品经理（或其他类似职责）手中，他们将与市场、客户、高层沟通，完成需求管理工作。
在项目开发环境中，由于没有为需求负责的产品经理，所以大家自然而然地想到了客户或销售人员。
其实，Product Owner负责的不只是把需求说出来，还应该为需求背后的商业目标负责，而这一点客户或销售人员做不到。
完整地解析Product Owner的职责，将包括：
1. 描述需求
2. 为需求排序
3. 为客户价值负责
4. 为客户群价值负责，即长期、广泛的客户价值
5. 为由满足客户价值而带来的乙方企业商业利益负责
客户或销售人员可以实现123，但对45则不会当作首要驱动力，极易出现问题。单个客户会因为过于突出自身利益而伤害企业的的其他客户，销售人员则会因为过于关注自己负责的客户而伤害企业的其他客户，并进而影响其企业的整体利益。
鉴于这个是软件外包中存在的主要人员问题，下面将以主要篇幅加以描述。
为了满足对45的管理，以下人员适合担当PO：
1. 乙方的项目经理
其工作方式是与客户沟通需求，确保正确实现客户价值。但其绩效应由企业判断，也就是说“通过实现客户价值，带回来多少企业收益”是其主要考核点。
其工作心法受到两方面制约：一方面要满足客户保证收款，一方面要保证利润率。
以往一般的做法是销售/开发割裂开，前者从合同总额提成，后者没有提成只对进度质量成本负责。结局是如果本来100万能做的单子被签成50万，销售人员仍然有提成（个人认为把两个100万的单子都当50万赔本卖掉，比把其中任何一个100万卖掉的难度都小，再加上“100万”这个数字谁也无法检验，这导致销售人员的心法越来越倾向于前者），而项目经理则几乎只能面对失败。
合理的做法，是以各种方式将两者的责权交织一下，交织的方案试情况定，下举两个实际例子。
A. 某电信研发企业
其销售绩效机制不明（当时笔者没有问）；项目组拥有X%的合同总额作为奖金。
其运作方式是以季度为结帐周期，每月商讨需求，配合功能点报价作为内部工作量计算的参考依据。由于采用短周期交付，项目组比较容易逐渐建立“生产率”的概念，即使这种生产率不是准确量化的，所能提供的参考价值也能保证不会出现太大的偏差。这里提到的“太大”的偏差包括准确性上的百分比偏差，也包括合同总额的巨大偏差。
为了保证短周期交付，他们采用敏捷开发方法。
点评：未来软件开发将更多地向服务而非技术项目转型。前者将更多地使用连续式的交付方法，需求将更多地逐步被发现而非一次发现，在此类项目中实施敏捷将是一个趋势。在一些业务变化很快的领域如电信行业，这已经成为现实；银行业在迈进（尽管他们从来不提“敏捷”二字）；政府项目处于落后状态，有其政策变化不会太快的因素。
B. 某产品+实施企业
其销售与项目经理合二为一。绩效机制是从净利中提成X%，需要扣除各种实际费用和实施费用（包括实施和售后的人工费用）。若提成已经全额提取，而又发生了费用，则记账在下一单中。
其运作方式是销售全程乃至在实施完成后仍关注客户和项目，一则需要客观地推测实施所需成本（可比照为研发所需成本），二则“下一单记账制度”促使他们不断促进客户二次采购产品或服务以平掉费用。
点评：在项目合同洽谈的早期如何估算项目是个难题，这家企业也不例外（实际上国外已经解决并且应用地很好，国内也正在制定国标，在以后的早期估算篇中详述）。但即使没有量化的方法，当制度设置合理，其导致的心法也将起到很大作用。因此切勿因为没有方法而一“叹”了之。或者反过来说，无论你用什么精度的神奇方法，如果销售的心里一心想的就是把100万弄成50万卖掉，这个神奇方法就一定会失败。
2. 乙方的部门经理、区域经理、行业经理
这些人不适合担任一线PO就是负责需求收集与传达的人，而是适合组建PO团队（在139团队系列中有描述，本博文完成时尚未编写），并担任其团队领导。
常见的情景是销售人员或项目经理都希望将自己的项目重点对待，多投人多投力，或者为自己的客户多制作一些免费的“开拓性功能”由公司承担成本等等。这时候需要更高一个级别的人来把控。
此人必须站在更高更广更长期的位置来把控走向，因此为其设置的绩效也往往更长期，乃至将其职位的升迁作为主要绩效回报方式，由于外包企业组织庞大，这种方式往往可行。
Scrum Master人选
1. PPQA过程与产品质量保证人员
如果是产品研发，我会推荐项目经理，但在外包企业中，往往有上百乃至上千的项目经理，让他们能以统一的方式运作项目是非常困难的，甚至连培训的费用都很惊人。
很多项目经理还会拿敏捷方法对抗原来的CMMI方法，造成矛盾。
PPQA是原来CMMI体系下的角色，人员配比一般为1～2%左右比项目经理少很多，如果让他们同时了解CMMI和敏捷，会对公司制度贯彻带来极大便利。
如果公司没有过CMMI，但也有过程改进人员，则一样适用。
风险在于做CMMI的时候一般心法都比较“死”，常常喜欢条文化、制度化，而忽略了实用化。因此PPQA的组长（或其他更高负责人）的要求很高。
“找不到这么好的人怎么办？”这是个公共困难也没有太好的答案，唯一提示是内部培养永远比空降更好。这并不是培养世界级的科学家的过程，2～3年足以。
2. 项目经理
小公司或重点项目可以考虑。
团队
这个和产品研发基本一样，唯一的问题是有时规模较大，人员流动率高，还有一人多项目问题。
1. 大规模团队
请参考139系列文章（本文编写时尚不存在）。
部分地解决了这个问题。
解决思路是靠师徒制度来维系较大团队的沟通问题，并依靠其学习机制促进团队的扩张。
2. 人员流动率高
部分地解决了这个问题。
解决思路是尽量保持组长/小组长（师傅）的稳定性，他们人数较少，给以较高工资比较可行。另外“成为技术主管”的需求被满足，也可换取更长的留任期。
3. 一人多项目
很多企业都有的问题，但实际上是一个很差的实践，尤其在没有建立项目群管理的时候。
简单的数学计算是：倘若10个人参与10个项目（每人都参与每个项目）需要10个月让所有项目同时完成，则如果让他们10个人同时负责1个项目，待完成后再进行下一个项目，则不用10个月所有项目都可以完成，因为减少了“思路的奔波成本”。当然这是理想情况，因为如果换成100个人100个项目，总不能让100个人同时负责1个项目吧。
解决之道之一是尽量保持正在启动项目的数量不要太多。在故事板的应用中就有一个最佳实践：同时开工的故事数不能太多，做完一个再做一个，因为会分散精力。项目的尺度比故事大得多，问题也会更严重。很多时候会被所谓迫于压力而提前启动项目，则合理的顺序是先让139团队的组长进入，其次安排小组长进入，最后安排组员进入。这样组长/小组长就可以被认为“长期呆在此项目中”，而不会面临太多切换问题。组员的工作相对深度较小，受到切换的影响小。
解决之道之二是尽量保持高手的稳定性，比如每个高手可能只串1～2个项目，在他们忙的时候可以申请新手帮忙，这些新手则可能串更多的项目。高手的注意力集中了，项目的质量、进度都有保证。早期微软曾经做过测量，发现稳定的团队比临时团队的效率高50%，换言之即使稳定团队每工作一年闲着半年，也比让他们解散分散到其他团队强。在外包公司闲半年是不现实的，但是保持核心骨干的稳定还是可行的。
外包工程人员结构的核心是Product Owner的人选，必须认识到PO是企业和团队的一员，他从技术上到需求上到商业目标上，都应该是首先服务于企业和企业利益，其次服务于客户和客户价值，并通过后者来成就前者。
由于人数众多而且多数在CMMI体系下已经建立了管理方法，推荐外包企业将原有CMMI过程改进人员培养为Scrum Master，以便于将CMMI与敏捷完美结合。
“一人多项目”的问题可通过团队的层级结构来解决，应尽量保持组长/小组长不要太过频繁切换。
其实在选定人员之前就早应该解决的问题是：敏捷鼓励变化鼓励创新，但倘若我在做一个定额定期定需求的项目，敏捷开发到底有用没有？这是下篇要讨论的话题。
点击下载免费的敏捷开发教材：《》
