一起工作，分开就座-InfoQ

要想判断你的离岸外包冒险之旅是否成功，有两个最根本因素：人和过程。有人会说：过程是最重要的；另外有些人将人放在第一位。8 年前，我开始实施近地外包，当时认为流程最重要。我相信，必须要搭建某种像工厂一样的流程，这样离岸外包才能成功。现在，我相信：虽然流程至关重要，但人是最基础的根本。出色的流程加上不怎么样的人，结果必将让你失望。雇佣最好的人，却没有任何流程，结果会让你吃几个。如果你雇的人有问题，他们可能根本不注意流程，而是直接“开步走”。这常常导致各种沟通和项目管理方面的问题。

本文的早期版本曾刊登于《如何组织离岸外包和近岸协作》这本书中，它属于一系列管理远程团队的书籍。

本文是管理远程团队系列文章的第一篇。我将分享的经验，谈谈如何构建适用于远程协作的稳固流程。当人们身处多个远程地点时，必须付出更多精力，阐明团队如何协同工作。在 Bridge 公司，我们研究出一种工作坊，一直将其提供给新客户。我们还创作了工作手册，其中有些章节提到达成远程高效协作的几个关键因素：

流程：我们如何工作？
责任：谁负责做什么？
项目管理工具：我们如何跟踪项目？
沟通：我们如何沟通？频度如何？
绩效：我们用什么来度量绩效和进度？具体如何度量？
编码规范：我们的标准是什么？
时间记录：我们如何记录时间？
形成“同事”：我们如何一起工作，发挥潜力，成为朋友？

我会讨论其中三个因素：流程（“我们的工作方式”，包括规划、需求和测试）、责任和绩效。大家可以在我们的网站下载免费的工作手册。

1. 流程

软件项目中，很多人会自然地“马上开工”。他们会在东欧或是印度选择一个合作伙伴（后者要在招投标上用很多时间），然后就“开始工作”、“启动项目”。尤其是针对固定价格的外包项目关系，他们会期望合作伙伴知道如何着手项目。需求写完了，也发给供应商了，我们现在可以坐享其成，等着成果在指定日期交付就好。但是，这可能吗？

当然，作为外包的“买方”，你有权期望外包合作伙伴知道外包的工作方式。远程团队必须了解如何满足你的要求，让你的项目成功。而且很可能他们也是如此。但是你呢？

他们了解你的具体情况吗？知道如何让外包过程符合你的具体项目吗？当然，很多外包厂商都是技术公司。他们开发能力很强，但这不意味着他们可以保证复杂的协作过程顺畅无阻，这个过程要跨越文化、时区、不同语言的差异。最近，我跟荷兰一家大银行的 CIO 聊天。他告诉我：只要是把征求计划书（RFP）发到离岸厂商那边，得到的回应一定是深入技术细节的解决方案。而他一直在寻找的公司，要能告诉他自己如何交付他需要的解决方案：他们会用什么样的人，建议使用什么样的流程，建议如何与在岸的产品负责人协作。

在离岸团队开始执行项目之前，在他们开始分析你的需求、撰写代码之前，你必须召开一次会议，离岸和在岸团队都要参加，大家一起讨论具体工作方式。不妨从你们各自当下的工作方式开始。因此，两种方式可以在这里碰撞——你们的工作方式、厂商的工作方式——这意味着其中某一方（或者双方）要调整、适应彼此的行为。

软件开发是创造性过程。指望往一个标准化过程中灌入需求，然后得到完成的产品，这对任何客户来说都是一个美梦。但这不是任何创造性过程的工作方式。过去，软件开发遵循建筑行业的构建过程，人们制定出了瀑布模型。这个模型主导了 20 来年的工作方式。今天，一切都要“敏捷”。创造性过程自然就是敏捷的。本文中，为了简化起见，我将会使用瀑布和 Scrum 作为流程因素的两个极端加以讨论。

你现在如何工作？

你遵循的过程接近瀑布模型吗？还是你们已经完全敏捷了？你们是不是像很多公司一样开始使用 Scrum？也许你们已经应用了极限编程或是看板？在 Bridge 公司，我们构建的远程团队专为某家公司的内部 IT 部门服务。我已经体会到：最具挑战性的客户，是提供服务的公司（相对于构建产品的公司而言）。尤其是小型服务提供公司，比如互联网公司，要想让离岸发挥效果，非常具有挑战性。而且，在大多数情况下，客户强制要求使用固定价格。也许得使用瀑布式模型才能按固定价格报价。如果你是规模比较大的服务提供商，那就完全不同了。基本上，大型服务提供商要为客户的长期项目构建“产品”。因此，在打造流程的时间和灵活性更强，可以得到期望的产出。这种情况下，合作双方都有更多时间制定联合协作流程，即便价格或时间有限制，项目还是更易于成功。

现在，请用一些时间，梳理一下你自己真正的工作方法。我自己的经验是：Scrum 基于某些原则，而不是定死了的流程。因为人们会遵循“原则”，所以就有很多种方式可以产生工作方法。很多公司因此认为自己在实施 Scrum，实际上他们用的是瀑布或是看板，或是其他类似的过程。如果你希望与远程团队建立顺畅、完整的写作方式，你必须告诉他们（在你自己眼中）自己的工作方式，以及你希望的工作方式（你希望在自己流程中看到的改进）。很多时候，工作方式都没那么正式（也就是没有文档或流程图）。自己团队中的人们在潜意识中已经形成一套工作方法。然而，新加入的远程团队必须从意识上认识、适应新的工作方法，这个方法也是你们彼此同意的。所以，不仅要讨论工作方法，还要用笔写下来，画下来，让人人都能看到，从而产生责任感。如果仅仅以口头方式说明工作方法，开工之后，可能会发现大家对其理解彼此不同。

你如何估算工作？

瀑布模型有一个十分严重的问题，就是对项目的估算。不妨看看你个人的规划。你个人如何规划自己一周的工作？如果你看看这周的事务优先级，是否能准确估算出每一项要占用多少时间？要是估算接下来这个月呢？要是接下来这一年呢？要想知道估算的准确程度，比较你的预计时间和完成任务的真实使用时间。可能你会发现：真实使用时间是估算时间的 2-3 倍，每个季度是 5-10 倍。

我们希望软件开发者能给出比较好的估算，还发明了各种方法让其更准确。但是，我们是否的确更接近真实情况了呢？一般来说，为客户完成的项目需要提前估算。因此，常常使用简化的计算过程，以加快投标进度。既便如此，你也不能无视：即便赢得了投标，到了某个时间点，离岸团队还是要估算工作量。而且很有可能他们已经偏离了估算，那时你已经偏离预期进度了！

如果你以这种方式工作，而且无法改变瀑布模型。那我建议你寻找使用相同流程的离岸合作伙伴，他们已经习惯使用固定价格方式，他们的流程也能符合你的估算。不过我还是推荐尽可能改变这种流程。你可以先向当前流程中引入某些 Scrum 的元素，然后一步步改变流程，也许可以跟你的离岸合作伙伴同步进行。引入敏捷的原则和 Scrum 需要花时间，要培训团队如何实施 Scrum 时间，让你的某些雇员认证成为产品负责人或是 Scrum Master。这个变化会需要几个月，并且可以在与远程团队开始项目之前，让离岸合作伙伴帮你一起建立流程。

如果你正在使用敏捷或是 Scrum，那就最好不过。你可能使用规划扑克（或是其他方法）来估算每个用户故事，整个团队都要认可这些用户故事。如果你需要估算整个项目，可以大概估计一下项目范围，然后利用 Scrum 的灵活，在每个 Sprint 中调整工作量，最终完成项目范围内的工作。理想情况，当然是整个团队，包括离岸团队，都能加入 Sprint 规划，同时认可项目范围。

我们如何定义需求？

知道需要构建什么，而且能用清晰的需求文档加以表达，这是软件开发最具挑战性的方面之一。再加上遥远的距离，以及不同时区、不同语言、不同文化的差异，难度大大增加。

瀑布模型假设我们可以事前想清楚要做什么。我相信，如果时间足够多，我们可以做到，但也只能完成 75%-80%，所以，风险在于：当你完成某些功能时，它可能已经过时了。如果我们在远程协作中选择这种方式，那就必须要提前规定清晰的指南，说明如何制定需求规范。要回答类似下面的问题：

需求规范中哪些细节最为重要？
我们是否要创建单独的技术需求规范？如果是，哪些规范最重要？
离岸团队如何参与到需求规范的制定或扩展？
针对需求规范的附加条件、优先级变化、删除，如何讨论、达成一致、保存？

这些问题的答案必须有明确的纸质（或电子）记录，这样每个团队成员对于需求的设定方式才能有清晰理解。要是能附上一份“理想需求”的范例作为补充，那会很有帮助。

最根本的问题是：谁负责创建需求？一般都是在岸团队负责，因为他们更接近客户。但是要想清楚。如果在纸面做出某些承诺，那一定是经过了深入思考，这些思考来自于此前与客户的多次讨论。然而，远程团队却没有参与到这个互动中。所以，这些需求文档对你很清晰，对远程团队却如迷雾一般。要让远程团队尽量早加入解决方案和需求的制定，这样他们就更易于理解这个过程，知道要构建的东西。

如果你在使用敏捷开发过程，讨论和会议就是你的起点，而不是需求。至于需求，整个团队都参与到制定过程中，而不仅仅是某一个人。

首先，产品负责人会与客户或用户对话，将需求转换成用户故事，然后 Scrum Master 和开发团队（设计人员、开发者、测试人员、架构师）会进一步探究每个用户故事。要明确理解这种流程在你公司内部的机制，这很重要。

我观察到：有些公司称之为“Scrum”，即便他们没有真正遵循这个方法。这么一来，举个例子，产品负责人（或是既当产品负责人又当 Scrum Master 的人）就会跟客户讨论，详细描述用户故事，预先描述解决方案，有时会深入到技术实现细节，然后会将“用户故事”发送给开发团队。如果你这么做，就等于创建了“迷你瀑布”模型。虽然这种方式能出成果，但你和远程团队一定要明白：使用这种模型，会影响团队的参与程度，以及团队对需求的理解深入程度。

如何做计划？

电子书《如何组织离岸和近岸协作》中，有整整一章讲到规划，本文只提出一些要点。

如果使用瀑布模型，你可能要制定出使用工具（比如 Microsoft Project）创建项目计划的标准化方式。要思考制定计划的方法，这有助于为远程团队提供明确的书面理念。你是否要让离岸团队参与到规划活动中？他们是否会创建设计，还要经过你批准？你是否创建供他们执行的规划？

在 Scrum 中，你是否认真进行了 Sprint 规划？整个团队都参与到规划活动中了吗？如何计算 Sprint 中有多少个小时可用？团队成员能够将 80% 的精力用在用户故事的高效开发上吗？或者至少能保证 50%？谁为 Sprint 中的工作负责？

谁负责测试什么？

测试是软件开发中的灰色区域，各个公司的实施方式完全不同。很多公司希望他们的开发人员能测试自己的工作（但这么做如何做到“验收”？），然后项目经理会完成某些最终测试，再发给终端客户或用户。大型团队有专职测试或测试部门，他们评估开发完成的功能或是用户故事。此外，有些人使用小组测试，在 Sprint 最后一天，整个 Scrum 团会聚在一台电脑前共同测试。

这里的重要之处在于：记录组织当前的测试流程。你希望每个人都做什么？面对与远程团队成员的合作，你在测试上要做出哪些调整？验收条件，或者“完成”的定义是什么？把一切都写下来，与远程团队讨论，对于如何完成测试，要得到清晰的共同理解。

2. 责任

如果把团队放在一起，让他们“马上开工”，他们能否成功完成项目，很难说。在我看来，在团队开始工作前，一定要讨论清楚各自负责什么，然后写下来。

公司层面是最佳的起始点。两边的责任是什么？与项目有关的首要问题，是项目或产品的相关责任。谁负责规划、设定截止日期？谁负责项目管理？要想回答这些问题，必须划分明确的界线，而且要以契约形式确立。其他因素包括：谁负责管理人？谁确保每隔 3-6 个月团队成员就可以跟管理者讨论自己的个人发展？谁负责培训的决策和组织？

在 Scrum 中，产品负责人和 Scrum Master 是最重要的角色。在瀑布模型中，这些问题都差不多，虽然角色命名有所差异。

在离岸语境中，分配职责最有效的方式，就是让产品负责人在岸，尽量接近客户。离岸团队可以有第二个项目负责人，不过要是项目不大，这么做有可能更复杂。Scrum Master 离岸或在岸都可以。常用的方案有：

A. 在岸产品负责人与离岸 Scrum Master（加上团队）对话。

B. 在岸产品负责人与离岸产品负责人对话。

C. 在岸 Scrum Master 与离岸 Scrum Master 对话。

D. 在岸 Scrum Master 与离岸开发团队对话。

理想状态下，客户或最终用户会在 Sprint 规划会议中与整个团队对话，要是能与（虚拟）Scrum 团队（无论是离岸、在岸还是混合的）坐在一个办公室中，就更好。可是，很多时候，产品负责人会跟客户对话，然后将所有的用户故事告诉团队。无论选择何种方式，整个团队（包括产品负责人和 Scrum Master）都要在 Sprint 规划中使用视频会议。

为了保证责任界定清晰，要回答以下问题：

谁负责描述用户故事的实现（从功能以及技术角度）？是离岸还是在岸 Scrum Master？
产品负责人能描述多少内容？
在 Sprint 中，谁负责决定开发什么、何时开发？如果那个人因为时区差异找不到该怎么办？
谁负责做演示？
演示的目标人群是谁？
谁主导功能测试？

为了完成每个人或者每个角色的责任列表，我会继续阐述如下问题：

离岸协作中有一个关键角色——“流程经理”，也称为“交付经理”、“质量经理”或类似名词。此人的责任在项目之外，其核心工作是确保在岸和离岸团队顺畅沟通。比如，在比较大的环境中，在岸和离岸团队中都有这样的角色会更好。这些流程经理每周开会，评估当前的整体表现。他们不会深入到每天的项目进展细节中，而是有相对外部的视角，为团队沟通的方式提供有益的建议，他们会核查流程，看看是否偏离正常方向；他们还可以保证项目符合合同中的相关条款，以及诸如此类的事情。

我们有一个开发在线约会平台的客户，当时我们使用了上述协作方法。产品负责人位于客户在苏黎世的办公室，Scrum Master 也是。在岸流程经理位于荷兰，离岸流程经理位于乌克兰的基辅，跟团队在一起。CEO 一开始担任产品负责人。在每周定期的会议中，我们发现一个问题：CEO 有时候找不到。团队常有用户故事的问题，但他总是没法直接联系上，这会导致进度延迟。我们决定，苏黎世办公室中需要一个新的产品负责人。这个新产品负责人加入之后，障碍数目迅速下降，开发速度得以提升。很多时候，如果流程经理不能每周见面，这样的问题可能要几周乃至几个月才能发现，拖慢项目进度，影响团队之间的关系。

3. 绩效表现

在公司层面，基本上只有一个问题：这种写作能否交付我们需要的价值？在 Bridge 公司，我们每周都会来回问这样的问题。这不是一次就能回答的问题。在岸和离岸团队必须适应写作。目标是构建合作伙伴关系，要一起写作，要创建协同效应，达成 1+1=3 的结果。毕竟，这才是最重要的。当然，你也可以度量响应时间、工作效率，或者其他与你的 SLA 联系在一起的变量。

如果有多个团队参加多个项目，项目主管也不一样，同样问题也可以在团队层面提出。

需要评估的最重要的绩效，就是个人层面的绩效。团队由人构成，所以我们需要有人评估每个个人的技能。如果（离岸或在岸的）Scrum Master 可以每个月或者每季度完成类似评估，那就最好不过。在 Bridge 公司，我们让客户每个月评估单个团队成员。我们使用 1-10 的评分，以确保清晰明白。一般来说，我们使用下列问题（根据项目某个方面的重要性不同，我们会修改问题）：

这个开发人员能否：

满足你的期望？
及时响应你分配的任务？
自己做出有效决策？
理解产品或项目的商业模式？
以开放心态接受反馈？
在答应的时间进度内完成工作任务？
适合你未来的项目？

除了这些“正式”的绩效评估外，还必须建立有节奏的会议。如果你遵循 Scrum，每天的站立会议中、在演示时、在回顾会议中，都可以为团队提供反馈。我们也有与流程经理每周的会议（见前述内容），其中每个离岸地点都会像前文一样，给协作打分。每个季度，我们会与每个成员、我们的 HR 经理、流程经理等，单独开会。某些时候，我们的客户会加入或者接手这个季度个人发展会议。

对于更大规模的企业，《如何组织离岸外包和近岸协作》这本电子书有一章很有价值，讲到 Erwin de Bont，其中提供了一个度量绩效和 KPI 的框架。