离岸交付：分布式团队协作指南

版权信息

书名：离岸交付：分布式团队协作指南

ISBN：978-7-115-49165-7

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版权

著　　　　曲正平

责任编辑　杨海玲

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内容提要

本书的内容源自作者的实践经历和工作积累。在长期的实践中作者发现，越来越多的离岸交付需要适应敏捷开发的模式。本书结合分布式团队沟通、协作中的痛点，系统地分析了很多离岸项目虎头蛇尾的原因，并给出可供参考的解决方案。对于很多公司和组织头疼的如何让分布式团队推行敏捷的离岸交付的问题，本书给出很多成功经验。此外，本书还系统介绍了建设自组织团队的一些措施和方法。

涉及离岸交付的软件组织以及其他各类存在分布式团队合作的软件组织都能从本书中得到很多有价值的提示。本书适合开发人员、测试人员、需求管理人员或项目经理等参考阅读。

序一：认认真真做交付

三四年前，我和正平一起吃饭，席间他提到要写一本关于离岸交付的书。我听后心中暗喜，心想终于有人要写这个主题的书了，而且还是这么适合的人。当时我和正平都在ThoughtWorks（一家推进敏捷实践并为客户做定制化软件开发的公司）工作，已经共事七八年了。我们都经历了无数不同背景、不同领域的客户，对于软件交付的个中滋味自然体会颇多，这也是我们最大的共同话题。后来我们都分别离开了老东家，而我的身份甚至从“乙方”直接变成“甲方”。身份的转换让我有机会以更全面的视角来审视软件交付，同时也产生了更多的困惑。半年前，正平找到我，告诉我他准备了两年多的书终于要付梓出版了，于是我一口气读完了书稿。

分布式团队

从北京飞到大阪不到3小时，从北京望京开车到南三环有时需要两小时，而去看望住在不同楼层的邻居（或同事）可能要几个月。如今我们很难用“时间”和“距离”来判断一个团队是否是“分布式”的，而且我们总是惯于乐观地估计团队、个人之间形成壁垒的速度和程度。

可是正像本书中引用的数据——30米， 一旦超出目光所及的范围，就会产生沟通障碍，主动沟通的次数将会降低，沟通效率会快速下降——很不幸，你已经在面对一个分布式团队了。我们不久前有一个团队，因为办公室的扩张，所以全部被分到距离200米以外的另一栋楼中，于是这个团队的话题像人间蒸发了一样。后来这个团队不得不花很大的力气来克服沟通上的断层，效果也是时好时坏。

虽然这本书的书名是关于“离岸”这种最“极端”的分布式团队的，但是它尝试解决的问题却更广泛地存在于很多距离超过30米的团队中。

伤不起的供应商

我的前东家一直执着追求卓越的软件交付，我在那里待了近十年，觉得大概软件开发团队也都是差不多的吧。自从从“乙方”转到“甲方”之后，我有很多时间和不同背景的供应商的软件交付团队打交道，也算是体会到了“项目多了，什么团队都有”。

我不喜欢讲道理， 不如就说几个故事吧。

在我刚开始与不同的交付团队接触时，总是习惯于要代码库的地址，这样可以对团队的能力有个更全面的了解。然而这个简单的要求几乎没有被顺利地满足过，理由也是千奇百怪的。这其中有几个团队竟然从来不用版本控制工具，而是用共享目录来保存代码。还有一次，在某个公司战略项目的代码审查会议中，我望着空空的测试目录，问开发人员：“怎么没有单元测试？”“什么是单元测试？”对方一脸茫然地看着我。有很多团队的技术主管的个人电脑还会有个特殊的职责——每当某个版本完成测试后，要在他的电脑来构建、打包一个可以部署到生产环境的软件包。在交付的过程中，类似以上这些不遵循规则、近乎手工作坊式的生产方式不胜枚举。

尽管每家供应商的水平参差不齐，但总体来说大多都是流程极度不规范、产品质量低、维护成本居高不下、某些从业人员的综合素质也令人担忧。在这背后，可以看到的是供应商普遍在追求利益的同时缺乏对员工成长的关注，以及故步自封、不思进取的态度。这些现状与专业的软件开发工程团队的差距实在是太大了。

扶不起的“甲方”

但凡谈得上雇用供应商的公司，几乎都是“大”公司。然后，或多或少都有“大公司病”，症状的程度就因公司而异了。我们在各种商业文章中不难找到对大公司病的描述，如厚重的部门墙、官僚主义、不对等的权利与责任、安于现状、墨守成规、创新能力低等。我们发现，把这些问题直接放在IT部门，几乎也不需要修改。

其实，看看前面供应商的诸多问题，很多都是被“甲方”惯出来的。“甲方”公司自身不求改进，只希望一直待在多年养成的舒适区中，又怎么能指望别人来改变呢？当然并非所有的公司都如此固执，正好相反，越来越多的企业在积极寻求变革自己的IT部门。这固然是传统企业向数字化转型的大趋势下的必然，然而这条道路并不是一帆风顺。

我所在公司的IT部门，就属于希望积极改变自身的一员。不过撬动几百人的传统IT组织还需要供应商的协调行动，在这个过程中有太多的东西需要尝试和改变。而正平的这本“离岸交付”无疑提供了翔实的、可操作的指南，可以帮助团队少走弯路。这些内容都是他十多年摸爬滚打的实战经验，而非“光鲜”的咨询师在PPT里的“金句”。

甲乙方的新关系

其实我不太喜欢“甲方”“乙方”的讲法，觉得这给双方带来了对立。不过中文也没有什么更好的描述。外包的双方长久以来都是被合同、需求文档、验收报告、PPT文稿分割开的。甲方从来不必关心乙方交付的细节，乙方也不必关心甲方的真实想法，双方只要在报表和数字上达成一致就万事大吉了。

可是，随着这些年传统企业纷纷向数字化转型，软件在企业业务中的重要性越来越高，而软件交付面临的挑战也越来越大了，这样就需要双方建立起新的协作关系，开诚布公，共同改进。甲方必须关心乙方的交付细节，必要时还要提出改进建议，而乙方也要主动发现甲方真正的价值关注。这个过程对双方显然都是不小的挑战。正平在这本书中以务实的笔调，娓娓讲述了一个专业的定制化软件开发团队应该如何认认真真地做好交付这件事；正平讲给大家的经验，可以帮助我们找到改善软件交付的思路和方向。

韩锴

戴姆勒大中华区投资有限公司首席IT企业架构师

序二：理想的软件交付

工作久了，我发现很多工作中的问题，其实都是来自人的问题，或者更确切地说，是人与人之间沟通的问题。每个人各自所在的立场、各自背后对事情的认知以及各自表达和呈现效果的不同，都会产生“巴别塔”之效果，即使大家说的是同一种语言。

而这样无奈的事实被投放到软件开发这一需要创造力和多方协作的范畴，尤其是在规模越来越大、距离越来越远、节奏变化越来越快时，需求和实现的落差就会伴随沟通的无力越来越大。

因此，当正平在ThoughtWorks博客大赛中写作《离岸交付的今天和明天》，并告诉我他正在编写一本离岸交付的书时，我由衷地为他的行动点赞。

“离岸开发”由来已久，不少组织在寻求软件实现的时候，基于成本和专业性的考虑，往往会考虑独立、简单的交付方式。但这15年来，伴随着敏捷在中国的发展和深入人心，直至居于主流地位，它所推崇的实践和理念也切切实实影响了“离岸开发”的存在。

崇尚面对面沟通、寻求积极的反馈机制、可视化度量、消除浪费，甚至是自组织团队，我很难把这样一本集大成的作品简单地归结为只适用于离岸开发这一种形态。本书汇集了正平10年来的工作经验，以及ThoughtWorks极丰富的交付体验。

团队富有动力、受到客户信任，一直是我理想中的软件交付状态。虽然这些年国内同行们的做法一直乏善可陈，但我确信，我们可以从本书中找到更正确做事的方向。

谢谢正平。

张凯峰

《ThoughtWorks洞见》主编

前言

2005年对我来说是一个分水岭。

在这之前，我在一家国有企业里从事了3年软件开发工作。这个时期，软件的好坏完全取决于软件工程师的个人能力。软件的质量依赖于生产环境负责联调的人的测试，联调人员同时负责焊接电路板和测试无线发射信号。

在这之后，我到了一家软件外包公司，由于没有受过系统的训练，第一个项目就稀里糊涂地以失败告终。这是一个仓储管理系统，虽然拿到的技术文档我基本能看懂每个功能是什么，但是说实话，直到现在我仍然不知道最终用户是如何使用这个系统的。回顾这段经历，我发现经验不足和缺乏一定的指导，是造成这一失败的主要原因。首先，我们对客户期望值的把握并不准确。因为当时考虑要尽可能按客户的要求把项目做好，所以基本上是客户说什么，我们照做什么，很少自己做决定。随着项目的推进，我们的人也一直都很忙，但能够阶段性交付给客户的东西还是很少。再加上我们与客户的沟通基本以电子邮件为主，会议沟通只有每周一次的电话会议，而且会议沟通主要用于解决遇到的问题和安排下一周的任务，除此之外就再没有其他沟通了。

上面这个项目失败之后，下来的人马上接手了一个新项目。还是同样的人，同样服务于海外客户，最终这个新项目却十分成功。其主要原因是，我们总结了上一个项目的经验教训，应用了当时刚刚接触的敏捷开发方式，为了提高沟通效率，我们还到客户现场做了一次访问。在做访问的过程当中，我们应用了很多后来被证明非常有效的实践方法，如每天的早会、测试驱动开发、迭代式开发、尽快交付客户试用、收集反馈、采用JIRA这样的缺陷管理系统等。当年这些方法对我们来说都是理论性的东西，我们是在摸着石头过河。最终，原计划6个月完成的项目，提前1个月就交付给了客户，当时这在公司内部引起了轰动。我们按照老思路给工作留出很多缓冲时间，是特别给交付前测试和缺陷修复工作预留的。结果发现，最后没有太多的问题需要修复，这使我们对测试驱动开发第一次有了感性的认识。不知道当时哪里来的勇气，当领导问我要不要再测试两周时，我说：“平时都测试到了，而且最近一段时间缺陷的数量一直呈下降趋势，已经非常稳定。”一年以后，有一天我意外收到公司总监转发的邮件，大体是说，这个软件经过一年的上线使用，用户不但没有报告一个问题，而且表示这是他们公司最好用的软件之一。

你可能想到了，是的，我陶醉了，即使现在回忆起这段经历，仍是满满的幸福感。所以，流程的改进、沟通的加强、持续的反馈确实能够影响软件的交付，即使用的是离岸团队的同一批人。

后来，我们接触了更多的客户，参与的软件交付也从交付独立的软件，变成了与客户团队成员紧密合作，在共同交付软件的过程中，同时向客户团队传授我们的方式方法。在此过程中，我们也发明并应用了更多有价值的实践，如项目快速启动方法、持续集成、持续交付、行为驱动开发（BDD）、精益、看板等。在践行这些核心实践的过程中，我结合离岸团队的特点也找到了一些适合分布式团队的“微实践”。例如，电子邮件沟通的技巧、如何与客户想法保持一致、远程站会的小游戏、访问客户现场、平行角色沟通、质量内建、适合分布式团队的工具、定期开发成果展示、可视化一切、减少分布式团队的浪费、用同理心思考、处理冲突等。这些技巧和实践的应用，虽然微小，却能够对分布式团队的协作起到重要的作用，集中推广的价值也渐渐显露出来。

中国的软件外包产业经过了十几年的发展，形成了许多规模很大的外包公司，从业人员的数量也很多。三五年前，国内这些大型外包公司还常常见诸报端，他们能够吸引不少高端人才的加入，同时也积累了很多的行业经验。但是现在，这些公司的发展仿佛进入了瓶颈，最近几年也逐渐面临转型或者服务升级的问题。通过对这个行业的观察，我发现，在外包公司生存周期比较长的项目团队，大多是大客户的项目，没有技术难度，有独立的交付团队，只需要按照客户的要求按时做完项目即可。而一些初创公司或者转型公司的项目团队则有较大风险，因为要与客户的相关人员深度合作开发或者面临遗留系统，他们最终的交付往往达不到客户要求的质量，合作过程磕磕绊绊。这样下去对所处团队的每个成员的职业成长也非常不利。

并且，最近几年很多公司的外包策略与十年前相比有了很大的变化。以前，尤其是大企业的IT部门，要求只是维持公司其他业务运转。现在，赶上互联网热潮，因为软件更敏捷、更灵活，所以这些企业希望信息技术能带动整个企业业务创新。他们越来越重视自己研发团队的能力建设，而不是像以前那样简单地把任务外包出去。外包公司如果不提升与客户合作的等级和合作的技术含量，竞争力会越来越低。你可能会说，客户转型会在意这些细枝末节的东西吗？我要告诉你的是，发动机固然重要，但是润滑系统不好、进入的空气不经过滤芯过滤，是会出大问题的。

市面上的书，大的战略方面的、理论方面的团队管理、项目管理的倒是有一些，但聚焦离岸团队协作的却很少。经过这些年的总结，我希望针对离岸协作这一特殊方式对项目的细节进行一些打磨，以达到运转顺滑、延长寿命的目的。本书将针对文化背景、时间、空间都有很大跨越的离岸团队给出建议。至于是客户在一座城市，团队在另一座城市，还是跨国公司，团队分布在世界各地，跨越性可能没那么大，一样可以找到有用的内容。

目标读者

如果你是外包或者交付团队的需求分析师、开发人员、测试人员、项目经理、产品经理，或者有志于成为其中之一的任何团队成员，你将能从本书中学到在一个项目的不同时期可以应用的一些旨在提高沟通效能、掌握准确需求、提高交付产品质量、减少协作中的浪费、形成良好工作习惯等一系列的实践指南。本书的理论很少，如果你已经了解了理论，读到很多地方肯定会有一种融会贯通，或者“原来如此”，再或者“原来不过如此”的领悟。

写在前面

本书中提到的每一个主题都可以扩展成一本书，但是我只做必要的介绍，旨在领你进门，因为我相信每一个人都能够从其他渠道更好地、更深入地在本书之外的地方找到答案。

本书中的多数主题单独拿出来，很多人会觉得很熟悉，甚至是很了解，但在做项目的过程中，多数人却不会把它们很好地用起来，其实用起来的效果是很让人惊叹的。

本书中提到的实践、示例基本都是来自工作中的真实经历，也是我十多年在分布式团队中工作积累的经验。因为真实故事更容易让读者感同身受，并且真实是独一无二的，我的真实一定有我的独特性，而这可能是读者最感兴趣的地方。

正因为你不能经历它们，我才有了写作的动力，希望通过我的描述让更多的人感受它们。书中记录的所有问题和实践，都是离岸团队会遇到的，当然从理论上讲大多数主题不仅限于离岸团队。

希望本书对从事软件外包工作的读者有所启发。当然，即便没有在软件行业，相信读者也能够从服务者的角度看问题，通过阅读本书对自己将来的发展有所促进。经济全球化的发展使几乎所有的公司都需要不同部门和团队的协作，你完全可以把本公司的其他团队当成客户来看待。

在我的职业生涯中，大部分时间处于离岸团队之中，这些年下来积累了不少有价值的东西。随着积累的东西越来越多，终于到了一个临界点，希望把这些东西整理出来的意愿越来越强烈，希望它早日发挥出它应有的价值。

本书主要探究离岸交付的几大痛点，如沟通协作、需求变更（信息不全更容易产生误解等破坏力）、团队和客户以及外包容易出现的问题（如质量低下、交付延期、预算超标）。除了林林总总的问题，还有如何让成功的离岸交付可持续，找到一些共性的东西，我见过太多不同的外包团队重复造轮子的故事。

我们每个人都能比较轻易地得到一些理论知识，这些理论知识告诉我们的是理想情况下交付的过程是怎样的。但是在现实工作中很少会遇到理想情况的案例，我们需要多研究非理想情况下的方法。

如果你读得仔细，一定会发现，本书的内容在有些地方存在冗余。这是因为，当我们从不同维度、不同视角考虑问题的时候，总会有一些问题涉及不同的主题。虽然我可以继续提炼这些话题，减少冗余，在文字安排方面更加准确，但是这样会不利于理解。每位读者读完以后真正的收获，是检验文字的唯一标准，而不是“好多地方没看懂”或者“每看一遍都有一些新的收获”。

如果你有远程团队需要合作，如果你有本土客户需要服务，那么你真的需要好好读读本书。

第1章　分布式团队的现状

在信息时代，随着科技的发展，对人才的渴求让距离不再是阻碍团队发展的关键因素。一个离岸团队的价值，让增加的沟通成本显得微不足道。但是，我们仍然需要在工作中切实践行一些方法和技巧让离岸团队面对的不利因素最小化。离岸的好处是“距离产生美”，虽然距离感产生的优势不多，但是也要好好地加以利用。

在本章中，我们将了解分布式团队协作的发展、组建分布式团队、分布式团队的效益并以一些普遍性的问题为出发点，探讨离岸团队的现状。后续的章节还会针对这些问题给出实践中的案例和解决方案的建议，其中绝大部分案例出自真实的项目经历。

1.1　分布式团队介绍

全球化的发展让我们有太多的机会需要与不同地区的同事或客户紧密地合作。不得不说，互联网的发展使我们有了更多协同工作的机会。

1.1.1　分布式团队的快速发展

分布式团队的概念是从十多年前开始的，源自发达国家的软件企业，这些企业为了降低人力成本，将非核心业务外包到人力资源充足并且人工成本相对较低的国家。在那个年代，外包的软件大多是企业级应用，需求相对固定，要求的开发周期可以很长。

客户要在这些外包服务发达的国家选择一个能提供外包服务的公司，在开始的时候只能通过以下方法。

• 通过外包公司在网络上投放广告。我曾服务过的一家软件外包公司，有一个团队专门根据美国公司黄页一类的资料，给所有的潜在客户群发电子邮件，推销本公司能够提供的服务，展示公司的能力。

• 口口相传，客户推荐客户。这种类型的案例也不少，但口碑的积累毕竟有很大的局限性，对于“to” B类型的业务模式，这不是一条常规的道路。

通过以上方式建立的联系，彼此信任的建立需要较长的时间。如果是一些中小型公司，这时候可能会派人到当地现场考察，毕竟合作可能隐藏着很大的风险。如果是一家大型公司要选择外包服务公司，这样建立的合作方式就更加无法支撑了。随着行业的发展，有成熟的体系和完善的评估方法才是合作的基础。这就需要有一个标准，CMMI认证就适时地出现了。

1.1.2　客户为何如此看重CMMI认证

我们借此机会重温一下历史。CMMI的全称是Capability Maturity Model Integration，即软件能力成熟度集成模型，这是20世纪90年代中期由美国国防部、卡内基-梅隆大学和美国国防工业协会共同开发和研制的工程实施和管理方法。CMMI（包括它的前身CMM）的产生并不是只应用在软件领域，而是面向所有科研和工程领域的。要知道，美国国防部牵头研究出来的这套提升项目管理水平的模型，其初衷是为了管理它们的供货商，以降低成本和保证质量。美国国防部的招标活动带动了CMMI迅速的推广，因为它是一个有5级成熟度的模型，企业很容易对照自己的管理水平确定如何提升自己到更高的等级。当然，更主要的原因是越来越多的招标直接对投标者提出了CMMI等级的要求。因为在当时这几乎是唯一值得信任和有明确操作性的评估模型。企业为了拿到更好的订单，就不得不在这上面进行投入，这也间接地推广了CMMI的应用。

印度公司在这方面的表现尤为突出，对CMMI的推广出人意料地超过了美国。这也造就了印度拥有一大批CMMI达到5级认证的公司，极大地促进了印度软件外包行业的发展。因为有了CMMI等级认证，才有了越来越多的大型项目乃至核心项目的外包。可以说，CMMI对离岸外包团队的规模增长起到了巨大的推动作用，也是世界上离岸团队发展的第一波浪潮。

对于一个软件企业，在取得CMMI认证的过程中，要创建海量的文档，这些文档将证明，该企业在提供产品和服务的过程中采取的方法、应用的实践达到了所申请的级别。评估师是无法根据该企业的产品本身得出在过去一段时间内该企业的项目管理达到了什么水平的。所以，这个评估是一个对过程的评估，好的过程管理一定能得到好的结果。在这个过程中，软件企业一定会聘请一个CMMI认证专家来帮助自己进行标准的解释，通过文档来证明企业的项目流程的管理水平。

企业和团队花了大量的精力在文档的撰写和维护上，这种成本在体量庞大、相对稳定的项目上，可以从软件后期维护的收益中得到补偿。但是，对于一些互联网行业的客户，这种高度文档化的管理风格，反而会造成业务和技术反应的迟钝。

说到这里，一部分人可能会好奇这个CMMI五级成熟度模型到底是什么。

基于阶段式表现法的CMMI的5个级别如表1-1所示。

表1-1　基于阶段式表现法的CMMI的5个级别

从表1-1中给出的5个级别可以看出，每一级都是上面一级的基石。要上高层台阶必须首先踏上较低一层台阶。企业在实施CMMI的时候，路也要一步一步地向上走。CMMI实际上是一种管理流程的标准化模型，遵循该模型的标准，企业就能提升项目的管理水平。

如果以现在的眼光看，CMMI到达五级的企业才具备通过量化和反馈进行过程持续改进的能力。这些五级的软件企业是如何做到持续改进的呢？首先，对软件过程进行改进使其更有效率；其次，利用不断出现的新技术和新工具提高了生产力；最后，对出现的问题进行及时总结，避免错误重复发生。

但是，改进过程、引入新技术都是有风险的。企业不能盲目改进过程，也不能盲目引入新技术。新过程、新技术也不能一下子推广到整个组织，可能需要先在小范围内试行，然后逐步推广到整个组织，在实施过程中，监控整体情况并评估改进的效果。

这个时期的分布式团队基本上是离岸外包团队，客户方一般会任命一名专门的负责人来管理外包团队。这个人负责给外包团队分配任务、制定计划以及验收外包团队的工作成果。对于离岸团队来说，这名负责人就是客户的代表，同时在客户内部他还要为离岸团队的交付成果负责。

但是，这几年，听到CMMI的消息越来越少。是因为行业内有更好的标准来代替它了吗？不是，是敏捷开发方式的发展在慢慢改变分布式团队的组织方式和工作方式。离岸团队的成员也需要适应不同的管理方式和合作方式，学会承担更多的责任，提供给客户更多的价值。

1.1.3　分布式团队的类型

分布式团队有不同的合作形式，包括与公司不同团队的合作关系，与客户公司团队的合作关系、竞争关系，与客户的顾问团队的合作关系、竞争关系。不同的合作形式对应着不同级别的合作，同一家公司的合作级别也在其中。

如果分布式团队的组成是开发团队在一个地方，而测试团队在另外一个地方呢？这种分布式团队是要尽可能要避免的。本来把开发和测试分开就已经割裂了信息的流通，这样又使沟通障碍更大了，这样的两个团队很难为同一个目标努力。我们曾经认为，用减少沟通的方式来解决分布式团队的沟通问题，可以让分布式团队互相依赖最少，他们可以很好地独立工作。事实证明，这种方法行不通。我们不能按职能安排分布式团队，而要按功能来划分分布式团队，让每一个团队都是全功能团队，每个独立的分布式团队都能把一个功能从产生、设计、开发、测试到上线端到端地完成。

图1-1给出的是职能型团队和功能型团队在瀑布模式的开发团队和敏捷模式的开发团队中交付项目的过程。

图1-1　项目交付的过程

从图1-1可以看出，功能型团队的组织方式在交付时间上有很大的优势，要远远优于按职能划分的分布式团队。在需求固定并且没有持续开发的项目上，按职能划分的方式还是有一定成本优势的。

很多公司允许员工在家工作。这种情况与分布式团队还是区别很大的，对于这样的团队成员，管理有很强的灵活性。因为他们可以随时来到办公室与团队会合，所以这是一种按照需要“聚”和“分”的工作方式。这其中涉及另外一个问题，即公司的人性化管理。例如，对于哺乳期的女性员工，只要有KPI在背后发挥作用，就可以灵活安排自己的时间；对于是独生子女的员工，可以在父母家工作一段时间，陪伴年迈的父母；对于更加现实的一部分人来说，特别是住得离工作地点比较远的人，可以免去早晚高峰挤地铁，每天省下消耗在路上的时间。如此看来，还有人会对这样的好处无动于衷吗？

1.1.4　什么样的团队可以称为分布式团队

很多人的第一反应是，不在同一个工作地点的团队是不是就是分布式团队？其实不是这样。哪怕是在同一栋大厦里面，甚至是在同一楼层，也可能是分布式团队。一种权威的说法是，团队之间只要距离超过30米，就可以称为分布式团队。那分布式的标准是什么呢？当超过目光所及的范围，或者高声讨论失效的范围，就会产生沟通的障碍，沟通的效率就开始下降，主动沟通的次数就会减少。我之前在一家汽车制造商做一个项目，项目的两个团队在一个办公区相对的两个角落，分别负责不同的微服务，所以这也是一个分布式团队。我们已经见过有的团队虽然在同一楼层，但还是会通过电子邮件讨论一个需求问题，而不是走到一起在白板上面对面地讨论。

一家跨国公司的各分支机构是不是分布式团队？多数情况下不是。比如Google，他们仍然坚持所有的业务、技术团队都在一起工作。虽然他们在世界上的很多地方有分支机构，但是这些机构之间并没有真正的协作关系，所以这一类并不是我们所关注的分布式团队。但是，如果他们之间需要经常协作完成一个目标，本书的方法对这种情况也是完全适用的。

1.2　服务外包行业的现状

外包的好处是短期项目不需要长期维持一个团队。

即使是世界上一些志向远大的公司，也主张将非核心业务的部分（如业务流程）外包给专业性服务公司。这会使它能专注于核心业务，以降低间接成本，提高运营效率和灵活性。

作为世界上最重要的外包服务输出国之一的中国，国家商务部服贸司每年都会总结上一年服务外包行业的数据。服贸司2017年发布的数据如下。

2016年，在全球投资贸易低迷的情况下，我国服务外包继续快速发展，离岸服务外包日益成为我国促进服务出口的重要力量，对优化外贸结构、推动产业向价值链高端延伸发挥了重要作用。商务部服贸司负责人指出，2016年我国服务外包产业发展主要呈现以下特点。

一是规模快速发展，新签合同额突破10000亿元。全年新签服务外包合同额10213亿元人民币（币种下同），首次突破10000亿元，增长20.1%；执行额7385亿元，增长17.6%。其中，离岸服务外包合同额6608亿元，执行额4885亿元，同比分别增长16.6%和16.4%。我国离岸服务外包规模约占全球市场的33%，稳居世界第二，离岸外包执行额占我国服务出口总额的1/4。

二是产业结构逐步优化，技术密集型业务占比提高。借助于云计算、大数据、物联网、移动互联等新一代信息技术，推动“互联网+服务外包”模式快速发展，服务外包企业稳步向高技术、高附加值业务转型。全年承接离岸信息技术外包（ITO）、业务流程外包（BPO）和知识流程外包（KPO）执行额分别为2293亿元、809亿元和1783亿元，占比分别为46.9%、16.6%和36.5%，同比增长11.4%、35.9%和15.5%。

三是企业专业服务水平不断提高，创新能力稳步提升。服务外包企业新增软件能力成熟度（CMM）等国际资质认证927项，单笔合同均价527万元，同比增长15.3%和5.6%。企业的技术能力和专业服务水平不断提升，正在由提供单一技术服务逐步转向提供综合解决方案服务，由项目承接转向战略合作，由成本驱动转向创新驱动。

四是服务外包示范城市集聚引领作用不断增强。示范城市承接离岸服务外包执行额4564亿元，同比增长15.9%，占全国的93.4%。其中，京沪广深四个城市离岸外包执行额1385亿元，同比增长21.3%，占全国的28.4%，在技术、商业模式创新方面发挥了重要的引领作用；2016年新增的10个示范城市离岸外包执行额384亿元，同比增长32.2%，高于示范城市及全国的整体增速，成为服务外包产业新的增长极。

五是与主要发包市场合作加强，国际市场稳步拓展。承接美欧日和中国香港地区等主要发包市场的服务外包执行额3086亿元，同比增长19.3%；承接“一带一路”相关国家服务外包执行额841亿元，占我国承接离岸外包的17.2%。离岸服务外包现已拓展至201个国家和地区，业务遍布全球。通过承接离岸服务外包业务，企业的研发能力不断提升，推动技术、设计和标准“走出去”，促进了国际经贸合作日益深化。

六是从业群体不断壮大，吸纳大学生就业稳步增长。服务外包产业新增从业人员121万人，其中大学（含大专）以上学历80万人，占新增从业人数的65.9%。截至2016年年底，我国服务外包产业从业人员856万人，其中大学（含大专）以上学历551万人，占从业人员总数64.4%。

该负责人表示，2017年商务部将坚持稳中求进的工作总基调，贯彻落实新发展理念，加快推进供给侧结构性改革，会同有关部门优化服务外包产业和区域发展布局，建立示范城市有进有出的动态调整机制，促进一线城市提升创新能力和产业附加值，推动劳动力密集型业务向二三线城市转移；认真总结示范城市发展经验，研究将示范城市的优惠政策向非示范城市地区推广复制。

在过去大多数的软件外包模式中，甲方的利益相关者显然不关心交付过程中的细节以及如何解决问题，他们只关心阶段性交付了什么产出物。而现在互联网思维的传播，很多的行业开始利用互联网，尤其是移动互联网拓展业务，进行创新。以前的软件外包模式显然跟不上时代发展了，现在很多时候我们需要与客户一起进行持续的创新活动、持续地升级产品。双方需要更紧密的合作，客户不但重视合作中的关键结果，合作过程也变得非常重要。

更主要的是，中国人力成本急剧上升，在国际市场依靠人力资源为支撑的外包产业必然面临巨大挑战。所以说，2017年国家商务部服贸司发布的报告和数据进一步印证了我对软件外包前景的看法，以及这个行业亟待升级的迫切性。为了保持足够的竞争力，作为从业人员，也亟待提升硬技能和软技能，因为未来的舞台足够大，未来的世界也是足够平。从另一个方面讲，国家加强供给侧的投入，越来越多的人才会涌入这个行业，如果我们自己不主动去打开上升的通道，必然会被后浪推到沙滩上。

以软件外包为主的服务外包行业十几年来一直在高速发展，对人才的吸纳能力很强，对个人来讲也能得到充分的锻炼机会，可以有机会接触各种各样的领域知识和不同的技术栈。

外包这个行业就像一个窗口，给了很多人职业起步的机会和发展的机会。一批批年轻人在这个平台得到了锻炼，知道了国外的公司是怎么工作的、研发部门是如何运转的。

1.3　离岸团队的组建

1.3.1　组建分布式团队的原则

传统观点认为，根据工作的内容来分配本土和离岸的工作是一个很有效的方法。比如，业务分析和设计团队在美国，开发团队在中国，验收测试团队又在美国，这样看起来非常合理。确实，这是一个符合瀑布开发模式的分布式团队。

近年来我们已经很少听到一个单独的外包开发团队或者一个单独的外包测试团队。现在，我们倾向于按照产品的功能来划分团队，而不是团队的职能。建设功能团队，意味着一个团队要从头到尾负责一个功能，而不是负责这个功能的某个阶段任务。这样，我们就需要给各分布式团队拆分功能。我们不会过于在意各功能模块之间的交互，因为有持续集成可以保证，随着开发的进行，各模块会逐渐地集成在一起。

作为一个离岸团队，业务分析师（通常承担产品经理的职责）的工作地点非常重要。相对于本土团队的业务分析师，我们离用户的距离很远，离产品干系人也同样很远。离岸团队有了业务分析师，开发团队就可以避免等一天才能得到问题的答案这种尴尬的情形。离岸团队的业务分析师，当场解决本团队的问题，这确实保障了开发的顺利进行。但是做到这一点并不容易，我们需要业务分析师掌握客户的业务知识，而且要提前与客户的业务人员沟通好当前业务。

离岸团队的人员组成按照全功能团队的标准打造，对于沟通的促进作用是非常明显的。全功能团队能够把项目中绝大多数的问题在团队内部消化掉，单一功能团队的弊端也在于此，单一功能团队需要大量的团队间沟通。如果是开发团队在一个时区，测试验收团队在另外一个时区，沟通问题将会严重影响项目的成功。

《世界是平的》的作者托马斯·弗里曼说，“我们创造了一个全球网络平台来分享知识和分配工作，不受时间、距离、地形的限制，甚至也越来越不受语言的限制。”

有的客户也看到了这一点。当一个美国的团队在将要下班时，遇到一个新问题或接到一个紧急任务而不能马上解决时，他们就可以与另外一个时区的分布式团队交接工作，这样中国的团队就可以接手这些工作继续推进。当美国的团队第二天回到工作岗位时，就能拿到中国团队全部完成或者部分完成的工作。对于这个问题或者任务的利益相关者来说，他们的诉求解决的时效性大大增强。本来需要两天才能拿到的结果，现在一天就能拿到了，虽然我们付出的同样是两个工作日。

1.3.2　组建分布式团队

不同的项目有不同的团队成员分配和分布。

一个12人的团队，10个（包括DM、PO、QA、BA、Dev）在北京，2个开发人员在武汉。我们可以把所有人看作是一个独立运转的团队，然后在所有团队仪式中包括2个远程工作的成员，并且寻找机会让武汉的成员定期到北京工作，这对互相的了解和关系的建立维护非常有帮助。还要考虑让两个地点的人远程结对工作，确保知识能够在分布式团队中分享。

一个28人的团队，20个（包括DM、PO、QA、BA、Dev）在北京，8个（包括BA、QA、Dev）在西安。与上面的例子不同，这里也许最好的方案是把不同地点的成员看作两个子团队。每个子团队进行相对独立的开发工作，并辅以Scrum of Scrums会议来协调和分享一些信息。可以考虑尽可能减少工作交互的场景，降低协作中的沟通成本。

Scrum of Scrums会议从诞生起就是一种为了处理多Scrum团队项目的相互依赖的复杂性机制。每天，在每个团队进行完每日站会后，由每个团队派出的代表组成一个Scrum of Scrums会议。在这个会议中，每个团队的代表向大家报告他的团队头一天做了什么有可能影响其他团队的工作，以及第二天有可能做什么可能也会影响其他团队的工作。主要会集中在讲问题上面，与每个团队内的每日站会类似，只是在一个更高的层面上。

1.3.3　建立一个离岸团队的投入和效益

组建分布式团队的目的不外乎以下几种：

• 降低成本；

• 开拓本地市场；

• 搜罗更多的人才。

作为客户，要考虑很多现实的问题，因为建立一个离岸团队而不是采用本土招聘的形式，在行业内一直存在不同的观点。作为支持方，理由是众口一词的，人工成本降低。有时候，分布式方法是交付产品的唯一方法，因为当地没有所需的人才，这也许算是使用分布式团队开发产品最正当的理由。

其实，人工费只是所有成本中的一部分，仅仅盯着人工费是不明智的。我在软件行业摸爬滚打多年，有一点我认识得比较清楚：不同人员的生产力的差异要远远大于他们的薪水差异。离岸团队更会显著地增大这一差异，因为离岸团队的成本除了人工费，还有沟通成本的增加、差旅费的增加，风险也因此远远高于本土团队。

我们先来看看沟通成本。分布式团队面临很多的沟通挑战，距离远而无法面对面沟通、时差、语言能力等。这些都会使我们对需求理解出现偏差，导致做出不正确功能的概率大大增加。我们虽然采用了很多技术手段以及派遣常驻代表，但离岸的风险仍然会对我们的团队造成负面影响。

如果是一个传统工作方式的团队，而不是采用敏捷工作方式，更加不支持团队间太多面对面的直接沟通。我们大多通过电子邮件、通过文档来达成团队间共识。因此，我们是不是就能得到最高的投入产出比呢？其实没这么简单，通过减少直接沟通的方法来达到减少沟通成本的目的，并不能增大团队的交付能力。就像通过节流的方式并不会致富一样，我们需要更多投入开源，投资创造出更多的价值。

回头再看看分布式团队的优势。我们发现，如果离岸团队完全在另一个时区，我们可以通过接力的方式，让一个功能在同一个主线上，24小时不间断地开发出来。这对我们加快上线速度有直接的好处。这是离岸团队特有的串行工作模式，如果团队有技术支持的职能，则能加快问题的解决。我们曾经遇到过这样的问题，我们也使用第三方的平台软件Salesforce，有一个技术问题需要尽快解决。我们首先找到伦敦的技术支持团队，因为北京时间下午晚些时候，他们刚刚上班。在他们下班的时候，只解决了部分问题，他们将我们的工单转交给了Salesforce在加利福尼亚的技术支持中心，继续处理我们的问题，后来他们又交给了悉尼的技术支持部门，最后解决了我们的问题。这样在我们第二天上班的时候，悉尼的客户支持人员给我们交付了他们的解决方案。

最后一个我想说说人才短缺的问题。我们可以在北京、深圳等很多城市找到足够的人才，即使这些人才并没有长期在这些地方生活的计划。在国外则很难找到人才如此集中的地方，而且人们也不愿意为此漂泊他乡。这时候我们更在乎的是工程师的天赋，而不是他们的成本。

1.3.4　分布式团队需要注意的问题

1．分布式团队中的人

现在社会上有一个观点，团队成员都在一起工作，有时候工作效率会降低，这是真的吗？团队成员每天都在一起，拥有最好的沟通条件。但是即使前提条件是最优的，结果就一定是最好的吗？我看不一定。就像一个家境很好的孩子，家长给他创造了最好的学习条件，但并不一定能得到最好的结果。反而是家境一般的孩子，平时要帮父母做事情，自己还要挤时间学习，主观能动性更强，结果反而可能更好一些。这就是为什么很多时候不好的条件反而能激发出更好的主观能动性。

因此，如果你一直奢侈得拥有一样东西，你一定不会认为它有什么特别之处。当这个东西是需要你努力才能得到的，你才会更加珍惜它。应用到沟通这件事情上，分布式团队中的我们更加看重沟通的机会，每次机会都会充分地准备，让沟通的效率更高效，用主观能动性来弥补天然的缺陷。

由此可以得出，人是一个分布式团队取得成功的关键因素之一。找到优秀的人，培养自我管理能力，运用适合的实践，就能把距离对我们的消极影响降到最小。

2．沟通难度的增加会改变团队的沟通习惯

通过以往的实践可以发现，接口难度的增加会产生一个后果，那就是交互的次数会减少，每次交互的内容会增加。例如，如果可以快速找到其他团队的一个人聊一下，确认一个需求或缺陷，我会马上做这件事。但是，如果我需要创建一个会议或者发送电子邮件讨论这件事，我也许不会立刻做这件事。即使我做了，也会花费更长的时间，所以我可能会先积攒更多的问题，然后再一起去讨论。

3．减少远程工作消极影响的方案

远程工作通常会阻碍社会化学习的过程，并增加跨功能团队工作交互的难度，所以我们需要在一些必要的工具上进行投资，如Wi-Fi、视频电话、日常沟通的流程等。远程结对，使用共享屏幕软件，拉近距离。在工程实践上的投资，持续集成和自动化测试工具，这对分布式团队尤其重要。

共识要在刚开始的时候就达成，并在以后坚持这些共识。比如，分布式团队之间分配工作的原则、各团队中角色成员的不同会从很大程度上影响分配的结果。

曾经有这样的例子：由于本土团队掌握任务分配的主动权，或者误认为自己有权力给离岸团队分配任务，往往把一些烦琐的己方不想做的工作丢给离岸团队。比如，把新的开发的工作留给己方，而把修复缺陷的任务给离岸团队。这样的行为是非常有害的，没有人在被当成二等公民的情况下，还能保持工作的主动性和积极性。

虽然远程参加的会议效果会差一些，但是分布式团队还是最好能够有规律地和频繁地碰面，尤其是在站会、迭代计划会议和回顾会议等时机。

我们所认同的面对面的沟通，在分布式团队的情况下，应该是直接的沟通。即时沟通工具、视频会议、电话会议等都属于“面对面”的沟通。

如果我们合作的客户在他们自己那里都是分布式的，那又该怎么办呢？我们将会又增加一项校准对方两个团队的任务。

1.4　软件外包服务大方向的变化

以低成本商品服务为目标的企业正在减少，因为在当今数字化转型时代，越来越多的企业在寻求与外包供应商建立更强的战略合作伙伴关系。这也逐渐改变了外包服务签约的类型和质量。

越来越多的客户接受了敏捷开发、开发运维（DevOps）、微服务等思想，并开始向敏捷的企业转型。

1.4.1　人才战争已经打响

外包项目中需要更多的高级专家和顾问，随着咨询类服务的增长，正在要求外包服务公司将一部分注意力放到人才的争夺和保留上。

在成本最低的地点采购软件服务已不再是竞争优势，因为客户需要使用自动化和工具来提高效率、降低成本。越来越多的组织正在通过技术而不是劳动力来促进大规模的生产力提高。

现在的传统企业，不管是银行，还是石油天然气公司，都希望使用创新、灵活、高端的技术，解决它们的业务问题，它们对技术的要求比以前有了很大的提高，以前只是外包公司把技术推荐给客户，客户并不是太关心技术上的实现，而主要关心业务。现在的客户言必云计算、大数据、人工智能，对技术有了更多的关注，对设计方面的需求也越来越多。这是一个好消息，必然带来劳动力价值的提升，而不是10多年前的成本为王。还有一个更好的消息是，现在的客户仍然保持着对离岸交付的接受度。

客户对风险的关注度越来越高，每次上线的风险都是客户的无法承受之痛。客户希望在交付中自动化部分越来越多，包括自动化测试、自动化构建、持续集成、持续交付和一键部署等，以便消除人为因素的影响。自动化不仅提高了效率，而且在其成为影响业务的事件之前也带来了积极的处理问题能力，这为企业增加的价值远超典型的成本削减。

客户开始重视软件交付之后的运维以及虚拟化、容器化的应用，因此运维也开始向自动化、智能化方向发展。

客户也变聪明了，他们明白如果需要技术推动创新，对技术的采纳不能仅靠降低成本（节流），还要靠技术带来的附加值（开源）来提升企业的竞争力。

1.4.2　战略合作的成果——建立离岸交付中心

随着技术成为跨行业的竞争优势，从汽车制造商到石油天然气供应商到零售商，所有公司都要变成科技公司，我们时不时地会通过媒体听到某某传统行业公司高管声称自己公司是一家科技公司。互联网创新将引导更广泛的IT外包客户离岸建立自己的专属技术服务提供中心。外包公司可以通过对一个行业、某些技术的深耕，进而具备成为交付中心的条件。

当然，成为客户的离岸交付中心，不是说人员到位就可以了。客户首先会进行实地安全检查，交付中心要建立健全的信息安全和运营安全机制，让客户对交付中心的环境、规章制度和规范性有充足的信心。

1.4.3　客户衡量外包服务的方式在发生变化

在这个业务转型期间，IT服务行业面临的最大变化之一是如何量化服务。合同正在从传统的投入或交易模式转向基于业务指标和结果的模式。在新的模式下，令人心服数据的获得和里程碑事件的设计就变得非常重要。

客户的期望正在迅速发展。客户的参与，从特定的业务挑战开始，潜在的供应商被要求为他们量身定制解决方案。结果是增加了以咨询为主导的高端服务的参与，为客户精心设计更加优质的解决方案。

关键外包服务的模式从基于赚取差价的套利模式演变为数字化转型的模式，这要求所有外包服务提供商将更多的资源用于创新。此外，人才的储备、成功的案例都是客户会考虑的重要因素。

第2章　分布式团队的沟通

长期以来，外包行业都是非常注重“客户服务”的，但是软件外包行业的复杂性，简单的客户服务的思想已不能满足需要。现在提倡的多是“管理客户”。从字面上体现的是，要更加主动地与客户合作，而不是仅仅满足客户提出来的要求。在为客户交付产品的过程中，以主动合作为基础，以客户为思考出发点，提升与客户进行远程合作的效率，提升客户在与离岸团队合作中的体验。

本章遴选了一些离岸团队的成功经验，单个实践可能不会给一个团队带来质的提高，但是一套组合拳一定会给整个分布式团队带来一个全新的体验。

2.1　管理客户的期望值

很多想当然的理解是错误的，比如经常听到有人说南方人爱吃辣，北方人不能吃辣。可是，这是一个很明显的误解，因为明明是沿海不吃辣，内陆地区吃辣。为什么很多人对这样一个明显的误解还能言之凿凿呢？先入为主和人云亦云的原因都有，但根本原因是拿来主义，没有经过自己的思考。

对于客户的期望值，我们也要透过现象看本质，不能被表象所迷惑，这是管理好客户期望值的第一步。主观地思考很容易引起误解，这已经发生在很多人的身上了，客观地分析才是我们需要训练的。

做好期望值管理的关键是要给客户一个合理的期望，让离岸团队与客户朝着同一个方向努力，把双方期望值的鸿沟缩小，达到双赢的目的。要做到合理非常重要，合理表示离岸团队的判断和客户的想法取得了一致。如果离岸团队为客户设定的期望值与客户所要求的期望值之间差距太大，离岸团队就算运用再多的技巧，客户也不会接受，因为客户的期望值本质上是客户对离岸团队要求的体现。

要达到管理好客户期望值的目的，就要站在客户的视角去考虑问题。说起来容易，很多人都知道这个道理。但是，我们做些什么才能转变视角，并且进一步与客户形成良好的互动呢？

2.1.1　了解客户

在开始任何一个项目的时候，都要填写一份客户负责人列表，上面记录谁负责什么、擅长什么、工作风格什么样子，相当于一幅客户画像。

1．了解客户的人

先来看看我做过的一个离岸项目的客户团队成员组成，如表2-1所示。

表2-1　客户角色和关注点

我们开始的时候，经常混淆Kevin和Ken的职责。我们完成一个功能都会找他们进行验收，但是很难找到他们都有时间的时候，所以经常会找他们中一个人验收。很多时候我们给Ken演示完以后，Ken都会说，这几个你们再找Kevin看看吧，Kevin满意了的话，他也没有问题。后来，我们仔细分析了一下，只要我们谈到具体逻辑实现的功能，Ken都会建议让Kevin来验收。只要是提升用户体验的功能，都需要拉上Ken。后来我们就慢慢习惯了他们基本的职责分工，对必须他们共同参加的确认、验收也了然于胸。

所以说，我们要了解客户，首先要了解客户都有哪些人，分别是什么角色。可以从用一个最简单的列表来列出所有的人开始。我们也可以用一个传统的结构图（分级别的那种）来展示客户的所有的人，并且让离岸团队的每一个人都清楚，不同层级或者角色的客户关心的信息都是怎么样的。这样，我们也能做到有的放矢，清楚需要我们提供的信息是包含细节还是仅仅是一个概要。

对于管理客户的干系人，还要避免不同的客户提出不同要求的情况。一个客户拍板了一个解决方案，离岸团队做了一半后发现，另外一个客户并不同意这个做法。我们虽然可以告诉他这是他们定的方案，或者把证据电子邮件转发给他。这样做确实是我们做事的方法，但是不能成为我们做事的策略。我们在决定方案的时候，一定要尽可能把所有人都聚在一起决定。即使做不到同时聚齐所有的利益相关人，也应该在做了决定以后，马上就通知所有人。

• 管理客户所有的利害关系人：设计图2-1所示的表格。

• 背景包含信息：加入客户公司的时间，在客户内部的影响力，懂多少敏捷实践（如Scrum证书），是否懂测试，了解多少领域知识等。

• 关注点：是否排斥重构，是否重视自动化测试、测试覆盖率、开发速度等。

• 在哪些方面能帮助离岸团队：擅长哪些方面，能回答哪些业务问题，是否了解遗留系统的架构等。

图2-1　客户干系人清单

所以说，对于不同角色的客户，我们也要调整我们的沟通内容。如果与我们紧密合作的是技术人员，我们可以解释具体的技术实现来说服对方。难点在于说服客户的业务人员，并且往往是客户方最终拍板的人，我们需要用讲故事的方法说服对方。讲故事的重点是说服客户我们为什么要这样做，想办法让听者产生共鸣，能够与他们头脑中已有的用户业务痛点产生关联。

举个例子，用户需要在系统中输入输出固定格式的数据，我们决定采用Excel格式的数据输入，而不是开发一个全新的表格控件。用户期望的是能够方便地编辑数据并且保存到系统中，方便地导出CSV数据生成报告。我们是这样解释为什么采用这个方案的：开发一个新表格控件作为数据输入，要有很长的开发周期，成本非常高，利用Excel软件的编辑功能，完成编辑后直接导入系统，会显著地缩短开发周期。绝大部分用户熟悉Excel软件的使用，上手也比较容易。导出的是CSV格式的数据，原因是出于性能的考虑，客户每次导出的数据量能达到50万条，再加上用户并发的情况，导出Excel格式的数据难以达到性能指标要求。

我们按照以上的方案来开发，后来我们发现导出CSV数据是不可行的。其中一项是不支持多语言的文字，非英文的信息会显示成乱码。至此，我们不得不回来解决Excel的性能问题，幸运的是，我们通过一个颠覆性的解决方案解决了性能问题。

我们通过对比开发工作量、用户使用的优劣势，而不是从技术角度去讲如何集成Excel，如何开发表格来向客户解释我们的方案如何满足客户的期望值。客户也能给客户团队其他人讲出来我们为什么要这样做，这样才是达到了目的。但是在后期发现原有实现方案不满足要求的时候，我们又通过技术性的解释，维持住了客户对团队的满意度，即使我们的最终方案与一开始相比发生了很大的变化。

2．了解客户的想法

没有一个离岸团队是不希望客户开心的，客户满意了，我们才能过上“好日子”，我们才能更从容地按照既定的标准开展工作，包括引入新的实践，这是一个良性循环。不过，要形成这样一个良性循环或者维持住这种良性循环，了解客户的想法是其中的关键。

如何让客户满意？我们首先得知道客户想的是什么，要把自己放在客户的位置上去思考。有人说，从客户的视角想象一下不是就能出来嘛。但是，拥有团队的力量，利用脑力风暴，才能尽可能接近目标。

我们应该从以下几个方面着手去了解客户。

（1）优先级。每个人手里都有做不完的工作，而一个人的精力又是有限的，所以当我们着手工作的时候，肯定要经过一个排定优先级的过程。排定优先级有一定的主观因素，也有一定的客观因素，比如了解的上下文。离岸团队需要建立正确的优先级，并且与客户的优先级保持一致。如果我们一直抱着客户认为不重要的事情在做，而把他们急切想让我们做起来的事情放在一边，客户绝对不会满意。

（2）进度。客户团队的交付速度是怎样的，由于我们采用了测试驱动开发，在故事卡的交付过程中，我们离岸团队体现出来的开发速度是相对较低的。虽然我们采取了很多措施，比如安排更有利于展示的功能，尽快交付客户能用的功能，但是还是有可能落后于客户团队的绝对开发速度的。有很多的客户会抓住这个点，挑战我们的工作方法，乃至质疑与我们的合作。有经验的团队成员可以用我们缺陷数量少、后期维护成本低的优势来说服客户，或者用交付价值的大小而不是交付功能点的多少来衡量团队的工作。当然，这些都需要用已有的统计数据作为支撑。

（3）质量。对质量的期望值，哪些缺陷是不能容忍的，哪些是可以放过去的，哪些是必须马上得到修复的。与客户一起制定一个评估缺陷的标准，具体的缺陷严重程度和优先级分级将在第3章被详细分析。

（4）用户体验。客户在与我们合作的过程中，期望值是会发生变化的。近年来，对用户体验的期望值越来越高。过去，用户体验的工作并没有专人来做，但是随着移动互联网的发展，用户体验设计从一个需求加分项变成了一项非常重要的要求。现在，没人会说用户体验不是他们的优先考虑对象。

所以，我们在项目一开始的时候，就要做出一些典型页面的高保真原型图，与客户达成一致，尤其要得到客户领导的正式认可。然后团队的前端开发人员就可以将这样的设计风格贯穿整个开发过程。

在项目运行过程中，当功能部分完成后，客户会开始重视对性能的要求。如果客户的期望值是“越快越好”这类感性的要求，我们要引导客户把感性的指标量化，变成可以度量的指标。

为了达成以上的目的，我们与客户要有一个正式的沟通计划。

制定沟通计划是一个很重要的策略（就像测试策略、质量保证策略一样），其最高目标就是在正确的时间能够找到正确的人得到正确的信息，反之亦然。不同的利益相关者有不同的信息需求，对数据类型的关注点、呈现方式、数据采集汇报的频率以及细节的程度都有不同要求。我们定义出对不同的利益相关者采取的沟通（汇报）形式，确保他们能够以容易理解的形式，阶段性地得到团队的进度信息。因此，这个沟通计划书，不仅仅是一个日常沟通的计划，而且包括利益相关者的期望值管理。

通常在项目启动以后，会产出一个正式的沟通计划表，包含不同级别、角色参加人的沟通计划。计划中明确了在整个交付过程中，所有的会议和活动的时间安排。这些会议和活动包括但不限于每日站会、迭代启动会议、功能验收活动、成果展示会议和团队间的互访计划等。

沟通计划也是为了明确一些机会，一些用来促成离岸团队充分了解客户想法的机会以及客户了解离岸团队表现的机会，所以这些机会可以划分为以下两类。

• 客户意见输入的机会：项目启动会、站会、缺陷的鉴别分类和迭代计划会议。

• 客户反馈团队的机会：迭代工作成果展示会、回顾会议和代码评审会。

所以，我们要充分利用这些例行性的沟通机会。不要觉得我们的团队每次都会把工作做得天衣无缝，因为几乎所有的离岸团队都会带给客户一些失望的情况，而这些问题几乎都可以归结为对用户了解不够。表象是离岸团队经常给不出一个合适方案或者被抱怨质量不好（内建质量在于代码质量不好，外建质量在于使用起来质量不好）、交付速度太慢等。这些指标其实都是相对的，我们只有从客户那里了解了指标的标准在哪里，才能补齐一些短板，匹配上客户的要求。

2.1.2　保障客户的知情权

没有人愿意成为一直被蒙在鼓里的人，所以坦诚是非常重要的。如果有了坏消息，也应该诚实告知坏消息，与客户共同面对。越是艰难的时刻，越要团结一切能团结的力量，与其藏着掖着，不如大家一起想办法，渡过难关。

客户的期望值有一部分是在与我们合作的过程当中形成的，要形成合理的期望值，我们必须让客户容易地得到准确的团队状态数据。

根据我做过的项目，客户的满意度主要建立在产品的进度和产品的质量两个方面。当我们在这两个方面的表现低于客户的期望值时，我们在其他方面处理得再好也无济于事。在客户的心目中，这两个因素是硬性指标，而且比较容易量化和对比。与此形成对比的是，非功能性需求能很好地增加客户的满意度，比如更好的性能、更好的易用性等，但是这是建立在理所应当地做好功能性需求的基础之上的。

1．进度

短期的进度，主要是迭代的完成情况，迭代计划会议是一个非常正式的获得迭代成果的机会。迭代的数据更新到燃尽图和燃起图中，进一步得到了产品发布这样大的层面的进度数据。通过对发布日期的预测，获知当前的进度是超前了还是落后了。

因为迭代内部的进度主要靠每日站会来获取，所以我们一定要有与客户的负责人一起参加的站会。即使不能组织两边全部人员参加的站会，也要有两边代表参加的状态更新会议。利用好每天的站会和各种审查活动，可以让使项目逾期交付的因素尽早浮现出来。

2．质量

有了缺陷跟踪系统的支持，是不是就了解了某阶段的产品的质量呢？显然，对于本身有大量己方工作的客户来说，了解离岸团队的具体细节工作是不大可能的。我们可以在迭代计划会议上，给客户展示缺陷的汇总和分析结果，或者每周一份周报也是不错的选择。除了既成的缺陷，让客户知道持续集成环境上运行了哪些测试也能提升客户信心。这些测试可以放到持续交付的环境中，让每一次的代码提交都能运行这些测试。

除了以上最重要的两点，与客户期望值能挂上钩的还有人员变动、需求变更、工作效率等很多因素。从原理上说，项目实施的过程是一个不断寻找平衡的过程，平衡什么呢？基本上是范围、时间、人员和质量4个方面。因此，当时间出了问题之后，我们可以通过增加人手、降低质量、缩小范围等手段来达成目标。对于多数的项目来说，缩小范围是常用的手段，即把优先级相对较低的功能移出去，这样可以保证重要的功能仍然能够按期交付。处理变化的因素需要客户更多地参与。当一个因素发生变化时，我们会有不止一个选项的应对措施，当然也可以以不变应万变。这个时候，客户的直接意见就显得尤为重要。

在我经历的项目中，不止一次遇到客户随意增加需求的情况。所以，需求范围的控制也要常抓不懈，并且要教会客户具有范围意识。对于我们的迭代式开发团队，当客户增加一个需求的时候，一定要让客户从迭代中移除等量的、优先级相对低的故事卡。

几乎所有的客户都会抵触进行离岸团队人员的更替，因为新人要付出很多学习的成本。所以针对团队内部成员轮换这个问题，我们也要争取改变客户的观念。这不是“换”和“不换”的问题，而是多久轮换比较好，如何在团队内部形成良性轮换的机制，让团队适应一个合理的轮换周期。长时间不进行人员的更替，有很多的副作用——兴趣和挑战的降低，团队成员满意度的降低，团队外的人失去了了解本团队技术栈的机会。有计划地进行人员的更替，会有机会引入新鲜的视角、新的技能包，继续提升团队的创新领域。所以，我们在这个问题上需要客户的理解，技术人员的管理有着特殊性，我们追求的不是安逸轻松、每天重复的工作，我们也需要一些挑战以及学习提高的机会。过于追求团队稳定，很可能让公司留不住那些有远大抱负的员工，对我们和客户来说，这是一个双输的结果。

保证离岸团队的项目信息以及人员信息，始终对客户来说“可控”，是一项长期的工作。不完整的信息，可以隐瞒的信息，短期内可以营造一个风平浪静的局面，但是这会影响到客户对离岸团队的评估。日后当这些信息被动地暴露出来的时候，必然要掀起更大的风浪。

2.1.3　维护客户的期望值

毫无疑问，处理客户关系是比处理一个技术问题更具挑战性的工作，因为人具有更大的不确定性。即便如此，我们还是有很多事可以做，以使客户关系更顺畅一些。

我们知道，客户不会无缘无故地发飙，通常关系紧张是由于客户的期望值没有得到满足造成的。工作没完成并不一定就会让客户不满，而是我们对客户的期望值有误判。所以，管理好客户关系的关键是设置明确的、持续地管理现实的、约定好的期望值。这其中的道理不难理解，做起来却并不容易。

我们都希望与我们合作的客户是更有合作性、更敏捷、更理智的客户。但是现实情况却不是这样的，我们每个人都有责任和力量去提升这种合作的状态。因为我们都是管理软件开发项目的专家，而客户很可能以前从来没有参与过敏捷软件开发过程，也就对实践的组织和执行一无所知。但是，对于这些我们是了然于胸的，因此建立共享的期望值和一个协作的环境去监控这些期望值，是我们理所当然的责任，而不是客户的。

我们可以从下面5个方面去维护好客户的期望值。

• 尽早设定清楚无误的期望值。

• 频繁沟通，有效沟通。

• 把客户的业务目标作为团队的主要目标。

• 保持一致性。

• 减少犯错的可能。

1．尽早设定清楚无误的期望值

关于客户要求的一些底线以及必需的实践和采用的流程，一定要提前与客户确认好。等到客户指出来就说明有些晚了。关于整个项目的流程需要在项目开始的时候就要确定下来，比如需求的范围、风险的管理、项目完成的验收标准、管理结构和流程。或者一些相对更加细节的方面，比如，调研类任务的成功标准、确定非功能性需求（性能要求）。确定好了这些，项目进行的过程中出现与客户争吵的可能性就会大大减少。客户自然也更清楚我们如何管理项目的流程、定义任务和项目完成的标准。前期任何含混过去的地方，都会变成后期的坑。

需要指出的是，如果团队为了防止完不成客户的要求而降低一些标准是不可取的，因为管理客户的期望值并不是意味着要去降低客户的期望值。除了在客户盲目乐观的时候保持清醒的头脑，在工作低于客户的期望值的时候，合理地解释也是我们需要做的。

现代社会的人，不管是客户还是离岸团队的任何人，都会倾向于过于乐观地估计我们的能力、我们的生产力。潜意识里把最理想的情况作为前提条件，随着项目的进行，我们实际的表现往往低于所有人的期待。当客户认为其最重要的指标有风险的时候，我们的节奏将会被打乱。比如，客户非常注重进度，当我们的进度落后的时候，我们将不得不在其他方面做出妥协，如质量以及一些解决方案、用户交互的润色。

举个例子：很多团队、很多人都自觉不自觉地把需求估算的点数和时间关联到一起，有的人说1个点表示一天的工作量，还有的人认为1个点是两天的工作量。更有甚者，进一步把天数想象成理想的1天，没有会议，没有其他任何干扰，实际上这是不可能的，正常的1天只有4～6小时的有效工作时间。

2．频繁沟通，有效沟通

当项目运转变得磕磕绊绊或者遇到困难的时候，我们往往忍不住以没有时间为借口，取消一些沟通会议，或者有时候我们很容易与一个不容易沟通的利益相关者沟通越来越少。从长远看，这样都会让我们付出代价。因为清晰、准确、频繁的沟通是一个项目成功的必备条件。一旦我们建立了双方共同议定的期望值和流程，我们就需要继续基于这些期望向客户报告，并确保持续地满足客户的期望值。只有继续坚持这些做法，我们才会减少以后的事情出错的可能性。

因此，我们要明白什么是沟通方式，什么是好的沟通方式。说得直白一点，就好像我们传达信息给特定的观众，例如，把过于细节的信息发给高级主管。所以要聪明地使用文档和电子邮件来沟通。大多数沟通还是以口头的形式，文档和电子邮件主要用来记录沟通的结果和业已达成的决议。电子邮件还是要特别注意的，因为收件人可能会按照自己的想法，去解读电子邮件中用到的情绪化的词语和信息。

团队工作透明化是一种有效的沟通，它可以让期望值的管理更简单，还可以促进责任的共担。因为对于你没有公布出来的工作，默认是你自己承担所有后果的。

什么是透明化？来看一个最近发生在我自己身上的例子。

我是中国联通的“沃家庭”宽带用户，两年的服务到期的时候，我去联通营业厅办理续约，他们给我推荐了一个新的两年合约，费用每月增加10元，网速提高一倍，还送一部手机。我满心欢喜地拿着新手机回家了。接下来的那个月，我发现我的手机上的网上营业厅中固话部分的信息不见了。中国联通的“沃家庭”是包含着宽带、固话和手机的。我就打联通的客服电话，客服人员打了一段太极之后，我发现我家的固话已经分离出去了，已经与宽带、手机解绑了。我竟然对此一无所知，固话竟然从免费的变成计费的了，如表2-2所示。

表2-2　联通新旧“沃家庭”产品对比

对于联通的业务工作人员，我姑且认为他们是了解他们的产品的，对我这次续约的固话单独收费是知情的。但是在续约的过程中，他们从来没有提到过固话的问题，而我本人对我这次续约的关注点始终在宽带和手机上。

作为联通的客户，你们觉得我现在会满意吗？不管出于什么原因，联通对我隐瞒了部分信息，我也一定要做些什么，因为我不希望同样的事情再次发生。同理，我们离岸团队与客户沟通的时候，一定不能专拣客户爱听的说，而是要把完整的事情告知对方，让客户知晓在这里得到什么，在那里也许会失去什么。如果我们只告诉客户前者，等客户自己发现后者产生的破坏力，要远远大于提前告知产生的影响，所以不要有侥幸心理。管理客户期望值的最终目标是永远不要让客户惊讶。

当项目进展非常顺利的时候，保持与客户的沟通是非常重要的；而当项目出现问题的时候，也与客户保持坦诚的沟通则更加重要。虽然这个时候沟通会变得稍微困难一些，但是如果我们隐瞒问题，则会动摇客户对离岸团队的信任。让客户知晓我们调查问题的过程，最好能进一步提出一个或两个解决问题的方案，与客户一起讨论这些选项，最终团队一起决定一个最终的方案。如果解决问题的过程足够坦诚并且专业，实际上，我们还能因此加强与客户的关系。说到专业，一定要给我们的解决方案一个时间线，客户需要清楚这里面的时间成本。同时，执行的团队也不会因为没有压力而误判此任务的优先级。

3．把客户的业务目标作为团队的主要目标

如何提升客户的业务价值？怎样才能给客户提供最多的价值？这两个问题是离岸团队需要不断思考的问题。坚持我们非常执着的做事方式是非常容易的，因为我们坚信我们的方法能带给客户最大的收益。在注意分辨坚持和固执的同时，多站在客户的角度去反思我们的做事方法和内容会更容易与客户相向而行。我们除了自己的团队需要更努力之外，我们还需要问这样的问题：“在这个特定的条件下，对于特定的客户，我们能提供的最高价值是什么？”如果我们相信我们的做事方式能够提供最高的价值，那么我们就要与客户探讨这些方法。探讨的时候我们要把焦点放在如何提高客户的业务价值上，而不是方法本身或我们的偏好上。

作为一个离岸团队，我们确实需要保证做的事情尽可能地让客户高兴，但要记住客户并不永远都是对的。如果客户提出一些很明显与他们的业务价值相悖的要求，或者增加项目和系统的风险的要求，我们也有责任坚定地反对这些做法。如果客户足够顽固，我们团队不得不按照客户的想法去做，我们也要坚持客户的业务目标，不要客户想要什么就给什么，采用敏捷的思维和方法，快速失败，让客户早一点意识到错误。

在追求更高客户满意度和达到更高期望值的道路上，我们不能止步，我们要给客户提供超出我们承诺提供的价值。这里面隐含着这样的信息：我们不能在一开始给客户承诺我们真实的交付能力，要留有一定的余地。我们需要在业务目标下，承诺哪些事必须交付的，哪些是可能交付的。我们需要把一些具有附加价值的交付能力先放到兜里，在交付的过程中再让客户看到这些令人欣喜的东西。如果我们一开始就把所有的东西（包括所有制造惊喜的东西）都放到与客户谈好的期望值中，然后按部就班地去完成所有的期待输出，将可能产生图2-2所示的效果。在图2-2中，满意的家长的孩子考了61分，而不满意的家长的孩子却考了98分。团队要知道客户的目标在什么水平上，适当降低客户对我们过高的期望值，但是绝不能降低团队在实际工作中的表现。

图2-2　某年高考看图作文题

4．保持一致性

在不同的分布式团队中，要尽量采用相同的标准。估算故事卡的时候，评判缺陷等级的时候，确定需求优先级的时候，我们都要统一所有人的认识。因为即使是同样一个任务，不同的人看待它的优先级也是不同的。

在人的方面也存在保持一致性的问题。离岸团队不同的人与客户讨论同一类问题的时候，尽量做到统一，而不是让客户得到五花八门甚至我们自己自相矛盾的意见。

5．减少犯错的可能

我们犯的错误给客户留下的印象一定比表现好的时候更加深刻。这个真理放到测试人员的身上会更容易理解一些，当你发现一个缺陷，然后团队把它修复了，你不会得到太多的赞扬，但是同样的缺陷如果到了生产环境，会严重影响我们的工作成绩。因为在这个时候客户认为你把工作都做好是应该的，任何的错误都是不应该出现的。

除了保证产品的质量，减少项目的延期也是维持客户的满意度。减少迭代的长度，一周最多两周，这样计划得会更准确一点，也能够更快地应对变化，比如优先级的调整。哪些需要尽快做，哪些可以往后放，从迭代中剔除。

学会放下紧急的事情，弄清真正紧急的事情。在分布式团队，对紧急的定义也需要扩展一下，更多的因素都会对紧急的定义产生影响。多考虑重要性的影响，不同团队的重要性的影响。因为紧急的事情很容易把团队拉到关注短期目标的错误道路上，等到发现的时候，往往偏离了更大、更重要的目标。

但是，我们不可能让所有的客户都满意，也不可能让一个客户永远都满意。本着这个原则，要坚决拒绝客户的不合理要求，因为不合理的要求对双方都是损害。或者伤了离岸团队的士气，或者纵容了本土团队的不合理做法，让他们在错误的道路上越走越远。或者虽然得到了短期的好处，却损害了长期的目标。还有一些貌似很正确的事，一定要看清楚，其实只是做了正确的事，但是没有正确地做事。

一味地无原则地迁就和妥协，客户也不一定会满意。拒绝不可能完成的要求，对不喜欢的东西能够大声说出来，才能帮助离岸团队树立正确的态度、严谨的做事方法，最终赢得客户的尊重和认可。

2.1.4　超越客户期望值

要在先于客户想到客户没想到的事情，而不是等客户告诉我们，以此创造良好的口碑。但是，口碑的核心在于超越用户的预期。

站在客户的立场考虑：他们的人与我们合作是否会常常感觉头痛？如果是，这些痛点出现在哪些地方以及哪些时候出现？深入地了解客户，在与客户合作的时候更加主动，能更准确地了解客户的状况以及痛点。客户告诉我们的信息毕竟经过了客户主观的加工。

分布式团队合作的一个关键是维护双方的信任。当然，信任来自平时合作的表现，如解决问题的能力、代码的质量、软件的质量等，这些都是硬实力。很多处理问题、对待任务的软技能，如态度、守时，也有助于提高互相的信任。其实，很多时候我们一开始就是以信任开始的，当我们一次一次不能按时交付一些功能、完成一些任务时，我们之间的信任就开始流失甚至崩塌。

鼓励离岸团队多走1000米，并且要让客户看到。

• 性能上超过客户要求的指标。软件响应更快，用户体验更顺畅。

• 离岸团队自身有能力去平衡一些选项，然后做出选择。毫无疑问，客户都会希望离岸团队具备这种能力。这样也就能避免随便一个小问题就把离岸团队阻止了，而不得不等待权威一些的人士来回答这个问题。

• 更好地服务于客户业务的创新。采用更先进的技术，更好地适应业务的变化，缩短上线的周期。比如，采用微服务、云计算等技术，更加灵活地适应客户需求的进化。

离岸团队如果不希望让低价值的工作越来越多，就必须抓住时机展示自己的能力。如果不能的话，可能产生恶性循环，团队的士气也会越来越低。客户找到我们，是因为客户相信我们能够带给他们更好的交付体验和创新的业务解决方案。

当然，我们在提升客户对离岸团队的期望值的时候也要谨慎，要防止挖了坑，结果让团队掉进去。因为客户可能会把我们额外交付的价值算成正常的范围，再次回到正常的期望值反而会被客户认为是一种降低。除期望值以外，在做决定的时候减法也总是比加法难，我给女儿报课外辅导班就是一个很好的例子。当多报一个的时候经常不会认真思考它的意义，很随意就加上了。但是，当计划减少一个辅导班的时候，反而会好好想想是不是可以去掉它。

2.1.5　L项目的案例

过去，行业的共识是——软件开发是不可预见的。敏捷开发方式的推广正在改变这个根深蒂固的看法。为了给客户提供可预见的敏捷交付，需要提高团队产出的可预见性、提高团队间信息透明度。

在该项目中，我们做了下面这些工作，包括通过客户间接地管理用户的期望值。

• 频繁的与客户讨论，直到理解一致。讨论的内容包括每一次阶段性的成果展示，要完成哪些功能，希望展示出哪些功能块。

• 开始测试前就去了解用户有什么期望。一开始用户误以为将要开展的是他们传统意义上的UAT测试，而关注数据的完整性。我们真正的意图是要得到用户对功能使用和体验上的反馈。

• 在第一次测试的过程中，我听到用户好几次提到我们对他们测试的期望在哪些方面。针对这些困惑，在第二次用户测试前，我们提前与用户做了沟通。例如，数据问题，用户不知道哪些数据可以用来测试，在开放给用户测试以前，我们给客户发一封电子邮件，说明哪些数据可用，哪些数据不可用。

• 用户缺乏对敏捷开发方式的理解对合作也是不利的。因此，我们向客户解释了我们的开发路线图是以业务为导向的，会尽快提交支持业务的基本功能，之后才有更高级的功能，而不是面向功能，即把一个功能做好了再去完成另外一个功能。

• 部署众测版本要按照上线的标准来要求软件的质量和数据的完整性，使用生产环境的数据意味着用户的预期就是交付的标准。

• 客户对开发速度的过度关注也容易引发了问题，习惯上速度是用来衡量生产能力的。我不止一次地从客户那里听到这样的对话：“团队的开发速度从上次迭代的30个点下降到这次迭代的23个点，是哪里出问题了？”这时速度就变成了一个绩效工具。

分清客户和用户，分清你想要的、猜想的和用户想要的，分清哪些是用户（注意，是用户不是客户）的无理要求、哪些是不合理要求、哪些是合理要求。

如果客户搞不定他们的用户，我们要小心了，客户说某些功能简单实现就好，但是当用户上手用了以后，很可能会有体验方面更高的要求。这种问题怎么解决？一开始就让客户给用户发一个关于用户体验的定位和标准，明确我们的用户体验只满足这些基本要求。

如果与我们合作的客户方对接的人很多，但都不是帮助我们做项目的，而是时不时提一些要求，让团队做这做那，给他们提供各种文档，那么我们除了要分清楚哪些是他们的本职工作，还要给他们必要的支持，让他们在领导面前有工作成果，这样对未来的合作会有帮助。

2.1.6　拆屋效应

“拆屋效应”源自鲁迅先生的一次演讲，他说道：中国人的性情总是喜欢调和、折中的，譬如你说，这屋子太暗，须在这里开一个天窗，大家一定不允许的，但你主张拆掉屋顶，他们就会来调和，愿意开窗了。

“开窗”就是指要达到的目的，拆掉屋顶就是指提出高要求。从心理层面分析，拆屋效应之所以能够实现实际效果，是因为当不合理的高要求出现时，对方会立刻去权衡得失，然后开始调整自己的心理预期，做最坏的打算。

这个时候如果有更合理的方案出现时，对方为了防止更难以接受的情况出现，就会做出适当的妥协。再者，为了维持自己在他人眼中的好形象，人们通常不好意思连续拒绝他人的要求，何况是比第一个要求更低的要求。

给客户的承诺先高后低，最终客户的满意度是比较低的。如果给客户的承诺先低后高，那么刚开始客户可能不是很满意，但是当时也能接受，最后的结果却高于期望值，这样客户就比较开心。这就是“拆屋效应”在管理客户期望值方面的体现。

2.1.7　项目的成败是由客户的期望值决定的

管理好客户的期望值是离岸团队的核心问题，因此我们还要平衡好交付的价值、客户接收到的价值、客户期望的价值，尽量把它们捏合在一起。打个比方，如果客户认为交付日期是更重要的衡量成功的指标，那么这个项目即使没有按照最开始约定的范围交付，只要在约定的日期交付了，这也可能是一个成功的项目。相反，如果客户更看重交付功能的完整性，那么即使错过了交付日期，只要交付了约定范围的所有功能，这也是一个成功的项目。

前面提到的L项目就有这样的背景：我们做的软件产品的目的是替代客户现在购买的一个云服务系统，这个服务在第二年的3月10日到期。所以说，我们这个项目的交付日期是固定的，但是客户又反复重申新系统必须包含云服务的所有功能。难道这个项目的计划就没有一点可以调整的余地了吗？答案是：有。我找客户讨论了一天，综合用户对云服务系统的使用和我们约定的需求列表，我们圈定了一些需求列表中满足业务必需的需求。结果我发现，我们有一个迭代的工作量可以在上线之后再去做。好了，这一个迭代的工作量就是这次发布计划的缓冲量。所以，即使我们最终的正式发布中没有包含最后一个迭代的功能，也并不妨碍项目是一个成功的项目。

如果一个项目按时而且是在预算内交付了计划内的所有内容，它还是被定义为一个失败的项目，不要惊讶，因为这有可能是我们交付的功能满足了客户的要求，但是没有满足用户的需求。

如果对客户的期望值不清楚，项目的成功与否就完全取决于运气，因为我们并不清楚现在团队的表现是高于客户的期待还是低于客户的期待。

有时候我们还要识别一些陷阱。比如，在某个迭代中团队做完了承诺的故事卡，还完成了一个承诺之外的功能点之后，要不要把这个新完成的故事卡也放到这次的发布计划当中呢？冲动的话，可能做出肯定的回答，觉得这样交付的工作超出了客户的期望值，能够给他们惊喜。实际上，这样做要冒很大的风险，因为这样不仅让我们自己测试的工作量增大，而且会缩短测试的时间，结果必然会造成质量的降低。

一门心思想超出客户的期望值，往往会忘记其带来的风险。战胜一时的交付诱惑，不要轻易做出尽量交付更多功能点的决定。把这个选择按照下面的方法列出来，对以下两种交付结果就很容易做出正确的判断。

• 20个功能点：测试点少，测试时间长，质量高。

• 25个功能点：测试点多，测试时间短，质量低。

2.2　沟通是分布式团队最大的挑战

俗话说“好事不出门，坏事传千里”。看来，如果是好事，想让别人知晓，也需要些手段；如果不好的事情，不经过处理，离岸这种工作模式也有可能是瞒不住的。

对于分布式团队，沟通从来都是一个永恒的话题，而且是焦点话题，我必须在这里把这个话题挖得更深一些。

• 把简单的事情做好，沟通无小事。

• 从同步和异步这两个维度去了解沟通的本质，有利于离岸团队成员自己去挖掘提高沟通效率的方法。

• 要有同理心。

敏捷提倡多沟通，尽可能面对面沟通。从这个方面看，分布式团队结构是对敏捷开发方式在沟通方面最大的挑战。多数人会认为，各个不同地点的团队如果交付独立且完整的功能，可以明显降低沟通的不利影响，这也是过去几年外包行业发展坚持的宗旨。这种分布式合作方式与敏捷倡导的增量式开发和持续集成有本质的不同，好消息是通信技术的发展，特别是互联网技术的发展，让很多团队可以更紧密地协作，真正地远程结对，所有功能均由不同团队的人参与完成。

2.2.1　分布式团队最基本的沟通方式：电子邮件

总是能听到有人说邮件是最坏的沟通方式。那么，为什么分布式团队还要倚重它，该怎么做才能扬长避短，充分利用好电子邮件呢？

多数人会觉得使用电子邮件非常简单，根本不需要别人来告诉自己如何使用。不过说实话，我不得不很遗憾地承认，在我的工作经历中，总是时不时地看到错误使用电子邮件的场景，如下面这些情况。

• 本来在讨论公司填写工作日志痛点的电子邮件，若干个回合之后，变成了某个客户安全政策的大讨论。

• 一位名同事发了电子邮件给分布式团队所有的人，然后有人单独回复他一些稍微私人性的内容，他未征得这个人的同意便把这封电子邮件回复给了所有人。

• 讨论一件小事，双方反反复复在电子邮件中踢皮球，很长时间也没有定下方案。

• 群发电子邮件，结果漏发给一个关键人。

• 明明感觉在电子邮件里已经把要求解释得很清楚了，但其他团队做出来的却完全不是那回事。

• 电子邮件主题的使用非常随意，经常与内容相关性不强或者过于泛泛。比如，有的电子邮件主题是“最近的一些问题”，这样的主题对以后搜索查询的关键字具有隐蔽性，该邮件会很难被搜索到。

当然，还有很多情况下我们用得都很好。例如，不同团队的两个人一直在单线联系，但结果始终达不成共识。一方在回复的时候就把对方的领导抄送上了，这很明显是一个沟通升级的举动，希望对方的领导介入并尽快确定一个方案。

一封邮件里面最好只讨论一件事情，至少也应该是相关的事情。很多人喜欢发汇总类邮件，邮件中讨论多个主题。这样做的坏处是，主题会被穿插讨论，容易乱，并且邮件的回复列表比较长，查找内容比较麻烦，主题的关键字查找也不准确。

电子邮件的内容除了文字，尽量多使用截图，以免使对方产生疑惑和猜测，减少邮件往复的次数。

我所经历的离岸团队，经常会遇到发送一封邮件给客户，却迟迟得不到回复的情况。如果再次催促的话，一定要把这封电子邮件的内容也带上并抄送给领导，这样对方也能意识到他们的回复并不及时。

对于市面上大多数电子邮件本身的功能，也要了然于心。首先，要使用好邮件组。使用分布式团队的邮件组来发送邮件，可以有效地避免邮件漏发的情况，尤其是对其他团队的状况不是特别了解的时候。其次，要使用好CC和BCC，专业地沟通。

小常识：邮件系统“抄送”和“密送”你真的会用吗？

　　

先说“抄送”（carbon copy，CC）。在我曾就职过的新加坡创新科技公司，我是第一次学会了发送电子邮件和抄送电子邮件。我们当时其实也是典型的分布式团队，在新加坡本土和北京有几乎同等规模的测试团队。我刚去了不久就有一次开完会由我负责发送会议记录，我把差不多所有的人都放到了“收件人”（To）一栏，把我们部门经理放到“抄送”一栏就发了出去。很快，我们部门有一个在新加坡总部工作超过10年的同事找到了我，给我上了职业化的第一课。他说：对于会议纪要这样的电子邮件，“收件人”这一栏应该是放所有与会者的，因为作为参会人有权收到这封邮件。而“抄送”这一栏应该放没有参会的人，包括未参会的领导，或者与会议内容相关但因故没有参加的人，让他们也能知晓会议的内容。

再说“密送”（blind carbon copy，BCC）。正常的接收人和抄送人是看不到这个地址栏里面的人的，而在这个地址栏里面的人却能看到正常的接收人和抄送人，但是所有在这个地址栏里面的人又是互相看不到的。这个一般用在对外发送的情况，比如你想把一封邮件发给多个客户，而不希望他们互相知晓，就可以把他们全部放在“密送”中。

注意，在一封邮件的“密送”中，一定不要使用“回复所有”这个选项。曾经有一次，两个团队的主管因为一个方案在邮件里吵得不可开交，其中一位主管就“密送”给了更高一级的经理。最后，这个高一级的经理就跳出来“回复所有”把方案给定了，结果可想而知，另外一位主管非常生气，觉得这样一件平常小事还“密送”给领导看。从此以后，这两位主管更难以协作了。

1．电子邮件沟通的特点

下面对这么多年电子邮件的使用稍作总结。

从电子邮件承载的信息来看，电子邮件是非紧急情况下的沟通方式，多用于详细信息的沟通，并且可以用来作为沟通中的知识的保存地点。在沟通之后，还能作为证据记录，以备后续查找。

从时间的维度上看，电子邮件本身是一个异步沟通的过程，不需要接收人立刻答复邮件的内容，接收人可以有思考的时间。

转发邮件是有技巧的。当我们收到一封“仅供参考”（FYI）的邮件时，会进一步发现这封邮件包含了一段时间以来多次反复的沟通，不只一个沟通对象表达了很多的意见。我是非常头疼的，这需要在缺乏一定的上下文的情况下厘清所有的问题。如果一个当事人在转发邮件的时候做到以下两点，这封转发邮件的读者将会轻松很多：

• 简单介绍一下这封电子邮件所讨论的问题以及由来；

• 总结一下目前提出了哪些问题，哪些已经得到解决并且解决方案是什么。

2．有些时候，需要采用比电子邮件更好的沟通方式

比如，前面提到的“讨论一件小事，双方反反复复在电子邮件中踢皮球，很长时间也没有定下方案来”这个过程中，真正有价值的就是最后的方案，沟通的过程比较频繁，其实不适合使用电子邮件。正确的做法是使用电话或者即时通信工具去讨论，等有了结论以后，再使用电子邮件给相关的人员广播一下就好了。

遇到比较紧急的事情，如果使用电子邮件，我们不能指望马上得到回复。即便是我们用上了“如果在今天下班之前没有收到回复，我们就会采取什么行动”之类的语句。

很多人有这样的误解：把电子邮件转发一下，把文档给别人一丢，就认为别人已经知道了这里面的所有信息。对有些内容来说，其实把所有相关人召集一起，共同讨论一下是更好的选择。

3．用持续改进的思想看待电子邮件

如果不得不在电子邮件中讨论问题，我们要让电子邮件中所讨论信息的某个利益相关人，在电子邮件讨论结束后，追发一封总结电子邮件。把所有讨论过的有价值的信息在最后这封电子邮件中罗列出来，以备以后查询以及后来人的知识传承。如果没有总结，那么没有参与讨论过程的后来人，只得到一封转发的一长串的电子邮件，从头到尾看起来，去收集里面有价值的信息，是一件很头疼、很浪费时间的事情。

2.2.2　常规意义上的沟通：异步沟通和实时沟通

我们先看看下面这个例子。

1．异步沟通

现在很多公司会给员工提供免费的牛奶或者饮料，你是否也有在早上想喝牛奶的时候，发现冰箱里同时有好几盒打开了，却不知道是什么时候打开的？星期一早上的情况会更糟。因为大家都知道牛奶一般是打开后24小时内饮用完，所以为了保证自己喝得安全，在不确定牛奶被打开的时间的时候，一般人会新打开一盒牛奶，这样冰箱里就又多了一盒被打开的牛奶。

那么，有没有什么解决方法能方便地知道哪盒牛奶能喝哪盒牛奶不能喝呢？方法是有的。因为所有的牛奶盒上面都提供了一个空白区域让我们标记时间，所以我们只需要在上面写一个数字就解决了所有问题，这个数字所起的作用就是异步沟通。

从理论上讲，异步沟通就是在时间这个维度上，信息在一个时间点产生，并从一个人这里流通到另外一个人那里，另一个人在另一个时间点接收到这个信息。异步沟通提供非现场的沟通，即这两个人处理这个信息的时候，是在不同的时间点上。道理有点像我们开车上路，如果违章的话，可能会是交警的现场处罚，也可能是被摄像头拍到的非现场处罚形式。

对于不同时区的离岸团队来说，我们的沟通在相当多的时候属于上面提到的异步沟通。针对这种沟通方式，我们沟通的时候，在一开始就要包含足够多的信息，站在对方的立场思考，因为对方的上下文可能与我们不一样。全面而完整的信息难免会有冗余的信息，但是要保证对方能得到所有需要的信息，甚至让对方有选择的余地才是重要的。

对于不同时区的离岸团队，我们都会想到要减少异步沟通的影响，增加实时沟通的机会。所以，离岸团队有时会被要求改变标准的上下班时间，以增大与客户工作时间的重叠时长。这种改变需要非常慎重，因为工作时间的改变会影响大家的生活甚至工作的士气。对于改变，我们不但要关注它带来的好处，而且要知道它会造成的潜在影响，尤其是消极影响。

我们在需求分析的时候，使用的提炼用户画像（persona）的方法其实也是改善沟通的例子。用户画像本身就是信息提炼后的产物，代表了一组特定的用户。提炼出来以后对加强所有人对一些事物的看法的一致性很有帮助。不过一定要注意不要把它与用户角色（role）混淆了。它们的区别在于，每一个用户画像是一个具体的人，具体化有助于进行同理心思考，这是用户画像最大的价值；用户角色是对应于软件来说的，主要用来在技术上对不同用户进行权限的区分。

拥抱变化的协作文档，我们可以维护一个最新版本的文档，但是我们需不需要记录新版本的变化呢？要用同理心这样思考：客户打开某个文档，发现这个文档更新了，但是需要把文档全部看一遍才能知道哪些地方更新了，如果更新的部分用颜色高亮显示出来就好了。

除了信息，包括需求，很多处理代码的实践也是异步沟通的例子。代码库中的沟通，对于分布式团队来说，这里面每天都会进行一些没有硝烟的战争。代码本身要起到沟通的作用，方法的命名原则是一个最基本的要求。

测试被称为可执行的文档，每一个测试方法的名字都需要足够清楚地反映测试的目的。比如，我们要写一个文曲星猜数字游戏的测试，第一个测试方法可以是这样的：

"should_return_4A0B_when_there_are_four_perfect_numbers_in_the_guessing_
 numbers".

从测试方法的名字就可以知道，我们比较数字的方法应该在满足一定条件时返回合适的值。如果我们遵循以上的标准去写测试方法，我们在管理测试的时候，看到的可以认为是一组描述软件功能的文档。

沟通要有一些前提条件：第一，沟通要基于对所有涉及的概念性术语有共同的理解；第二，沟通要基于对所有涉及的实践有共同的认识。

异步沟通，意味着信息传达的双方不在同一时间读取信息。这就要求信息的发出一方，充分考虑到对方的条件和环境，确保信息的绝对完整性，并对信息进行有效的组织。而信息的接收方，也要充分了解信息产生一方的一些“惯例”，当信息不完整的时候也能够最大可能地知道信息的全貌。因为信息缺失的部分往往是发出者认为理所当然的东西。

有时候我们发现一个问题，我们又比较积极，可能会立刻把这个问题抛给客户团队。但是我们要知道，通常我们的离岸团队人员变动是比较大的，很可能之前已经有人与客户沟通过，我们应该首先尝试在团队内部寻找现成的答案。有可能这些事情团队已经遇到过，并且有了解决的办法，能在内部解决的还是应该在内部解决。对于客户来讲，我们一直是同一个离岸团队，再次询问相同的问题，会认为是我们团队内部沟通有障碍。可见，过于盲目积极地沟通并不一定是好事。

由于对异步沟通的依赖，在远程团队中工作有一个原则是，尽量减少在最后一刻才做决定。这听起来是与精益理论唱了反调，其实不然。如果我们有一个需要一些投入和决策的项目，那么在执行之前需要充分地收集反馈信息。我们不能指望马上得到答案，因为协作的同事不可避免地会与我们的工作时间不一样。

异步沟通的主题需要我们花更多的时间进行思考和准备，虽然这看起来像是额外的工作，但是异步通信最终会更有效率。比如因为会议是事先计划好的，通常是一周一次的，所有的事情都是基于整个团队的讨论，这样可以更快地达成一致意见。这也消除了那些烦人的随时发起的即兴会议，不仅剥夺了远程员工参加的机会，而且中断了团队成员的专注性，迫使大家在头脑中进行上下文切换。

共享文档的风靡，从技术上解决了不同团队之间信息的一致性问题。团队在需要一个信息的时候，主动去信息所在地查询，总能得到最新的数据。

2．实时沟通

相对于电子邮件、共享文档的沟通，即时聊天软件、视频电话等沟通手段是更加直接高效的沟通手段。这两类沟通方式是解决分布式团队时区差异和地理位置上差异的综合手段。

通常，选择离岸团队的时候，完全没有工作时间重叠的情况是非常少的，因为这是一开始选择团队的关键因素之一。当然，工作时间重叠的多少，对分布式团队的沟通机制还有一定的影响。

• 重叠的时间非常少的情况。安排尽可能多的实时沟通在双方重叠的工作时间内，如站会、迭代计划会议、各种讨论会和碰头会等。除此之外，更多的沟通要依赖于异步沟通手段，团队要多进行提高异步沟通技能和技巧的培训。

• 重叠的时间比较多的情况。这种情况下，我们可以在实时沟通上投入更多的精力，采用更高级的实时沟通方式。建立不间断视频，使用一个大屏幕显示所有各方的工作区，当有事情的时候，直接走到屏幕前面就可以说话。配合软件的自动应答功能，能很好地模拟一起工作的场景，不说话的时候保持安静，有人呼叫的时候自动接通。

实时沟通包括用视频直接沟通，或者录制项目介绍或复杂的缺陷重现步骤，等等。在很多情况下，视频其实是成本最低的沟通方式，因为它远没有准备一个单独的文档来说明一个问题来得复杂。这是一个很多人都会搞反的情况，所以往往采用的是成本最高、效果最差的文档描述。

2.2.3　工具的利与弊

最近几年，远程协作工具越做越好了。如Screenhero，它能共享屏幕，然后让远程的两个人同时控制鼠标来进行操作，支持语音聊天。协作工具目前提供的功能，从客观上说，基本消除了远程带来的不利影响，剩下的就是人的主观能动性了。

如果客户要求我们定期提交项目的报告给所有的利益相关者，包括开发和测试的状态，这真是一件痛苦的事。通常，我们需要收集好所有的数据，以图表或图形的形式展示出来。使用普通的文档工具需要花费很长时间，而且需要小心维护，有时候还需要修改数据。现在幸福了，我们可以用好JIRA、Trello、Mingle等任务管理工具自动生成需要的报告。如果能说服客户自己登录系统去看报告，那就更完美了。

工具可以让我们非常容易地知道每个迭代的安排，因为在物理看板上我们只能知道当前迭代的内容。利用虚拟看板工具，可以避免不同团队间进度指示不同步的情况。

最后，当我们应用了很多的工具之后，切记仍要保持面对面的实时沟通的机会不被减少。

2.2.4　主动的沟通

在项目开始平稳运行时期内，表面上看上去风平浪静，水面以下却总有暗潮涌动。客户团队的人员经过一段时间的熟悉以后，慢慢地能够提出一些有意思的问题。例如，测试人员从项目一开始就加入团队好像并没有什么事情做？测试用例要写成多大的粒度才合适？为什么缺陷的优先级要高于故事卡的优先级？估算这么不准确，为什么我们还要估算故事卡？自动化测试写多少，什么时候写？

很多的问题实际上是客户的误解，我们要及时纠正他们的误解，以防止误解的扩散和生根发芽。条件成熟的话，引入更进一步的实践帮助客户提升实践的水平，提升客户合作的信心。

如果客户感觉离岸团队失去了“控制”，不信任感就会由此产生。所以作为客户来讲，每次感觉需要什么样的信息，都会询问离岸团队。虽然我们都按时提供了客户需要的信息，但是我们也要多迈出一步，就是根据客户当前需要的所有信息，与客户进行讨论，定期给他们发送。这样可以避免随机性和遗漏的可能性。同时，信息的规律性也更有利于进行横向和纵向的比较。为了避免客户出现不知道自己不知道的情况，我们要主动向客户介绍更多的上下文。描述项目概况、项目全景或者技术架构是很好的开始。既见树木又见森林的信息更容易理解。如果客户很看重产品质量，而离岸团队所负责部分的质量对他们来说是一个黑盒的状态，客户势必会很焦虑。所以，定期与客户讨论当前的已知缺陷，客户会对我们的质量做到心中有数，运气好的话，缺陷的优先级也能容易地定下来。

我们会想当然地认为所有的信息都在版本控制系统、任务管理系统里面，客户会主动去看想要的信息。事实上几乎所有的客户都不会去看，我们仍然需要给客户发送状态更新的报告，让客户花费最少的时间得到想要的内容。

有一些采用文字沟通方式的情况，如电子邮件、故事卡的内容描述、缺陷描述等。通常自己觉得很清楚，但是没有上下文或者不了解前因后果的人却看不懂。如何跳出自己熟悉的上下文去描述一件事情，是让客户顺利了解我们表达的内容的一个重要技能。

针对不同类型的协作团队，我们该怎么做呢？

• 协作团队是独立产品团队，但是与我们有比较紧密的集成的时候，我们该怎么合作？

• 协作团队是与我们工作在同一个代码库的团队，我们该怎么合作？

• 对于不共享同一个代码库但有少量交互的分布式团队，我们互相发定期报告（比如周报告）的方法是否能很好地解决团队间沟通的问题？

很多团队热衷于缺陷分析，但是要考虑分析的结果怎样去反馈到开发团队。开发团队有能采取的行动吗？如果没有切实的行动则不能形成反馈闭环，这样的工作做了能有什么意义？

很多项目有接触不到最终客户的问题，而且我相信这是离岸项目的“通病”。但是，用户是检验产品的唯一途径，所以我觉得我们希望帮助客户做到的是建立用户的反馈链，在项目中，在开始做真正的业务功能之前，做好产品的原型，客户可以用产品原型向他们的客户展示、收集反馈，这样也可以降低风险。

2.2.5　沟通中的冲突

我们先来看两个寓言故事。

故事一：狮子和老虎之间爆发了一场激烈的战争，最后，两败俱伤。 狮子快要断气的时候对老虎说：“如果不是你非要抢我的地盘，我们也不会弄成现在这样。”老虎吃惊地说：“我从来没有想过要抢你的地盘，我一直以为是你要侵略我！”

观点：相互沟通是维系团队的一个关键要素。有什么话不要憋在肚子里，多多与人交流，也让同伴多了解自己，这样可以避免许多无谓的误会和矛盾。

故事二：两只鸟在一起生活，雄鸟采集了满满一巢果仁让雌鸟保存。由于天气干燥，果仁脱水变小，一巢果仁看上去只剩下原来的一半。雄鸟以为是雌鸟偷吃了，就骂了雌鸟一顿。过了几天，下了几场雨后，空气湿润了，果仁又涨成了满满的一巢。这时雄鸟十分后悔地说：“是我错怪了雌鸟！”

观点：团队同事之间要相互信任，很多团队就毁于怀疑和猜忌。所以，团队成员要保持信任，不要让猜疑毁掉团队。

以上寓言故事说明，虽然出现问题的原因在于第三方，但缺乏沟通和信任仍会造成双方的冲突，离岸团队还会遇到更加复杂的状况。

下面的情况都是经常发生的，提前做好心理准备，才能在出现的时候有的放矢。

• 客户在工作中不是很配合，只考虑自身的负责的任务，不为我方设身处地地着想。

• 选择会议的时间难以达成一致，做出牺牲的一方会觉得对方不够体谅。

• 语言问题造成与离岸团队沟通的难度增加，离岸团队时常会有信息丢失。

• 对一个具体问题的不满引申为对团队的不满。

• 不尊重对方的辛苦工作。主要表现在无视对方的调研结果，强推己方的方案，或者达成一个超过期望值的成果，未得到应有的肯定。

• 给别人泼冷水。当进一步询问某个任务如此做的原因时，得到的回答是“我们就是这样设计的”之类缺乏数据、讨论流程、量化指标支持的决定方式。

• 离岸团队有时候做事随意，不够重视，对本土团队日常工作造成影响。比如，令牌不归还，其他人无法提交代码等。

如果团队都在一个地方，出现冲突的时候，可以坐到一起面对面地解决问题。但是因为是分布式团队，团队成员无法面对面坐到一起，所以解决冲突会有很大的难度。这是因为只有面对面，我们才能看清对方的面部表情和肢体语言，没有这些，我们就少了很多了解对方的机会。书面解决冲突是一个糟糕的选择，因为我们不仅看不到对方的表情，而且听不到对方的声音。没有语气，任何的小情绪我们都捕捉不到。在我之前公司内，我目睹过很多同事在电子邮件里激烈的交锋，总是错误臆测对方的想法，最后不得不强行终止电子邮件交流。召集所有当事人开一个视频会议是一个折中的方案，既能节省成本，又能增加现场感。

说到解决沟通的冲突，专业人士给我们的忠告通常是学会倾听。但是，到了离岸团队，只学会如何倾听是不够的，还要在倾听后充分准确地表达自己的想法。如果对自己的想法非常有信心，应该进一步去说服别人接受自己的想法。

我们谈需求的范围，不是说每个需求的深度都可以无限拓展。在这方面我们与客户是比较容易产生分歧，客户往往会有意无意地往需求列表里增加新需求。我们对每个功能要做到什么程度要心中有数，当用户的需求比之前的计划复杂了之后，一定要向客户标示出来。要让客户明白，我们不是不做他们的需求，而是要重新排优先级，做真正有价值的功能。固定价格的项目更是应该如此。

1．分布式团队化解矛盾的典型方式

分布式团队化解矛盾的典型方式分为客观手段和主观思考两类。

客观手段主要指远程破冰游戏，创造条件面谈，寻求高层的介入（比起裁判，更是起到协调员的作用）。这些手段的目的不外乎增加互信，推动去关注好的方面，聚焦解决方案而不是互相责备，对事不对人地讨论矛盾根源。其实努力的目标就是可视化和增加团队间透明度，当我们要对对方的一些内容不得不去猜测的时候，往往不会往乐观的方面去下结论。对于有现场同事的离岸团队，可以请在现场的同事约客户在工作之外去讨论解决问题，因为离开工作环境，紧张的感觉也会变得缓和。

主观思考主要指以就事论事为出发点去解决问题。

• 基于事实，撇清利益关系。要解决冲突，如果不能做到公正，而是被问题之外的因素所左右，则不可能让双方都心服口服。

• 求同存异的策略。客户指责我们的工作方法或者内容的时候，切记，吵架解决不了任何问题，要从双方的共同点出发，先找出双方之间可以达成一致的部分，然后再去解决有分歧的部分。针尖对麦芒式的沟通，往往会更加关注分歧的部分，但是求同存异，管控分歧，才是解决问题之道。

• 同理心思考。站在对方的立场上去考虑问题，有助于理解其他人行为背后的深层原因。

2．要有勇气说“不”

如果要获得主要利益相关者的认可，就不能不加分辨地采纳所有的理念与请求，因为这样的做法只会让不合理的要求越来越多，离岸团队的目标变得分散，也会失去了自己的计划和节奏。乔布斯曾有言：“创新并非采纳所有的功能，而是仅留最关键的功能，删掉其他。”做减法的能力是乔布斯成功的关键因素之一，团队协作也是同样的道理。团队协作并不是一股脑地满足客户团队或者其他团队的所有要求。而是要搞清楚工作的分配是否合理，以及对我们有没有负面的影响，必要的时候要帮助客户做减法。

如果与我们合作的客户代表控制不了需求，结果需求经常变化，应对这种情况的关键是一定要得到确认需求的书面答复，不确认坚决不做。这样，即使确认过后面再改，我们也有理有据。再经过我们估算的改动工作量，客户可能就需要为增加的工作量单独买单了。

如何让分布式团队互相信任对方是一个很难的课题，当双方关系闹僵再去修复则更是一个挑战性的工作。所以，离岸团队要及时把矛盾暴露出来，争取在冲突刚有苗头的时候就去解决掉它。俗话说：事从两来，莫怪一方。双方都要先从自身找原因，我们总有需要改进的地方。

2.2.6　同理心

同理心原则就是让自己站在对方的位置上，设身处地地体验、理解对方思考问题的角度，形成彼此之间的共同感受。打个比方，在恋爱中，拥有同理心是增进相互理解、促进相互包容的一种有效方法，对于有同理心的情侣，遇到挫折的时候，他们不会抱怨、责怪对方，我们看到的将会是鼓励、谅解、互相扶持，关系也因此变得更加和谐。通常，一个具有同理心的人对周围的一切事物都会产生一种关心和了解的心理趋向，当自己与他人在认识上出现分歧时，能够真诚地尊重对方，并容忍这种差异，当自己与他人在行为上出现摩擦时，能善意地理解对方，愿意综合双方的因素，从更高的视角去寻求一个皆大欢喜的解决方案。

要解决分布式团队的沟通问题，建立同理心和情感共鸣也是团队各方需要认真思考的问题。很多时候，其他团队的决定让我们感到非常费解甚至不满，同理心可以让我们站在对方的立场上考虑问题。当我们开始以对方的立场为思考问题的出发点时，我们就会发现我们忽视的很多事实。如果不转换视角，这些事实很难引起我们的重视。所以，同理心在很多方面间接地消除了沟通的障碍，让沟通向积极的方向发展。需要指出的是，离岸团队和本土团队都需要同理心的培养。

离岸团队的同理心能帮助我们更好地把握客户的期望值，使离岸团队的工作产生最大的价值。离岸团队会有很多确认的工作，如果没有得到及时的回复，我们会怎么想呢？是客户不重视离岸团队，还是客户手头有更多高优先级的工作？如果我们当时能说明一些不能及时回复会造成的影响，是不是能给客户更好的判断？离岸团队作为一个技术服务团队，一般会着眼于技术架构、逻辑实现等领域，当发生需求变更的时候，我们一般会聚焦于技术本身的影响。而客户则聚焦于业务价值，基于业务价值的评估而做出判断。

我们之前在做一个国外电信公司的网上营业厅项目期间，使用了一个插件来记录用户在使用过程中的日志信息，这样在出错的时候我们能够以最快的速度找到原因。这个功能对于测试和以后的产品环境都很有意义，所以我们在安排用户功能的故事卡时，会同步安排相关的记录日志的故事卡。但是客户却反对这样的安排，而是要求安排尽可能多的功能故事卡，最后再做日志类的故事卡。起初我们的开发人员是非常反对的，因为对我们来说这样会增加测试过程中调研工作的难度。后来我们了解了客户的立场，客户希望所有的利益相关人都能尽快看到能用的功能，收集他们的反馈，没有他们的支持，即使一开始做得再完备也避免不了一些需求的变更。后来达成这样的共识，当前的功能和日志功能分开做，未来可以按照离岸团队的要求合到一起做。

作为本土团队，如果没有同理心，我们可能会很容易地搁置或者驳回离岸团队提出的建议。也倾向于把离岸团队排除在需要达成协议的会议之外，因为我们会觉得这样更容易一些。当离岸团队犯了一个错误时，我们通常会直接抱怨他们，而同样的事情发生在我们身边的团队，我们则倾向于往好的方面替他们着想。当我们建立起适当的同理心时，恐怕一半以上的沟通问题就会消失。

既然建立同理心在分布式团队这么重要，那我们团队能做些什么，一步步地培养这种意识呢？结合我十几年分布式团队的经历，我们可以从以下事情做起，然后发展出一些适合自己团队的实践去尝试。

• 组织跨团队的活动。可以通过可视电话，组织一个共同的冰激凌社交活动，或者玩一个破冰游戏、跨地区的寻宝游戏。曾经，我们的团队和澳大利亚的团队共同参与了墨尔本杯赛马比赛的竞猜活动。两个团队都买了很多的小吃和饮料，两边的团队就像在一起一样，选择自己喜欢的马竞猜，所有人都很享受这个过程。

• 建立一个包含所有团队的人的照片墙。包含名字的发音，或者关于这个人的有意思的事情，或者把所有的照片贴到一个地图墙上，把每个人放到各自家乡的位置。

• 在双方之间进行文化方面的分享。可以以更有意思的方式进行，比如让离岸团队介绍本土团队所在地区的文化，或者反之。这样做的好处是，促使双方了解对方的文化、风俗习惯，同时肯定也会有很多的误解或者不对的地方。这样对方就可以来纠正和解释，会有很多的讨论和互动行为。

• 远程会议中穿插一些寒暄和闲聊。比如天气、当地事件、重大比赛等这些与工作并不相关的谈论。

• 互相寄送食品包裹。这一方式源自第二次世界大战时期美国发起的一项活动，旨在为战斗在欧洲战场的家人寄送食品包裹，后来引申为给远离家庭的人寄送食品包裹。收到对方团队寄送过来的小吃，团队会激动好几天，对双方的合作都很有好处。

• 有些视频会议可以放在厨房或者活动室等淡化工作的场所，大家可以讨论一些轻松的话题。

• 学着站到对方的立场上考虑问题。远程的团队在业务、所处的环境、文化背景上都有不同。你觉得显而易见的东西，别的团队可能是首次碰到；你做起来很简单的事情，别的团队可能要花更长的时间去调研；你的工作时间的会议可能安排到了别的团队的午餐时间。

• 当然，最好的方式还是争取机会互访。

最后，要记住同理心和尊重是相辅相成的，回顾会议上宣读的最高指导原则也体现了这个宗旨。无论我们发现了什么，考虑到当时的知识范畴、技术和能力、可利用的资源和实际情况，我们理解并坚信，每个人都尽了最大的努力。换句话说，在没有反面例子的情况下，我们要坚定地相信离岸团队对做好事情的渴望和为之努力的决心，就与自己团队是一样的。当出现不符合我们期望的结果时，我们查找原因的时候也应该先从自身开始。可以这样尝试问自己：“为什么一个理智、善意的人会做出那些决定？”“如果我提供一些信息或者支持，会不会避免这些事情的发生？”“我有没有忽略了他们的哪些信息？”

有很多的方法可以建立团队间的信任，破坏信任的原因当然也不止一个。但是，团队里最需要警惕的是滋生“对方团队”的对立感，这是非常有害的。把离岸团队当成自己团队来对待，在协作过程中注重同理心的培养，做到这一点，分布式团队协作的潜在障碍就会显著减少。

但是我们也要明白，同理心不是挡箭牌，不是猜测，不是臆断，该做的用户调查还是要调查，该要客户做的事情还是要客户做。不能我们自己想象一下客户的场景，就把所有的事情都做了。要知道，与离岸团队比起来，本土团队离最终的用户更近一些。

2.2.7　清楚而坦诚的沟通

面对面沟通的时候，很容易判断一个人嘴上说“可以”时他的肢体语言实际上是在表示“不一定”，或者当说“好的”的时候是表示“可以”还是“不可以”。这些观察在通过电话交流的时候是很难得到的，因此，在电话会议中，清楚而坦诚地说出你的观点非常重要，不要留给别人想象和猜测的空间。

如果有些事情我们团队做不到，一定要向客户明明白白地说清楚我们做不了。否则，随着时间的推移，我们的信誉一定会受到破坏。同理，当我们同意一件事情时，明确地说“我非常赞同”“我喜欢这个主意”也是非常重要的。这样，其他团队的人就清楚我们明白了他们的意思，并且所有的人对此有了相同的理解。相似地，当我们讨论完一个主题时，一定要及时地总结，保证所有的人没有误解。

在分布式团队更要注意暴露问题，不要指望别人会为你多考虑一步。帮助别人也是帮助自己，有时候一个小小的提醒会省掉后期很多麻烦。由于惰性，可说可不说的时候，选择了沉默，未来不出问题只能寄希望于运气好。

很多时候，在分布式会议讨论的进行中，我们同时会共享一个屏幕，在上面打开一个文本编辑器或者脑图工具做会议记录。这样做的好处是，如果音质不好，任何一方都可以结合会议记录更好地跟上讨论的节奏。再进一步说，记录下来的问题能使与会人员感到问题已经得到注意，后续解决方案也会很快出台。

沟通失败有以下几个先兆。

• 远程团队的成员不参加电话会议，对电话会议的讨论回应比较消极，参加电话会议迟到。

• 举行多次电话会议才能做出一个决定、达成一个共识。

• 注意力不集中，经常问重复的问题。

• 会议上答应的事情，会后不去兑现承诺。多见于回顾会议制定好的行动计划，到了下次会议，还是没有任何行动。

遇到这种情况，应该尽快出差到对方现场进行面对面的沟通。

下面是一些其他沟通技巧。

• 不管是技术上还是业务上，确保真理的来源只有一个。这需要在一开始就清楚地说明，如果做不到，团队需要在以后的工作中注意校准信息。这也带来了额外的沟通成本和信息风险。

• 维护一个健康的产品待开发列表，对于每一个团队，要有清楚的分工和所有权（Owner）归属。

• 分布式团队要有一个清楚的整体架构和设计准则，特别是共享一个代码库和信息库的情况。

• 有目的地选择合适的工具。有时候很多工具并不适合分布式开发的项目，所以要从一开始就说服团队使用合适的工具。

• 通过清晰和坦诚的沟通来建立跨团队的沟通信任。只有健康的环境，才能保证人与人之间、团队与团队之间更开放地表达各自的想法，而不需要害怕后果。宽进严出地处理反馈问题，积极地接受别人给我们的反馈，慎重地给别人提供反馈。

• 让在线会议更有效率。既然很难确保别人是否跟了上会议的进程，所以尽量使用可视化辅助手段和高质量的设备。

• 对一些针对分布式团队和大型团队的实践保持开放的态度，不要害怕去实验，不然无法确认这些实践是否适合我们的团队。

• 在每个独立团队的内部，给团队完全的自由去实现团队的小目标也是同等重要的。比如，是否需要物理看板。

2.2.8　成功的离岸团队还需要关注的

除了以上介绍的沟通原则和技巧，工作中很多沟通的细节也是需要我们注意的，小细节往往能够带来意想不到的效果。保持工作的敏感度，培养自己对沟通中的“美”的发现能力。

1．与客户的书面沟通

客户一般会要求定期发送工作报告，即团队状态以及工作进度的更新。可以是每天、每周、每迭代，这取决于我们合作的性质、团队的规模等因素。所以这个报告该怎么写、应该包含哪些内容，也是我们需要关心的事务。因为对于客户的技术负责人来说，我们的工作成绩可以通过提交的代码来检验，但是对于客户的非技术管理者或者其他人来说，这些文档类的东西才是我们当前工作的反映。

很大比例的客户会要求一个每天更新的报告。仔细想想，其实这个类似Scrum of Scrums这种多敏捷团队协作实践的书面形式。这里面要着重强调的是我们正在取得哪些进展、我们遇到哪些问题、我们做了哪些能力范围内的决策、是否需要团队外部的帮助等。

客户方的参与度比较高时，需要的都是上面的每日报告。客户参与度相对较低时，他们需要一个每周更新的报告，主要目的是向他们的老板汇报工作。所以在周报中我们要体现客户向老板汇报工作需要的信息。例如，本周的工作达成了哪个里程碑、在整个业务中我们又完成了哪一部分、感谢客户本土团队做了哪些支持、下周的计划是什么等更加宏观的信息。

当沟通双方的外语口语水平相差较大的时候，要多使用书面沟通作为我们沟通的主要手段。要注意与客户打交道的同时，管理好电子邮件，做好信息共享，这是一个老生常谈的话题。

2．更好的沟通来自更多的细节关注

工作中，我们经常使用假设，但是分布式团队在使用假设的时候需要更加的谨慎。距离本来就容易造成误解，过于苛刻地使用假设，反而不利于协作的产生。使用不当还会使双方产生很多的防备心理。先要明确广泛的共同点，与尽可能多的人交流，缩小假设的范围，从团队成员那里直接获取信息总是最好的方法。

轻易地说出“如果我是你，就……”有时候是很伤人的。如果是这样说过去的事情，就是一种对别人努力的轻视；如果是这样说未来的事情，就是一种建议了，这通常是很好的。

与别人合作，别人不知道怎么帮你，可以使用倒推法，即金字塔思维。要完成这个目标，把还需要做什么事情列出来。做好可视化，别人才可以找到一个适合做的事情来帮助你。

推广首接负责制，不管是谁接到了客户要求，不要觉得自己不是当事人而置之不理。帮助客户找到解决问题的人，并持续跟踪，直到有人接手与客户直接沟通或者最终得到解决。

帮助客户缓解用户压力也是离岸团队义不容辞的责任。比如用户给客户施压，要求一个端到端的测试场景的列表。虽然文档性的东西我们并不注重，但是为了帮助客户缓解用户施加的压力，这就变成了一件非常有价值的工作。正所谓，帮助客户就是帮助我们自己。

作为离岸团队的成员，我们的挑战还在于，相对于独立团队的简单做事，离岸团队除了做好，还需要能够经常把自己做的东西、了解的东西讲出来。我们都知道，很多时候讲出来是更有挑战的一项工作。你了解一项技术，你可以熟练地应用它，但是要给别人讲的时候，需要准备很长的时间，而且还不敢保证讲的效果。

进行全方位的沟通，项目的不同阶段要有不同的沟通策略。同时，鼓励离岸团队的不同角色成员多进行平行的沟通，避免沟通瓶颈的产生，但是要注意沟通后团队信息的拉平。作为一个知识型的团队，如果没有有效的沟通是很难将工作完成的。

说服客户要以价值为导向，如果客户坚持要做一件事情，我们一定要帮助客户分析这件事情的价值所在。区分出表面的假象和真正的价值，客户自然也会更加信服。

2.3　会议的组织

作为一个离岸团队，不管是团队内部的会议还是远程电话会议，不管是正式的例会还是非正式的讨论会，都是需要日常频繁经历的活动。

我曾经听到这样一种说法：会议是浪费时间的最好去处。听起来像是一句笑话，实际上它反映了很多时候大家对参加会议的感受。这是因为我们的会议经常被开成下面这样的会议。

• 会议开始的时候，远程会议的环境设备还没有准备好。

• 议题需要提前准备或者了解，没有提前准备的人无法充分参与讨论。

• 发散性讨论，很难结束一个议题。

• 会议没有时间限制，经常超时。

• 频繁跑题，讨论与议题无关的话题。

实际上，我们乐于参加下面形式的会议。

• 提前准备开会环境，减少无谓的等待。

• 为了提高开会的效率，我们可以采取顺序式讨论或者举手发言。

• 时刻保持原则，讨论的问题要有目的性，必须是能解决项目的问题。

• 与客户开会，最简单的方法是提前定义好会议议程，即使是生硬地把会议议程讲完，也算是完成了目标。

• 学会抛出问题，然后通过发散和收敛的方法寻找解决方案。

要做到以上几点，我们需要一个引导师（facilitator）。因为即使是在一个敏捷团队里，开会通常也是需要一个主持人的，但是我们不叫主持人，而是称之为引导师。因为工作职责的原因，项目经理、需求分析师和技术总监经常去作为一个引导师，其实，团队成员完全可以轮流来做，只要充分了解会议的议题即可。

开会需要引导师，不外乎有以下几个目的。

• 一旦发现有人偏题，应该及时提醒。

• 防止开放性的问题在会议上无休止地讨论下去。

• 鼓励所有人增加参与度。

• 平衡参会人员的发言，以防一两个人的意见左右了全团队的意见。

• 处理会议上发生的争执、冲突。

• 让离岸团队充分表达自己的观点。

• 让团队成员保持专注，防止开小会。

对引导师的具体要求如下。

• 安排会议时间、地点。

• 收集、准备会议议题，提前发放给所有人，好处是提前了解会议议题能增加参与度。

• 引导师有权决定发言人，或者只有拿到令牌的人才能发言，这样可以保证一个人的完整陈述不被打断，同时可以照顾广泛性，避免一个人或几个活跃的人主导了发言。

• 控制好时间，但是又不能说“我们时间到了，我们讨论下一个问题”这样的话，客户肯定也不答应，应该采取暂时搁置的方法，委婉地结束当前的话题。

• 引导师要面对观众，少面对黑板。

• 团队的引导师要学会引导式发言，例如，“小王你之前提出过一个方法，你能给大家解释一下为什么能解决这个问题”，让更多的人参与进来，虽然不用保证每次所有人都发言。

作为参会人员来说，也不是到场参加就可以了，而是要参与。

• 尽量提前了解会议要讨论的问题，做到带着问题参会。

• 作为一个普通的参会人，在会议上要关注的是整个团队，而不仅仅是引导师。

• 重复客户的问题“我可以重复一下您刚才的问题吗”，让客户确认我们对问题本身的理解。

• 重复客户的回答“让我来总结一下您刚才的回答吧，不准确的地方也请您纠正我”，确保我们正确地理解客户的观点。

• 防止信息的丢失，做好会议记录。

• 开会时，尤其是回答问题的时候，尽量避免仅仅回答“可以”“是”“否”。然后，就没有然后了。要给出自己的观点、自己的看法，哪怕是确认一遍对方的观点，这样别人才能确定你真正了解了正在讨论的问题。

引导师需要解决远程会议的效率问题，需要把一些发散性的讨论及时归纳总结。对于一些迟迟达不成一致的问题，促成一致或者想别的办法暂时搁置。不要在一个问题上停留太长时间，要保证团队开会的效率。这里提到的所有会议都是需要限定会议时长的。

2.3.1　典型的会议

典型的会议有下面几种。

• 站会（standup）；

• 迭代计划会议（iteration planning meeting，IPM）；

• 项目回顾会议（project retrospective）；

• 功能演示会议（showcase）；

• 各角色的碰头会（huddle）。

1．站会

作为分布式团队发生频率最高的一种会议，跨职能团队进行沟通的标准活动，站会是一种很有效的团队同步机制。远程站会要从内容上和时间上做好准备才能保证效果。

我们先来看看一个独立团队的站会是怎么做的吧。

我们通常选择早上一个合适的时间作为站会的时间，只要团队内部的人能够达成一致即可。内容上，每个人更新的内容仅仅包括前一个工作日手头工作的进度、当天的计划以及预期完成情况，还有与团队其他人分享的信息和需要的帮助。

相对于一个独立敏捷团队的站会，远程站会需要客户内容和时间上的双重挑战，才能达到站会的效果。一旦分布式团队能够解决这些问题，就能消除远程的不利影响。

从内容上看，每日站会绝对不是一个工作汇报会，不是离岸团队向客户团队或负责人汇报工作，而是团队沟通交流的平台，用以分享信息、表示承诺及提出障碍（遇到什么困难，需要哪些帮助），解决的是团队协同的问题而不是解决某个问题。除此之外，还要体现出每个人手头工作的进度。不能仅仅说前一天做什么功能，当天继续做这样的话，这样对别人、别的团队没有多大的意义，别人不知道你什么时候能够做完，然后可以计划下一步的集成。总之，我们的目标是让每个团队正在做的事情对其他团队尽可能透明。

在一个正常运转的团队中，保证站会不超过15分钟应该不是难事。我参加过的一个团队差不多15人，很轻松地能在15分钟之内把会开完，大家很清楚在会上说什么，什么事情应该线下讨论。因为站会不是解决问题的地方，而是提出问题的地方。为了保证效率，必须有一个令牌，保证任何时候都是一个人说话，即使分布式团队也是如此。我们把令牌通过摄像头交给对方，很有仪式感。

从时间上看，总的来说，安排全体参加站会是一个很好的尝试，这样可以充分了解其他团队的情况。但是时差的问题，经常让我们不容易找到一个对所有团队都合适的时间。表2-3所示是我参加过的时间段的站会或者临时的协调会议，可以想象协调各个团队定一个开会的时间是多么的不容易。

表2-3　不同项目的分布式团队站会时间

所以，如果时间允许的话，我们可以做到每天都开全体团队的站会。如果有团队的站会时间不得不安排到工作时间以外，我们会妥协成每周一次全体参加的站会，其他时间各团队分别开自己的站会。

跨团队的站会，可能参加的团队有的起了个大早，有的已经工作了一天。我们在站会的开始，可以讨论一些轻松的话题，让大家热热身。我们在与洛杉矶的客户团队合作的时候，每周一站会开始前都会先聊一些有意思的话题。我们聊过两真一假、最尴尬的时刻、看到的最喜欢的东西、你名字的本意等。

做好心理准备，有时候客户团队不会同意在他们的非工作时间开站会，我们就不得不在他们的工作时间范围内，找一个我们团队最合适的时间点。这时候，我们这个项目的成员也要调整每天的工作时间，例如，从9点到18点变成7点到16点。这样长时间也是很困难的，因此我们与客户商议出了两套站会时间。每套时间保证一个团队在工作时间内，与客户每两周切换一下站会的时间，这样对双方都公平，像表2-3中给出的那个包含北京团队和洛杉矶团队的项目那样。如果客户不能妥协，则只能放弃所有人参加的站会，而是派代表参加。

远程站会的组织可以有不同的形式。在一个项目中，我们发现由于每个人讲的内容并没有与故事卡直接关联起来，导致我们并不能很好地把讲的信息和看板墙结合，以至于看板墙成了一个背景。我们开始质疑，轮流讲这种形式是不是不适合我们团队，后来转变为由一个人主持，根据看板墙上的任务卡逐个更新状态和问题。很自然地，项目经理承担了这一重任，但是他需要一定的技巧，才能让团队成员之间、团队之间了解到每一个任务的状况。必要的时候他还要进一步做一些解释，保证所有的相关人都充分了解。

敏捷推崇自组织的理念，提倡团队的自我管理，而每日站会就是团队自主进行状态同步、风险管理及各项决策的非常重要的实践形式。团队通过站会来了解整体状态，并对暴露出的风险和问题做出集体决策。一个组织良好的站会，是出于团队的自组织需要，而不是客户的监控需求。

所以，关于远程站会，我做了如下总结。首先，既然是定期举行，则选择一个合适的时间是首要的任务。其次，敏捷方法倡导所有团队成员参加一个定期的状态更新的简短会议。简短非常重要，这也是为什么站着开会的原因。作为站会参加者中的一员，站会的目的一定要牢记：让别人知道你在说什么，能跟上你的更新。再次，对于站会的形式，有的分布式团队更适合采用按卡更新的形式。按照任务卡更新，会让参加站会的人更容易了解团队的整体状态，任务是主线；而按照人员来更新，对单个人的状态会有比较清晰的认识，人是主线。

在我最近的一个项目中，我们尝试了利用Wi-Fi更新每个人、每个团队的状态，这样就减少了分布式团队不得不安排到一个时间点的站会。幸运的是，这样竟然运转得很好，我们可以得到足够的对方的信息，只是缺失了团队间需要立即沟通的部分。我们只好要求任何紧急的事情，都要利用其他渠道去解决。现在，对于工作时间内没有时区重叠的那些项目，我们取消了跨团队的站会。但这并不表示我们没有了面对面的沟通，因为我们还有各团队少数代表参加的一些沟通会。严格意义上的全体团队的站会没有了，但是一周一次或一周两次的各团队代表参加的新站会诞生了。

2．迭代计划会议

迭代计划会议代表着一个新的迭代的开始，会议的内容主要分为展示上个迭代的成果和介绍新迭代的任务两个部分。这两部分需要项目经理和需求分析人员花费一定的时间进行一些前期准备工作。准备好你的故事卡①给其他人做简单阐述，分享你对故事卡的了解。

①故事卡是敏捷开发团队对功能的划分方式，每个有业务含义、可以独立开发的功能都可以作为一个故事卡，有利于开发排期和工作交付。

在迭代计划会议上，开发团队和产品负责人通过详细描述什么在范围内、什么在范围外（紧接下个迭代的工作开始之前）形成交付契约。到计划会结束时，应该就不再有关于需求、解决方案或接收标准的隐藏假定和潜在误解了。

项目经理的会前准备包括以下事项。

• 统计已做完的故事卡，展示上个迭代的所有故事卡的状态。

• 计算上次迭代完成的故事卡的点数，显示交付速度。

• 生成燃尽图和燃起图。

• 其间遇到的问题的总结。

需求分析人员的会前准备包括以下事项。

• 分布式团队需求分析人员、客户产品经理等的碰头会，解决需求中的疑问。

• 准备好新迭代交付的故事卡的范围。

• 与客户确认每个故事卡的优先级。

会议的议程通常是下面这样的。

• 向团队和客户展示上个迭代的成绩和新迭代的计划。

• 新迭代故事卡介绍，团队对每个故事卡估点。

• 迭代会议都有最后一项，即团队请假计划，可以采用可视化方法，画一个请假日历，上面注明谁哪天不在。

如果要求分布式团队全员参加比较困难，可以把迭代计划会议中的故事卡逐个介绍、估算的部分拆分出另外一个独立的会议。如迭代计划会议，各团队项目经理、需求分析人员、技术总监都需要参加，迭代计划会议之后安排的启动会议，要求各团队全员参加。

迭代计划会议要达到的目标包括以下几项。

• 根据团队的开发速度，选择合适的故事卡组成新一期迭代计划。

• 讲解在新的迭代要做的故事卡内容。

• 完善每个故事卡的验收条件。

• 对每个故事卡进行估算，估算的点数会对迭代的计划产生影响。

• 定义好要做的故事卡的优先级。

会议上经常出现的问题有以下几个。

（1）估算标准不统一

具体表现在以下两方面。

• 需求不明。如果碰到一个大家都不熟悉的领域，比如拿到一个故事卡后，大家都不知道到底该怎么下手，不知道水有多深，那么一般的建议就是：不要对这个故事卡进行估计。我们需要让一个人先对这个故事卡进行调研，在拿到调研的结果后再划分任务，最后再估计。

• 意见不统一。到底应该按照工作量估算还是按照相对难度估算呢？

很多团队会有这样的疑问，客户团队就更不用说了，有时候客户问起来，我们也不见得能解释清楚。估算的时候常常是这样的，小王说：“这个故事应该两天能做完，两天算1个点吧。”其实他是按照工作量（即人天）来估算的。可是，Scrum联盟创始人之一Mike Cohn的著作《敏捷估算与计划》中，真真切切说的是按照相对难度来估算的啊。

其实这取决了我们估算的目的。通常情况下，我们估算是为了安排迭代的计划，识别交付的风险。基于这样的目的，我们可以按照相对难度来估算，我们估计的点数也都是相对值，统计出来的交付速度也是根据前几个迭代和经验得出来的。如果我们估算的目的是为了统计团队的工作量，则可以按照人天来计算点数，这样的点数是一个绝对值。这就产生了一个问题，一个故事卡给不同的人来做，工作量肯定也是不同的，我们只能得到一个团队的平均值。

目前为止，我经历的所有项目中的估算可以分为3类。

• 在项目启动（inception）阶段，对所有故事卡的快速估算，用于确定交付的范围、交付的日期以及安排故事卡到迭代计划中。

• 在项目开始交付以后，每个迭代开始时的所有开发人员的估算。

• 在实际开发之前，开发人员根据需求细化的结果，再做进一步的细化，能够把每一个故事卡细化出一个一个的任务（task）。当然，这种基于任务细节的估算，不是所有的团队都会去做的。

第一种情况，应该就是按照绝对难度来估算。启动阶段需要快速地得到总的工作量，通常是技术主管根据自己的经验，加上需要综合考虑需求风险和技术风险，快速评估所有的故事卡，给出一个绝对的数值。这种情况的目的主要是为了商务上的需要，用于招标报价。

第二种情况，团队中支持按照相对工作量来估算就开始占上风。此时它的精确性根本不重要，这里估算的原则是，估算的一致性要高于估算的准确性。在这种情况下如果按照工作量估算，由于每个人的开发能力不同，同一个故事卡每个人估算的点数都是不同的。所以估算的时候不能拿自己的开发能力来衡量，而是所有人用同一个标准的样板卡来比较，得出估算的点数，这样大家比较的是同一个标准。

第三种情况，此时团队对细节了解得比较彻底，已经不是估算了，而能够给出完成需要的准确时间。

仔细观察不难发现，估算提供了一种有用的机制，可以引起和促使团队成员间彼此交流。估算会议可以帮助大家以不同的方式，对实现即将开始的故事、未来的架构方向和代码库中的设计问题有更好的理解。在这种情况下，任何输出的估算数字显得没有那么重要了。相似的对话可能会在很多场合发生，如果这些对话没有发生，团队就可以发起关于估算的讨论。相反地，如果你考虑停止估算，则需要确保估算时会发生的任何有效的交流在其他地方还能够继续进行。

包含相同基础类工作的两个故事卡该怎么估算？这个问题在我以前公司内部引起过几次大讨论，时不时地还会有人再提起。

比如，有两个故事卡是这样的：故事甲和故事乙都包含了一个基础性的工作丙，如果故事甲和故事乙分别来估算的话都是5个点，但是如果故事甲先做的话，故事乙后做可能只需要两个点，因为故事乙中包含的基础性工作丙，在故事甲中已经做完了。工作丙并不能单纯拆分成故事卡，因为它没有完整的业务价值，甲丙和乙丙才有独立的业务价值。

在这个问题上有两种观点，一种是将丙拆成一个3点的任务卡，甲和乙变成两个2点的故事卡；另一种是保持甲和乙两个5点的故事卡。两种观点都有自己的理由，持第一种观点的人认为，我们交付给客户的价值是7个点的价值，不能让客户为丙买两次单，虽然这种拆分故事卡的方法并不符合故事拆分的原则。第二种观点认为，从用户价值方面看，甲和乙是互相独立的两个用户需求。当第一个完成再做第二个的时候代价会减少，这说明的是复杂度降低了，开发的速度增加了，显示的是团队能力的增长。而且根据一致性的原则，我们不能把相同复杂度的故事卡因为先做后做的关系，所以给了不同的点数。

你可能也看出来了，第一种其实是面向技术的按照工作量来估算的方法，第二种是按照相对复杂度的面向需求的估算方式。

故事拆分的原则：遵循比尔维克的INVEST原则

　

INVEST原则中的INVEST指的是独立性（independent）、可协商性（negotiable）、有价值（valuable）、可估算（estimable）、足够小（small）和易测性（testable）。

测试的工作量是否要包含在点数当中？要回答这个问题，取决了我们对故事卡估算的目的。如果估算是为了计划下一个迭代的安排，我建议是不包含测试人员测试的工作量。原因如下：

• 不管是任务卡还是故事卡，都是有产出物的，而质量是内在包含的；

• 不管代码的质量高低，测试要做的步骤都是一样的。

从上面可以看出，在会议的过程中，我们对很多实践的看法是不一致的，统一这些分歧也是这个会议的目的之一。

拆分子任务，尽量细化并减少单个故事卡的点数，理想情况是每个故事卡都能在一两天完成。通过这种方式减少交付风险，即减少迭代结束时未完成故事卡的数量。

（2）会议时间太长

既然全体团队参加的迭代计划会议对某些团队造成了不便，我们就需要格外注重这个会议的效率。要想这个会议能够在最短的时间内达成目标，我们就需要在会议之前约定完成很多任务。

• 测试人员在理解需求的基础上完成测试脚本。

• 开发人员了解故事卡内容，并开始分解任务。

• 记录待澄清的问题。

所以在会议上，对于需求清楚的地方我们可以一掠而过，而把精力放在团队有疑问的地方。

（3）交付速度下降，会议上需要合理地解释

交付速度下降无外乎下面几个原因。

• 估点出现严重偏差。

• 需要向客户解释估计的点数，仅仅是估计。它的目的是用来制定迭代计划。

• 有技术债需要还。

• 调研的工作量安排得太多，可能需要让这部分工作可视出来，可追踪。

如果上一个迭代进度落后太多，那么这次的迭代计划会议该怎么开呢？

对于分布式团队，我们可能会有另外一个启动会议来分配所有的故事卡。通常情况下，哪边的团队拿到的故事卡，测试工作也由哪边负责，这样效率会高一些。当然我们也尝试过同一个故事卡，开发人员和测试人员在不同的地方，但仅限于澳大利亚这样与我们重叠时间比较多的情况。

从我做过的很多项目的经历可以发现，每一次项目的迭代计划会议都要求所有团队参加对之后每个人协调工作很有帮助。在这些期间，我也注意到，多数项目会设计自己的迭代计划会议，以适应不同类型的分布式团队。这种自适应能力也属于敏捷领域的重要范畴，适应变化，持续改进。

分布式团队恼人的时区问题，这时又成为团队会议的掣肘。虽然某些团队的时间不是很好，但是付出点牺牲参加迭代计划会议绝对是值得的，因为迭代计划会议没有可替代性，我们没有其他手段达到同样的目的，不像站会这样的状态更新会议，可以通过Wi-Fi来同样做到更新。

迭代计划会议尽量不要站着开，因为这个会议持续的时间比较长，如果站着，很多人会倾向于尽快结束这个会议，而不是利用所有人在一起的机会澄清所有需求相关问题。

3．项目回顾会议

Norman L. Kerth在2001年出版的Project Retrospectives: A Handbook for Team一书中有一句话，现在已经是项目回顾会议的最高指导原则：“无论我们发现了什么，考虑到当时的知识范畴、技术和能力、可利用的资源和实际情况，我们理解并坚信，每个人都尽了最大的努力。”

每次开会的时候，引导师都会朗读这段话，其实就是在重申我们开会的目的并不是要秋后算账、追究责任，而是要把注意力放到发生的事情上。让每个人放下防备，坦诚地探究在过去一段时间内团队的得失。当然，我们不能指望这个最高原则能够解决一切问题，我们会发现会议上原先踊跃发言的人还是踊跃发言，但是发言的时候多了一份免责感；团队成员中原先小心翼翼的还是会采取防御策略，但是他们至少迈出了第一步。最高指导原则实际上是在提醒我们的团队，大家的目标是寻求解决方案而不是指责人为因素（主观）和环境问题（客观）。我们也知道一个原则并不能改变人的行为，但是这是一个很好的开始。因此我们继续提倡在每次会议前阅读最高指导原则，以推动一个更有建设性、更开放的会议。

回顾会议要达到期望的效果，需要参会的团队成员间有极高的信任。这对分布式团队极具挑战性，所以如果没有平时建立起来的信任，很难保证每个团队的人都能畅所欲言。将信任融入每个人的血液当中，真的不是一句口号，这是每个人为之努力的目标，而且是切实的目标。

项目经理可以通过一对一的形式了解每个成员，以及推动正式和非正式的活动融洽团队关系。

离岸的不同团队的信任建立，需要注意如下的平时活动。

• 双方团队的透明性；

• 通过不间断视频超越空间的距离感；

• 定期的互访。

安全性检查也是回顾会议中一个重要的环节，其标准如表2-4所示。

表2-4　回顾会议的安全性检查标准

当一个团队的项目经理比较容易相处的时候，安全性检查的分数就比较高。当项目经理比较强势的时候，大家可能不太敢畅所欲言。当有团队成员觉得会议处在一个不安全的环境之中的时候，这样的会议的效果将会大打折扣。必须想办法把会议环境变得安全，比如把某“身居高位”的人请出去，直到大家觉得安全了为止。经历过敏捷实践的人都会了解这些理论，但是在单个项目的回顾会议中，我还从来没有经历过把人请出去的情况，往往最后都是保留一定意见后的回顾。

当确认团队在回顾会议上的安全性之后，回顾会议就可以进入正式的议题。如果想以最快的速度让大家活跃起来，选择一个破冰游戏是一个很好的方法。用得比较多的是画一幅画，来表达过去一段时间你对项目的感觉，时间可以是5~10分钟。如果回顾会议的周期比较长，画一下以时间为横轴的心情曲线，可以很好地帮助大家回忆这段时间的典型事件以及前后关系。

回顾会议有迭代的回顾会议和项目的回顾会议两种。两种不同的回顾会议有不同的目的。

• 迭代的回顾会议，关注的是上一个迭代出现的问题、下一个迭代需要做的改进。这也是普通团队经常做的回顾会议，本节中所说的回顾会议基本上是迭代的回顾会议。

• 项目的回顾会议，从更高的层面进行回顾，以一个项目的整个生命周期为出发点，找到提高项目交付的问题和方法。

回顾会议在形式上可以有多种形式。

• 最普通的是从“好的方面”（well）、“需要提高的方面”（less well）和“建议”（puzzle）这3个维度开始发散。这种形式是被采用最多的一种回顾方式，简单、易行，不需要向团队解释如何去做，尤其受到相对大型的团队和时间紧张的团队以及分布式团队的欢迎。

• 采用海星图。如图2-3所示，这个维度稍微复杂一些，但是给参与者提供了几个思考的方向，更容易产生行动计划。

图2-3　回顾会议使用的海星图

回顾会议引导师的职责

　

除了上面提到的宣读最高指导原则、进行安全性检查、带领团队玩破冰游戏，引导师在回顾会议上还有更重要的事情做。

（1）声明这次回顾要涵盖的内容，一般是从上次回顾到当天时段内与项目、团队、所有人相关的所有事情。给大家罗列一些重要的事件和里程碑，便于团队思考和进行发散性思维。

（2）对每个环节进行计时，比如收集问题的时间给10分钟足够。

（3）对收集的问题进行分组。分组也是很有学问的，并不是相似的问题放到一起就可以。应该把同类的问题放到一起，我们可以从前端的技术问题、后端的技术问题、自动化测试的问题、性能方面的问题、与客户或其他团队沟通的问题、进度方面的问题、团队协作中的浪费问题等维度进行考虑。

（4）回顾会议中是一定会提到比较敏感的话题的，务必对事不对人，一定要让团队充分认识到这一点。

（5）带领团队对投票选出的议题进行分析，引导出针对这些问题需要采取的行动计划。

（6）为每个行动找一名负责人。

（7）本次回顾会议结束之后，下次回顾会议来临之前，监督行动计划的完成情况。

回顾会议开始的时候，首先要评审上次回顾会议产出的执行情况。执行完的一笔勾掉，没有执行的需要说明原因。如果是失去了意义，可以直接去掉；如果还有继续做的意义，则放到这次的执行列表里。

回顾会议也比较符合左右脑的规则，先右脑风暴发散出尽可能多的观点，然后让左脑发挥作用，开始归纳整理、分类，变成数个主题（一般四五个）。

这个会上很容易做到让每个人都发言，因为绝大多数的卡片需要当事人解释希望表达的目的。

既然回顾会议的根本目的是改善，那我们为什么要列举和讨论做得好的方面呢？其实，除了找到需要改善的方面，还要肯定团队取得的成绩，树立团队信心。调节会议的气氛，眼里不能总是沉重、负面、严肃的话题。

就我的经验来看，很多回顾会议上，经常会提出客户反馈不及时等问题。这类问题其实不要等到回顾会议的时候才提出来，我们需要将这种反馈不及时的问题对我们计划的影响、进度的影响给客户明示出来，让客户体会到影响有多大，并且认识到会造成多大的浪费。客户也是专业人士，当了解到足够的信息后，一定会有更好的判断。如果只是默默地在等待，信息都是隐藏着的，没有人能知道真正的影响有多大。

会议中产出的行动计划，除了谁负责做哪个（一定要有负责人来跟踪和处理，这一点很关键），还有一个重要因素是什么时候完成。然后把每一行动转化成一个任务卡，放到待办事项列表里，与其他故事卡一起排定优先级。一定要确保回顾会议的产出得到实施，不然持续改进的环路在这里就断了，这是一个容易忽视的环节，很多人觉得这个实践就是回顾会议本身，殊不知产出物才是会议的目标，确保目标实现才是达到了目的。也正因为我们能够严谨地从失败中抽取出价值，所以我们可以让团队有机会在一个迭代周期内尝试一些新东西。

如果一个团队单独做回顾（绝大多数的分布式团队是这样做的），需要考虑让一个团队吸取的教训或收获的经验让其他团队也能吸取到。回顾的成果都会给其他团队分享，不管是发电子邮件给所有的团队，还是放到线上（Mingle、Trello、Google Drive）。当这些经验不断地被重复时，就能形成潜意识，在下次遇到问题的时候正确应对。

对于分布式团队，我们一直采用Ideaboardz这个在线白板工具，它就像一个虚拟的可以贴便利贴的墙。在系统内创建卡片是不记名的，卡片内容对所有参与者可见。因此，它也可以用作分布式团队的安全检查工具使用，快速而且简单。项目经理一定要提前建立好本次回顾的虚拟板，这样团队成员可以提前把一些想要说的贴上去。这样当回顾会议开始以后，每个人都经过了一些思考，讨论也更容易切中主题。

分布式团队远程回顾的简单流程如下。

• 计时5分钟的时间让所有人在板上创建卡片，每个卡片仅记录一个问题。

• 引导师把相似的卡合并，且保证所有人理解了问题的描述。这样投票的时候，同一主题的选票也不会分散。

• 2分钟内，所有人开始投票选择希望深入讨论的议题，每个人可以有3票。

• 深入讨论得票最高的3～4个议题，每个议题要有产出的行动。如果团队规模小或者时间充裕，可以讨论更多乃至全部的议题。

• 在会议的最后给每个行动找到负责人，负责人要保证行动的执行和完成。

回顾需要首先把问题暴露出来，我们才能持续改进，更出色的工作是敏捷团队永远追求的目标。精益追求持续改进，回顾会议最直接地诠释了这个原则的核心实践，会议最后的产出物就是致力于对过去的提高。回顾会议本质上是为自我管理团队弥补没有专业管理者而设立的，所以在这个会议上要达到什么目的，每个人都要好好考虑。

既然每次迭代都要上线，那么每次迭代相当于项目中的一个小型生命周期。在上线之后我们就需要回顾这段经历的经验教训，以达到团队持续提高的目的。

总之，回顾会议是最有价值和重要的Scrum会议之一。这是一个改进会议，通过该会议，团队回顾什么地方可以改进，以及讨论如何确保阻碍团队达到目标的问题，在以后的迭代中不会再次发生。同时，这也是一个能定期捕捉变化的实践，定期调整团队的大方向和日常工作，为“敏捷拥抱变化”尽一份力。回顾会议是遵循质量管理大师戴明的PDCA过程改进的价值体现。

4．功能演示会议/迭代评审会议

顾名思义，这是把完成的阶段性工作展示给客户的机会，并且是收集用户反馈的过程。但是在有些团队，他们把开发人员在自己的机器上向需求和测试人员展示开发结果的过程称为功能演示（showcase）。我更倾向于把这个展示叫桌面检查（desk check），这个名字来得更直接，而且更容易与向客户展示区分开，不容易引起歧义，不需要额外花时间解释，符合敏捷的精髓。

那么，团队为什么需要这样一个展示会议呢？

第一，这是一个向客户展示团队工作成果、工作进度的好机会，客户也都非常欢迎这样一个“汇报”性质的会议。

第二，只有当我们给客户展示产品的时候，客户才会意识到哪些功能真正是必需的。

第三，在敏捷的流程中，我们需要客户最终接收一个故事卡。如果没有这样的一个演示会议，客户就缺少接收故事卡的上下文以及接收的动力。有了这个例行的功能演示会，客户很乐于在一两天内接收完成的故事卡。

具体地说，做好一个成果展示会，我们需要做如下工作。

• 至少一次的演练，完成后务必把状态和数据恢复到演练前的状态。

• 真正的远程成果展示会开始的时候，提前15分钟把环境准备好，包括视频会议系统和外部独立的麦克和音响系统。

• 有额外备份的会议系统则更好。

• 成果展示的议程表，这样在会议中，整个团队就能知道进展到哪一步了。产品干系人也能清楚从上次展示会到现在团队的工作进展。

• 使用多屏幕显示，现在的视频会议系统大多支持同时显示团队的实景和演示者的共享桌面。

• 预定会议室。

理想情况下，对每个分布式团队来说，每个迭代展示一次开发成果，然后根据展示的结果，协调上线一次。

功能演示会展示是测试人员已经验收的功能。我知道很多主管非常希望尽早把做出来的东西拿给客户看，有些客户也渴望尽早看到团队做出来的东西。但是，展示的过程中非常容易出问题，有些问题有可能会影响客户对软件的好感。很多团队吃过未充分准备就向客户或者用户展示的亏。

如果有远程的参加者，应该提前将要展示的内容发出去，依靠电话会议的参加者需要知道上下文才能更好地参与进来。

给客户展示开发成果的时候，如果需要在客户现场的人主导这次展示，远程的离岸团队需要做好充分的准备，包括但不限于帮助演示的人准备好演示脚本，并且要有完善的用户场景和数据。定义出整个演示过程的所有测试用户的角色扮演，就像电影的演员表。如果是移动应用，要使用工具软件映射到计算机上，这样大家都能看得清楚。

管理好客户的期待，要提前明确成果展示的范围。评估将要展示的内容，圈出需要客户明确的地方，在会议上让客户确认下来。对展示过程中发现的问题、客户提的反馈，要做好记录。收集的反馈，转化成故事卡，需要需求分析师把它放到待完成故事卡中，重新排定优先级。定义好用户的角色，使用定义好的一个个用户旅程的方式，让用户感受使用的过程。

因为我们采用了敏捷开发方式，可用的软件是客户主要能看到的产出之一，所以做好定期的功能演示以及让客户尽早试用软件就非常重要。

给客户以及利益相关者展示完后，最好他们也能够直接使用展示所用的测试环境，让他们亲手使用这些功能往往会有让人惊喜的发现。

会议之后，我们要尽快地让客户验收已经完成的需求。只有用户接收了，才算是真正的完成，很多人会忽略这件事而去忙新的功能需求的分析工作。如果这个环节是写进合同的，则项目经理要负责让团队的人知晓，因为用户延迟接收会直接导致项目的收款延误。

除了以上定期的稍微正式的成果展示，我们还会鼓励客户进一步深度使用我们已经完成的功能，以期待更有深度的反馈。如果条件允许，比如已经建立起稳固的客户关系，我们甚至允许客户试用还没有完全做好的功能，以尽早地得到客户的意见。因为很多客户是在接触到产品之后，才会真正明白自己的需求。相信我，这样的客户不在少数。

功能演示的本质是反馈环路的一个重要的节点。得益于敏捷工作方式的迭代式开发，我们可以邀请客户在此时评审团队的工作。在一个普通的开发团队，一般遵循业务分析师整理需求、开发人员按照需求来实现一些功能、转交给测试人员进行验证、发布到生产环境给客户使用这样一个流程。在敏捷团队里面，我们能够给客户展示还在生产过程中的功能。客户能尽早地看到开发出来的功能是不是他们想要的，甚至是未完成的功能，只要它有了部分价值。因为在我们的团队完成一天的工作，把工作成果提交到代码库几小时以后，美国的客户团队可能就可以下载最新的代码。更大的可能是，直接下载最新的打包好的应用，安装到其本地，然后尝试最新的功能。客户可以非常快地察觉到与需求不符的地方，虽然不像本地团队可以立即更改，但是等到分布式团队再次上线的时候也可以处理这个问题了。

要让离岸团队与本土团队的客户如此紧密地合作，我们需要给客户我们的开发环境和测试环境的权限。刚开始的时候，客户对这些根本不会感兴趣，表面上很高兴我们能这样做，实际上他们不会按照我们的想法去做，我们要帮助客户消除技术障碍。找到一个最简单的方法，让客户看到我们最新的成果。比如，移动开发的项目，我们把最后打好的包全部放到Testflight或Dropbox上，客户非常容易下载和安装。而且他们看到的和我们看到的完全一样，都是最新的。

5．非正式碰头会

在一个分布式团队里，由于都是采用功能团队（feature team）的工作模式，团队的站会更多地关注故事卡的状态更新、遇到的障碍。各个团队中相同角色的成员也需要定期地开会，在一个横向的维度上沟通共同感兴趣的问题，如表2-5所示。很多时候，这是一个共享桌面的视频会议，而且时间大多控制在半小时到一小时。有事没事，己方团队不同角色的人，主动寻找一些话题与客户方同角色的人多聊聊，多讨论，拉近双方距离。

表2-5　分布式团队常见的碰头会

分布式团队优化沟通的流程要考虑时间的因素。比如曾经有个项目雇用了一个马尼拉的团队帮助我们做一些集成方面的专门工作，每天工作结束前安排一个开发团队的碰头会来沟通当天遇到的问题，以及另外一个目的，即验收马尼拉团队的工作。

分布式团队对会议的准备要求要更多一些。己方发起的会议，提前准备好会议日程表发出去，并说明这次会议期望的产出。其他团队发起的会议，我们也要有充足的准备，了解尽可能多的上下文，在会议上才有更多的参与度。

团队要根据自身的情况来决定一些准备工作。曾经在一个项目上，客户团队的沟通对象全都说“印度英语”，为了更好地沟通，我平时就到视频网站上寻找一些相关材料以适应口音。因此顺便说一句，随着IT行业在全球的发展，适应不同的口音对交流也是很有帮助的。

2.3.2　离岸团队的会议技巧

安排不同团队的会议，在时间的选择上应尽量减少对各团队工作时间的中断。一个会议可能会毁了整个下午，因为中间安排的一个会议把一个下午分成了两个小的时间段，以至于做不成一件像样的大活。不是紧急的会，不要马上就找人开，要给团队保证完整的工作时间。

需要的会议要安排尽早开，因为准备会议的时间大多是浪费的。推荐把会议安排在站会等例会之后，这样人比较容易找齐，不会因为有人手上有活推迟，而其他人还得等着。

到客户那边或者邀请一些客户来开会，不要客户坐在一边，我们坐在一边，这样会有种对立感。一些非正式的会议，尽量安排不熟悉的人坐在一起。不然的话，熟悉的人坐在一起，最后会变成好几个小会。

在一次会议上不要讨论太多的主题，不要邀请太多的人，因为这样无法控制会议的时间，会降低会议的效率，会议的产出也会下降。把大会拆分成仅有相关人员参加的小会，是一个很好的实践。

我们开的每一个会议都会有一些期待的产出物，或者说要解决一些问题。但是我们也不能紧盯着议程、交付物这些东西，这样会使开会的过程没有乐趣，显得冰冷。我们要利用这些机会，尤其是一些非正式的碰头会，拉近团队的距离，活跃团队的气氛，保持活力。

会议中控制开放式讨论，引导下结论。对于可能的开放式讨论，我们的解决方案是团队内先小范围地讨论出一些东西，然后拿到全体会议上讨论。

对于一些其他培训会，有个最简单的开场方式：首先针对这次活动的内容和方式做个介绍，并让所有参与的人提出在当前使用或应用的时候碰到的问题和对这次培训的期望，把大家提到的点收集起来。然后在讲完的时候，再来回头看看这些点。哪些点已经讲过了，然后讨论一下未谈过的点。针对有疑问的点，如果会上不能达成共识，可以放到线下单独讨论。

就像本章开头所说的，喜欢开会的人真的不多。分布式的敏捷团队的会议又不能减少，这些会议是远程团队日常沟通不得不采取的方法。定期的例行会议会强化团队的归属感，就像是我们的传统节日，是一个团队团聚的时刻。不要让团队把这些会议变成一个个负担。

2.3.3　小结

过去的经验告诉我们，没有视频图像的电话会议很难吸引参会者的注意力，因此我们决定在所有的远程日常会议、代码评审和结对编程中使用视频。此外，如果条件允许，我们还安排不同团队的人当面交流，最初是让团队内成员（不是项目经理）进行旅行。后来不断地轮换，所有团队都经历了这样的旅行，并花了一些时间来互相熟悉。现在，旅行则是按照团队成员的需求及可行情况进行安排，即能够照顾那些由于需要照顾自己的孩子而不愿意旅行的成员。对异地工作的人们来说，如果有机会当面会晤，那么其沟通会发生显著的变化。

当会议成为一种例行公事时，团队成员往往会很快形成一个共同观点，这是一个明确的信号。

虽然所有人都认同经常沟通对项目管理的重要性，但一旦项目在进行中，成员们很容易忘记彼此会面沟通，或向其他利益相关者们提供项目的更新进度。因此建立定期召开沟通会议的机制，包括谁来参加这些会议、谁需要参与，将有助于保持项目的顺利进行。正确的人数是非常重要的，因为太多的人会把事情复杂化，大量的时间可能会浪费在一个问题接着一个问题的讨论上。

每次开完会议的总结非常重要，不管是当场在白板上的可视化总结拍照，还有当天电子邮件方式的总结，都是非常有效的。因为会议刚结束的时候，每个人头脑中对讨论的问题都是最新、最全面的，此时最容易达成共识。如果犯了拖延症，每过一天，都会有一些信息丢失，再次沟通的时候，我们可能会听到这样一些话：“我当时可不是这么说的。”“你当时肯定误会了，我的意思是……”

2.4　常驻代表和短期面对面的访问

只要是团队之间的合作，就一定会有磨合，就像你买了辆新车也需要磨合一样。磨合意味着互相了解对方的秉性、优缺点，找到一个双方配合顺畅的状态。本章介绍的实践就是为了让这个磨合更顺畅，并且尽快跨过磨合的阶段，达到顺畅合作的阶段。

新项目启动的时候，我们一般会去客户所在的办公室或者邀请客户来我方公司，以更好地进行项目开始时的沟通。在项目启动的时候，快速理清客户的业务、客户的想法以及对未来的愿景。可能的话，团队还有机会接触到最终的用户，这对于远离客户的离岸团队来说是不可多得的机会，一定要好好利用。除了需求，我们还需要与客户的技术人员确定技术架构，如果有遗留系统，可以在现场深入地了解遗留系统的各种信息。

对于一个规模够大的项目，离岸团队沟通的需求很多，我们可以在客户那里安排一名常驻的代表。常驻代表可以提高与客户间沟通的效率，取得更好的沟通效果。如果没有常驻客户的代表，定期地面对面的沟通必不可少。我们可以短期地访问客户，比如两周到一个月，也可以邀请客户到离岸团队所在地访问，或者按时间每半年一次，也可以在项目达到里程碑的时候安排面对面访问的机会。

2.4.1　常驻代表

面对面的交流使得团队能更容易地进行头脑风暴，或者进行一些复杂的讨论。当大家都在一个地点办公时，很容易将所有相关人召集到白板前来解决复杂问题。因为大部分团队更喜欢能够在物理白板上贴纸条显示各种状态，而不是使用能够提供电子白板的工具。这也是为什么分布式团队即使有了任务管理系统，仍然倾向于建立每个团队自己的物理白板的原因。比起远程办公的团队，在同一地点办公也更容易成为朋友。

一方团队向对方团队派驻代表的方式，在很多的项目上存在，尤其是大型的项目。依靠常驻的代表对双方团队的了解，达成两个团队日常的无缝集成。这个常驻代表肩上的担子就比较重，他必须保证对两方团队做的事情要非常熟悉，而且随时需要评估一方的工作是否会对另一方造成影响，这是每次做之前需要思考的。开始做的时候如果需要对方配合，常驻代表还需要协调双方的人员，在合适的时间准确地完成协作。当然，在实际工作中，常驻代表的工作绝不限于此。

常驻代表有客户派驻离岸团队的和离岸团队派到客户现场的两种。

1．客户派驻离岸团队的

我之前服务过的外包公司有个很大的交付团队在北京，分成了5个子团队，这些子团队也在十人左右。项目刚开始的时候做得有些磕磕绊绊，整个项目的沟通成本很高，效果也不是很好。后来我们意识到沟通的问题，要求客户派一名专家过来常驻，解决需求方面和技术方面的决策问题。客户采纳了我们的建议，当然也会定期轮换派遣的人员。

让客户代表在我方交付团队中这一方法对工作时间重合非常少的情况非常有效。这样的做法也一直持续到现在，已经7年了。

客户来访应该注意什么呢？

• 团队的精神面貌。

• 专业性的表现，经常性的技术交流，团队建设，客户领域知识的学习。

• 着重解决需要面对面的问题。

2．离岸团队派到客户现场的

我经历过两个这样的项目。一个项目规模比较大，离岸团队总共有30多人。在客户现场我们常驻两个人，一个是项目经理，一个是需求分析师。项目经理负责项目的进度和风险的管理、优先级的沟通以及向客户进行阶段性的开发成果演示、收集客户的反馈，需求分析师负责需求的确认和解释、需求范围的控制。另一个项目规模不大，离岸团队基本保持在10个人上下，不过我们从一开始就在客户现场常驻一人。由于我们对于客户的业务比较陌生，所以一开始外派的是一名资深的需求分析师，帮助我们离岸团队理清客户复杂的业务逻辑。这对于我们离岸团队从一开始就避免陷入需求不清的泥潭帮助很大。后来我们派出的是一名资深的开发人员，此时我们的开发已进入关键阶段，需求已逐步清晰，技术上开始不断遇到挑战。双方的解决方案时常会引起争论，更多的是客户团队对离岸团队的质疑，此时我们的常驻代表能更好地把我们的声音传达给客户，告诉他们我们的根据。同时，常驻代表也能把客户的担忧传达给离岸团队。

去客户现场应该注意什么呢？

• 注意客户口头表达的对优先级的看法。

• 每天要及时为离岸团队解决疑问，从客户处得到确切答案。

• 将客户的调整及时反馈给离岸团队。

• 离岸团队有什么不好的苗头，要及时解决。

选什么样的常驻代表派到客户现场呢？

• 角色上看：资深的项目管理者、需求分析人员、开发人员都是长期派驻客户现场的人选。他们需要与客户持续地沟通，在客户现场可以有效地降低沟通的成本，提高沟通的有效性。

• 技术上看：我们派驻一名技术专家在客户现场，能有效地决定客户的技术选型，提升客户对技术架构以及解决各种技术问题的信心，对分布式团队的代码审核也能起到桥梁的作用，有效弥合分布式团队在技术问题上的分歧，减少无效的争论。

为什么要派常驻代表（on site）呢？

敏捷工作方式非常推崇面对面地沟通。对于分布式团队，我们也坚定地认为，把离岸团队的人送到客户现场，与客户一起工作会有很大的帮助。当然，项目启动的时候，我们一定会尽可能把团队的所有人集合在一起。即使做不到把所有人集合到一起，也会把核心的成员集合到一起。但是，我在这里要谈的是项目在平稳运行期间，我们如何规划分布式团队成员面对面沟通的问题。

一开始我们可能会倾向于安排一个像代表一样的人，常驻在客户那里，负责协调双方各种一般性的工作。当我们这样做了以后，慢慢发现这个代表会变成双方团队沟通的唯一通道。就像一个中继站一样，分布式团队的沟通在这里变成了一个点。某些时候，如果这个人不是一直可靠的话，还会变成一个瓶颈。如图2-4中的两个图，我们倾向于右图所示的结构。

图2-4　沟通的通道

既然以纯粹沟通为目标来派遣常驻代表，会极有可能导致这样的问题，那我们该怎么做呢？我经历过向客户派遣常驻代表的方式有很好的效果是基于这样的原则：即使有常驻代表也要坚持双方当事人直接地沟通，常驻代表只起辅助的作用。一次我们是派驻了一名业务分析师，在客户现场的主要职能也是业务分析。对于双方沟通方面的职责，只做必要的协调，真正的工作由双方当事人直接去做。因为我们是扁平化的团队，成员也都有很好的自我管理能力，需要与客户交互的话，我们倾向于当事人直接与客户的相关人员联系，这也促进了客户人员的做事风格向扁平化转变。信息在团队间传递的准确性提高了，解决问题的效率也提升了。我们的常驻代表因为在项目中有具体的工作，可以与客户深入结对工作，向客户展示我们的专业能力，建立更紧密的个人关系。

我们倾向于以3个月或者6个月为周期，轮换常驻代表这个角色。当然也可以少于3个月或者多于6个月进行轮换。因为常驻代表在对方团队的时间过长，就会对本方团队的情况失去了解。一个最简单的例子是，本方团队的人员变动，可能有一半的人你已经不熟悉了。即使不考虑常驻代表本身愿不愿意待更长的时间，也应该考虑让更多人有机会去更深地了解另外团队的工作。这里可能还有另外一个问题，如果团队成员本人的意愿并不愿意离开家，长期在地球的另一侧工作，我们是无法派遣这个成员的。我们在组建离岸团队的时候就要考虑这一因素。

通过常驻代表的工作，我们更容易建立起信任，这份信任也相对牢固。对于身处一个“友谊的小船说翻就翻”的世界，维护这份信任，就是维护分布式团队的合作基础。因此，如果你们的项目作为分布式团队的一部分，不管是同一公司的团队，还是客户的团队，抑或是供应商团队，长期没有人员交流了就要引起重视。我建议立即制定一个访问计划，尽早地选一名常驻代表到对方团队那里，与他们坐到一起工作一段时间。一定要在团队间出现沟通障碍、误解、互生厌恶感等不好的苗头出现之前，就解决这些风险。

3．注意事项

离岸团队和常驻团队的沟通通道必须保持畅通，虽然我们知道常驻团队还有他们本身的工作要做。

如果我们有常驻客户团队，离岸团队更新给客户的信息必须同时或提前更新给常驻团队。避免出现客户掌握离岸团队的信息比我方常驻团队还多的情况出现。

提高客户的满意度，还体现在客户反映一个问题以后，不需要与离岸团队的好几个人打交道才能解决这个问题。首接负责制，通过离岸团队内部的跟踪、转交，把结果反馈给客户。问题的澄清、确认、解决、反馈，都需要及时联系常驻代表协助完成。

2.4.2　短期面对面的沟通

本土团队定期派遣业务分析师到离岸团队的好处是，能提供更全面的需求背景知识给离岸团队。这样，离岸团队就由之前只知道完成一系列的功能，升华到理解用户需要这些功能的原因。了解尽可能多的背景知识，对离岸团队未来的决策很有价值。

常驻代表是指在分布式团队存续期间，长期性地保持有成员在对方团队，常驻代表对双方团队都非常重要。即使有常驻代表，也不能影响安排其他的人进行短期的访问。如果派驻常驻代表对于自己所在的项目存在很大的困难，短期的访问则显得更加重要。安排的访问人选要有目的性，可以与销售部门确认客户的期望点，可以是自动化测试，也可能是敏捷转型。我们就可以派出最合适的人去帮助客户解决他们最关注的问题。

短期面对面沟通主要有两种形式：一是启动离岸项目，这对所有团队成员对需求理解一致很有帮助，开始阶段的共同工作也为后来分开后各团队分别开展工作期间的合作创造了条件；二是项目平稳运行期间的，这对维护双方的合作关系可以起到一个维系和支撑的作用。

程序员相对于其他员工来说比较内向，因而会更喜欢IM或者电子邮件的沟通方式以及弹性的工作时间。这就非常有可能出现分布式团队最易出现的两个问题：缺乏信任感和人际关系的疏离。诸如Skype之类的工具并非万能，定期的面对面交流是必不可少的，由此能促进成员之间建立更牢固的关系。

1．启动项目的短期访问

启动项目的访问的行程和内容需要提前规划好。也可以考虑迭代的周期，把访问行程安排至少一个完整迭代，比如两周。从我所经历过的项目来看，一个月是一个很合适的访问时间。我们可以从容地安排各项活动，这些活动包括一些讨论会议和真正的开发活动（第一个迭代）。在访问刚开始的期间，安排深度合作的工作非常重要，应让团队成员们尽早进行协同工作的磨合。

在启动项目访问的形式上，本土团队的客户业务关系人、项目经理来到离岸团队的办公室，与离岸团队一起制定一个最初的发布计划。让本土团队的开发人员访问离岸团队，帮助离岸团队在已有的代码库基础上开展工作，把过去在此代码库工作的经验和总结传递给离岸团队。

启动一个全新的项目，离岸团队应该尽可能地到客户的办公室，与客户的产品负责人以及利益相关者坐到一起。除非我们能说服所有的客户到我们的办公室来，否则一定要做好这个出访计划。

让离岸团队的业务分析师尽早地来到客户现场，投入工作，参与到早期的客户需求分析工作。因为在客户现场，考虑到客户的成本，我们要尽量压缩时间，尽早确定日程安排，整理资源需求列表，让客户知晓哪些是我们需要从他们那儿得到的。让离岸团队的任何角色人员，创造机会访问本土团队。如果本土团队是客户方，这项活动将更有意义。

启动项目的访问如此重要，原因是这个活动最有可能把尽可能多的团队成员集合到一起，这个活动的工作日程表里包括了很多重大的、方向性的决定，比如项目的发布计划、交付的功能的范围、交付的优先级等。虽然很多的客户提前做好了很多需求收集的工作，但是这里说的快速启动是一个探讨客户核心业务、掌握客户需求的，强度很大、非常高效的一个活动。

在这个阶段，我们必须确认客户的关键业务场景。在完成这次访问以前，根据用户画像的结果，找到每一个关键用户的业务场景，利用与客户和用户在一起的机会，保证这个关键的产出。

项目启动的时候，利用一切手段梳理客户的需求，包括客户方面所有的用户和利益相关人。在客户现场，与尽可能多的相关人会面，收集尽可能多的信息，利用好第二手资料，很多的问题客户可能已经考虑过、尝试过了。

引导客户思考问题，推动事情向前发展。提出问题是一个开始，引导出结论才是完成。所以不要忘记在热火朝天的讨论完后问一句：“我们现在的结论是什么？”拆分故事卡的时候，先给客户讲什么是故事卡以及Epic的概念。条件允许的话，我们可以把以上两种卡片都贴到会议室的墙上，展示整体的需求树，帮助大家从整体上思考需求。

当所有的需求都被整理出来后，下一步就需要开发人员做一个快速的估算了。故事估算的假设要说得清清楚楚，不然以后必定扯皮。实在说不清楚的话，加余量吧，视情况乘1.5或者2。如果客户有遗留系统，我们在做原型设计、交付设计的时候，如何与客户的系统衔接要说清楚，包括接口和集成时间点。

项目启动阶段，最难的问题是不确定性，它比“难”和“忙”更难对付。不确定性的源头来自需求的变化，既然这是一个变量，我们要让客户理解需求范围和上线时间、成本预算之间的关系。迭代计划需要包含可以拿掉的故事卡，尤其是对于上线时间固定的项目。就像最简单的软件必然包含缺陷一样，软件开发的过程不像搬砖，总有我们考虑不到的情况出现。上线时间不能变动的情况下，需求范围或者成本必须是可以变化的。至于向哪个方向变化，我们知道少考虑了需求的概率要远远大于设计过度、考虑过多的概率。

客户有时候会质疑我们拆分故事卡的时候拆得太细。一般是这样回答客户：我们的迭代周期很短，不能让一个故事卡一直做很长时间，如跨迭代，这样容易造成一个迭代结束有很多半成品；促进频繁提交代码，持续集成；容易度量；开发更专注完成一件事情，效率更高。

项目启动活动结束，我们会完成一个迭代计划报告，告诉客户什么时候UAT、每个阶段的时间窗是什么时候、每个月计划交付的功能包括哪些内容。

在启动一个离岸项目的时候，把不同地点的开发人员集合到一起，有着特殊的意义。因为在迭代正式开始前后，开发人员要经常一起工作、讨论，确定架构层面的方案。在架构层面，所有人必须达成一致，大是大非的问题不能有一点放松。在此前提下面，不同的分布式团队在回到原本的环境之后，才可以在自己的权责范围内选择自己的解决方案。如果开发人员在刚开始的时候没有作为一个整体在工作，很可能各团队在起跑的时候就偏离了主方向。越往后，把不同的团队、不同分工的人员捏合在一起的难度就会越大。

不管计划了什么目的的访问，一定要记住一点，我们不远万里来到这里的主要目的不是做更多的开发工作，而是建立亲密的工作关系，了解对方的工作习惯和工作方法，这些才是我们长期合作需要的。所以，在出发以前，好好评估一下你的工作日程表，看看是否有一些追求工作量的计划，把它们剔除出去，增加一些有益于促进不同团队人员交流的活动。如果在工作中建立良好的个人关系有困难，我们完全可以安排一些非正式的活动。一顿丰盛的晚餐，作为东道主邀请客人参观当地的名胜，都是不错的选择。良好的个人关系，可以有效地增加在项目中的信任，这对乐于主动提出问题很有帮助。没有良好的个人关系，很多问题可能就被隐藏起来或者留在那里，最后变成了一个坑。

（1）注意事项

开始几天要尽快掌握客户人员的组织架构、利益相关人。迅速搞清楚客户找到我们的最关键原因，以保证我们的方向不会错。重视客户的文字确认，尤其是涉及第三方依赖、需求范围的确定和一些基于的假设。

我们在L项目上出现过需求的点数膨胀得很厉害的情况。第一个迭代的故事卡在项目启动时候估算的点数是25，结果在迭代计划会议上变成了49。还有新需求的处理，一定也要估算并且从计划好的待办事项列表中置换出相同工作量的任务出来。

项目启动的时候去客户现场，时间紧，有很多不熟悉的领域或地方，为了保证团队的整体效率，不能在一些问题上停留太久，我们要与客户一起建立一些针对这些问题的假设，在假设的基础上评估技术选型、需求工作量。未来即使发生变动，客户一般会理解当时情况下的决定。这也说明了并不是只要我们去了客户现场，客户就能解决所有的疑问，很多时候客户也有说不清楚的问题，这是现实。

项目启动的时候去客户现场的人通常较多。尽量保持一个联系人与客户联系，如果客户需要面对很多人，会很头疼。因为他面对的人很可能信息不一致、没校准，他就不得不要把相同的事情重复好几次。

项目启动的时候，各角色成员要做好自己负责的事情。不要与客户讨论自己职责之外的事情，比如商业、价格相关问题应交给销售人员去处理。

引导客户做“减法”。当我们寻求客户对我们的设计反馈的时候，客户通常站在自己的立场上，确定自己需要的都在上面，而自己不需要的则不会发表意见，这就会造成我们收集的反馈只保证了不会缺少什么，而没有把不需要的东西减掉。这对项目的成功很重要，做了不必做的东西，不仅会增加工作量（开发、测试），增加了出问题的可能性，而且可能会降低性能，理论上还会影响项目上线时间。

对客户的敏捷思想教育也是沟通的一部分，越早教育客户，对团队的长期合作越有益。推荐一些书籍去阅读，安排一些主题讨论会都是很好的方法。

因为项目的启动时间是非常短的，我们没有时间把所有的问题都讨论清楚，所以必须使用假设，在双方都认可的假设的条件下，快速达成共识。所有的假设在正式的开发阶段都需要被解决，因为假设事先得到认可，这个时候从假设变成结论引起的变化也容易得到客户的认可。

（2）我们在一次项目启动中做过的假设

L公司现有的SAP系统提供非常全量的数据，但是客户方面没有人能说清楚哪些数据是物流系统不需要的。不管从技术上考虑，还是从用户使用上考虑，我们都不可能在一个页面的表格中显示1000多列的内容，所以我们要满足搜索性能的要求和导出数据性能的要求，就必须确定一个数字作为我们的技术方案的基础。除此之外，有些地方业务需求方面，客户自己也没有百分百确定。但是启动的时间很紧，无法做出完整的技术评估，尤其是性能方面的评估。我们最后做出了表2-6所示的假设，在很多模糊的地方，我们与客户在一些深度和广度的方面做出了约定。

表2-6　一个物流系统的假设列表

（3）假设的技巧

• 无法获知需求的边界，比如有一些确定要的功能，另外一些功能无法百分百地确定不要。需求仅包括确定需要的内容，另外那些什么时候确定了什么时候再加进来。

• 界面交互需要有多友好，可以与客户多用例子来说明，是否需要专业的用户体验设计师。

• 技术实现有多种选择，可以基于一种方案来评估。

• 与第三方集成的部分，假定他们在规定的时间完成约定的接口，并且让客户确保这件事情发生。

项目启动之后，各分布式团队回到相对独立的状态。不过，做决定的时候也一定要从整体上考虑，不要做仅仅对自己团队有利的决定。合理的决定源自一个目标：整体团队利益的最大化。做好自己的同时，还要学会拒绝别的团队做出的不合理决定。

2．常规的短期访问

（1）人选

既然只有把合适的人送到客户现场，才能达成既定的访问客户的目标，那么如果我们的目的是建立良好的合作关系，我们最好把未来需要与客户频繁沟通的成员送到客户现场；如果我们的目的是说服客户尝试一个新技术新架构，我们最好把有经验的技术人员送到客户现场。

在项目启动阶段，我们通常把最有经验的人派到客户现场，这样才能给客户留下最深刻的印象，并且保证项目开始的大方向正确。在项目继续运转的过程中，团队成员可以轮流到客户现场工作，客户也会对离岸团队的更多成员有恰当的认识。

我们虽然不建议派遣一个项目经理作为常驻代表到另外一个离岸的团队去，但是我们还是建议在定期的相对短期的派遣时，把项目经理作为一个候选人。项目经理的主要职责是化解团队之间的“冲突”，移除影响团队间合作的障碍以及识别问题，在它们成为障碍之前就解决掉它们。熟悉双方的团队情况，对于解决问题也非常重要。不管我们决定谁出访客户，一定要坚持每次访问客户至少要两个人一起。

对于有常驻代表的客户，我们还需要定期地访问吗？常驻代表需要对团队有全面的了解，侧重点是协调工作以及他擅长的领域，比如需求设计。如果是要做下一阶段的后端集成架构，则需要后端开发负责人来探讨。

（2）鼓励互访

对于日常正常进行中的项目，我们可以安排交替的互访计划。鼓励客户访问离岸团队，这样双方都有机会了解对方的工作环境和状态。比如上半年和下半年轮换访问。不管哪一方访问另一方都是非常有益的，但是如果要考虑访问方向的优先性，我建议优先考虑离岸团队访问客户的本土团队，让离岸团队更多地了解客户的方方面面。去客户访问是一个很好的机会，建立个人关系，建立信任，产生影响力；与尽可能多的人接触，了解客户团队的团队文化，了解客户团队的人的能力和特点、客户的开发流程。

首先要明白我们这次为什么要访问客户。当然，一个主要的目的是维护双方的关系和士气。除此之外，我们是否还有其他计划达到的目标？去客户访问需要提前计划好，我们要展示什么，获得什么，产出物是什么。尽早把我们的计划与客户的对接人沟通，防止一些必要的活动在访问期间无法进行。

对于作为客户访问离岸团队的模式，客户来或是为了建立很好的合作关系，或是在客户所在的行业有丰富的业务知识或者技术背景，能传递很多有价值的知识给离岸团队。所以要有针对性地安排客户来访的内容，因为客户来访一定有了一些计划，在了解客户计划的基础上，安排好团队活动。

短期访问的工作重点应该包括以下几点。

• 即使以前在远程都见过面，也应该把访问团队正式地介绍给客户，毕竟面对面的接触是视频手段无法比拟的，正式的介绍可以为后来的合作铺平道路。

• 收集阶段性反馈，包括客户对团队工作的反馈、用户对我们交付的软件的反馈等，同时把我方人员对客户人员的反馈带给客户。

• 引入新的实践，可以是持续集成、持续交付、采用Scrum或者看板的开发方式。面对面能更好地保证知识传递的效果，对于说服客户尝试一些新东西有很大的帮助。

• 阶段性发布之前的类生产环境的测试，或者阶段性发布之后的生产环境的支持工作。

• 组建一个离岸团队去中途接手部分本土团队的工作，我们需要在有限的时间内，获取尽可能全面的知识，把离岸团队拉到客户所在地和环境是一个比较好的选择。

• 如果客户的管理层发生变动，我们要建立新的联系。

• 在客户现场工作的人每天需要总结当天的收获，随时调整计划。

（3）短期访问中的知识分享

不管是访问客户还是客户来访，第一天的展示都是非常关键的，我们要清楚团队要展示哪些内容和技能。展示给客户，我们的团队为什么能做杰出的软件，而不仅仅是好的软件。

根据客户最希望从我们这里获得的方面来选择主题，想方设法把我们做过调研的东西、我们擅长的东西安排时间给客户展示。客户也需要给我们做一些介绍，比如客户团队的现状、开发流程、有无痛点、最希望改变的地方以及客户的业务知识、技术架构。对于时间安排，就我的经验来看，午餐讨论会是一个很好的机会，在这个时间可以比较容易地把所有的人召集在一起。

（4）出访客户期间的“其他”任务

在我们出发之前就做好详细的计划，提前安排好所有重要的会议。除安排好的计划以外，按照以下的经验去做一定没错。

• 如果客户现场恰好还有本方常驻人员，一定要与他们讨论一下我们本次访问的计划，并且利用经常一起吃午饭的机会，找出在现场工作的有用信息。

• 计划至少一次在办公室外的团队建设活动，建立情感联系。这取决于所有当事人的喜好，异域的美食、精彩的比赛、轻松的观光活动等都是不错的选择。

• 举行一次在客户现场的回顾会议。虽然你不可能很有效地参与，但这是一个很好的机会，可以观察客户团队近期发生了什么。

• 在离开之前，我们要确保此行达到了我们的期望值，期望的输出结果也都是清楚的。

• 观察客户的工作风格和做事方法，言谈举止都要把自己作为访问的本土团队的一员。

（5）重视“关系”

这里所说的关系，并不是我们通常意义上的人情往来、利益关系，而是通过了解对方的文化、个人爱好，尤其是音乐、体育方面，找到更多的共同话题。大胆展示自己，不要让自己在别人眼里成为一个无趣的人。毕竟，我们还要一起合作很长时间，平淡的合作也能完成任务，但为什么不让合作过程更有意思呢？有一次我们团队几个人去国外的客户哪里出差时，一个客户每天都骑自行车来上班，还把车扛到自己的工位旁边，自己也是专业自行车手的打扮。我们一个成员说他也非常喜欢骑自行车，每天也是骑自行车上班。然后我们的客户就邀请我们周末一起骑自行车去山里玩儿。结果，我们度过了一个非常开心的周末，更多地了解了当地的生活，与客户的关系也更好了。私下交流对任何团队都是有益的，总会有些特别的东西是在成员们私下非工作时才会发生的。

如果有机会去客户现场，需要知道哪些注意事项，需要做哪些准备工作呢？这是每一个初次去客户现场工作的人都需要考虑的问题。下面是一封给将要到客户现场工作的团队的电子邮件。

大家好！

马上就要到客户现场办公了，这将是与在办公室做项目完全不同的环境。现场做项目对项目与客户关系既是机会也是挑战。如果我们在现场沟通更顺畅，让工作成果更可见，就能大幅提升客户的信任。但如果不注意沟通和工作习惯上的一些细节，就可能对双方的关系造成打击。

以下是一些注意事项，请大家务必仔细阅读，经常相互提醒和督促。如有遗漏，请大家补充。

工作时间：尽管有时候加班难免，但每天的上班时间务必与客户在第一天就达成一致，并严格遵守。如前一天加班过晚，也要事先与客户就第二天的上班时间达成一致。

现场沟通：因为时刻被客户环绕着，我们内部之间的沟通也要注意方式和内容。

对客户的问题和求助，请用专业的态度回应，不要表现得不耐烦。如果确实无暇顾及，应与客户定一个其他时间或转交给其他同事处理。

除非与客户有特别约定，不然请勿在现场尝试或调研新技术。到这个阶段，我们的技术方案应该是成熟并经过验证的，不能给客户相反的印象。

虽然在现场沟通更直接，但重要的事项和共识一定要用电子邮件作为存档和依据，如需求变更、因客户原因造成的进度延误等。

在客户现场一定要发出同一个声音，不要在客户面前争论或挑战我们自己的同事。举例来说，在公司内部我们可能会很自然地问项目经理或需求人员，“为什么要这么做，有什么价值”，在客户现场，请不要在客户面前这样挑战自己的同事。有不同的看法，可以在午餐或下班后提出，我们务必在客户面前发出同一个声音。

请不要在客户面前谈及薪酬、福利等话题，也不要谈论我们公司其他同事的个人情况，更不要与客户八卦公司的情况。

如需要请假，应先与项目经理商量，不要直接与客户谈论请假计划。内部达成一致后，由项目经理统一与客户沟通。

大家在上海如遇到任何困难，无论是工作还是生活上的，请在第一时间与我联系，我会帮助大家协调解决。有幸与大家一起经历作为公司转型尝试的第一个项目，让我们一起把公司的第一个产品化项目打响！

2.4.3　一次访问客户现场之后的复盘

本节的内容来自一个项目团队访问客户现场之后回来做的回顾总结，涵盖了出访的各种准备活动、访问期间的工作安排等各种注意事项。每次出访之前对照一下，还是有一定借鉴意义的。

期望达成的目标一定要制订好，比如下面的目标：

• 项目需求范围；

• 项目的后勤工作；

• 项目的目标、愿景、利益相关人以及他们的细微差别、他们的角色和职责；

• 明确一些里程碑的日期，客户的指南；

• 核心工作时间，站会时间；

• 定期的报告，报销规定；

• 人员交接的计划。

进入现场以后要做以下准备：

• 工作卡；

• 计算机；

• 邮箱账号；

• 工作区域；

• 保密协议；

• 我们的计算机和邮箱的使用要符合客户现场的规定。

客户的其他安全策略，比如项目文档存放的位置，是否可使用外部的在线协作文档工具。还是有更详细的规定，比如什么样级别的内容不能存放在外部空间。因此要确认我们用的文档是什么安全级别的。

1．明确你的目的

参加一个项目快速启动沟通需求，还是为了与现场的开发、测试或者需求人员结对工作？

此外，安排一些与客户审核重要设计和需求问题的会议。除客户方正常与我们的接口人开会以外，尽可能安排与其他利益相关者的会议，收集他们更多的反馈。

在客户现场应该优先和平时与我们交流不多的人会面，比如客户方的基础设施团队以及我方在客户现场其他项目的团队人员。

不管访问客户现场最主要的目的是什么，建立信任都是一个副产品，它能帮助我们从客户那里收集到目前的分布式合作的反馈，这种反馈更真实、更坦诚。

2．后勤注意事项

当我们遴选团队成员的时候，要确保他们能够在一定的时间内出差。要注意很多人会由于家庭的原因而无法出差。我们虽然不需要保证整个团队所有的人都能出差，但是我们要确保团队中有足够的人能出差，不然，这就是一个风险。

当我们考虑整体团队轮换的时候，要提前考虑签证的因素和限制。商务签证往往会限制团队停留的时间和在客户国家所能从事的工作类型。我们也可能早早地用光一个项目一年所有的准许访问时间，这样在年底之前就不能再次访问客户了，所以轮换的时候要考虑签证的规则。

确保到达客户现场的人能工作，例如清楚去客户办公室的路线、能够方便地上网、客户现场是否有足够的工位等。

去海外出差，文化差异是很大的，我们要让每个人生活得更轻松、更舒适。

• 如何让出差的成员了解所去的城市和文化。

• 如果他们有饮食禁忌，如何帮助他们解决饮食。

• 他们的居住环境是否有厨房。

• 如果他们有了健康问题，他们如何得到照顾。

确保出差的同事有一些个人的时间。出差是一件苦差事，在一个外语的环境中工作经常有筋疲力尽的感觉。在晚上或者周末，尽量不要安排一些工作活动，除非得到大家的同意。

3．不要随意“承诺”

客户都是喜欢得到“承诺”的。

承诺的目标意味着，基于我们现在所知道的，我们确信我们可以实现某一目标。客户往往只会关注目标，而不会注意我们基于的前提条件，也就是我们承诺的假设。软件开发是一个不确定的交付过程，而不是一个标准化的生产过程。

我曾经在服务过的L项目中有过这样一个承诺：在3月10日系统正式上线的时候，物流的通道模板要准备好。这是客户一开始说的全球范围内共用一个，我们基于这个条件，给出的承诺是能够完成。但是后来，几次用户反馈之后，客户的几个大区用户不同意使用同一个模板，各区需要根据自己的情况设计适用本区域的模板，包括亚太、欧洲、北美、中南美、中东及非洲都需要设计各自不同的模板。因此我们承诺的前提发生了变化，最后与客户商讨在原计划的时间点只上线亚太区的模板。如果承诺中没有假设所有线路使用一个设计模板，后面或多或少会产生一些扯皮的事情。

理想情况下，我们可以安排额外的容量处理不确定性。需要多少额外容量取决于以下几个方面。

• 我们所涉及的工作量有多不确定，就像上面这个例子。

• 我们对环境有多么不确定，优先级是否会发生变化。

• 这个承诺对客户和用户的重要程度，它越重要，就越需要更多的额外容量作为缓冲。

我们将尽最大努力去完成我们做过的承诺，但我们不能百分之百确定。如果任何时候我们不相信可以完成某一目标，我们应尽快让利益干系人知道。

正确的承诺应该是我们将会提供的业务结果（甲），而不是我们将实现的功能（乙）。也就是说，承诺要基于对业务的影响，而不是系统的输出。

在对客户做出承诺的时候，不管我们有没有明确地提出限定条件，它们都会在那里。但是，没有限定前提条件的承诺，通常意味着前提条件不会出任何问题，永远表示在理想情况下。一旦假设条件后来出现了偏差，往往会伤害产品质量和团队的积极性，而且使计划和预测变得更加困难。

2.4.4　小结

我诚挚地建议，对于分布式团队，一定要保证本土和外包的团队定期互访。这是很好的实践，通过这一实践可以搞清楚工作互访时的职责，以及我们保障双方团队轮换互访的效果。同时，在客户现场的浸入式工作，有助于我们熟悉客户的工作语言，减少沟通中的误解。

在项目开始的时候就定义好一个交换程序，来自每一个地方的人按照约定好的计划交叉访问。

适当地“投其所好”，本质上是更为人性化、建设性的职场法则，客户也是人，自然需要大家对他的肯定。

短期访问的目的将决定接下来的计划和方向。不过，需要注意的是，除与客户维系好关系之外，我们可能只有时间和精力去完成一到两个大的其他目标。所以，不要规划太多的任务，因为过犹不及。

2.5　虚拟交流工具

我不是来唱反调的。

敏捷宣言里说人胜过流程和工具，但是并没有否认流程和工具的重要性。在过去的几年中，团队协作工具不断推陈出新，试图通过创新解决项目、团队中的沟通问题。很多团队也切实采用了一些复杂的团队协作工具，以期望减少团队协作中的浪费，提升团队协作的效率。相对于独立的团队，这些工具明显对分布式团队会产生更大的价值。

关于工具，很多行业有一条相同的定律：没有最好的工具，只有最适合的工具。工具只有经过培养使用习惯后，才称之为工具。我们要根据离岸团队的现状和客户现有的资源，确定最适合团队自身的工具和使用方式。

目前，很多来自欧美的大型外包项目仍然有很强的成本KPI。而为了达成这种成本优化目标，常规作法之一就是尽量减少项目中的差旅费用。然而事实上，尽管通过例会、工作上报等多种流程和手段，配合必要的远程沟通，貌似也一切尽在掌握，但往往总部对于外包现场的状况还是缺乏长期、动态的了解，对问题和风险也没有准确的认知。利用工具来提供这些信息，并且保证这些信息的准确性和易读性，是所有离岸团队一直在追求的目标。

一个分布式团队需要哪些工具？它们从哪些方面帮助我们？这些工具根本是为了帮助离岸团队达成什么目的？解决了离岸团队哪些天生的缺陷的问题？我们可以从以下分类中找到答案：

• 知识分享类；

• 即时沟通类；

• 工作协作类；

• 流程控制类；

• 融合即时沟通和知识分享的工具类。

2.5.1　知识分享类

在线协作方式是确保团队使用的文档是活的文档的最好方式。每个团队成员的本地文档都能与这些工具提供的云存储实时同步，通过这种方式可以保证团队唯一的知识来源。同时这也需要团队的持续维护，任何人得到的信息变更都要主动放到云盘中，而不能保存在本地或者其他地方。只有做到以上几点，文档的内容才不会过期，才会值得信赖。

很多的工具除了支持团队间的文档协作和分享，提供同时编辑的能力和编辑的历史记录，还可以在文档中添加注解，还有的可以支持在文档中使用图表功能。

使用wiki工具的好处是分布式团队可以在线编辑同一个文档，没有什么学习成本，而且wiki工具本身能够很好地管理并发编辑的问题。

文档在线协作作为知识分享的工具现在的发展如雨后春笋一般，像石墨、Google Drive、Quip等。一些任务管理工具也提供团队知识分享的功能，比如JIRA的Confluence，用户可以有机会在一个地方同时管理团队任务和团队知识。

2.5.2　即时沟通类

不同类型的交流工具，是为了适应不同类型的沟通，解决相应问题而出现的。如果我们身处一个分布式的项目，即时通信工具是必不可少的。

团队即时消息工具，如Hangouts、Skype、QQ、微信和钉钉等，能够使我们快速地去问一个问题，而且很快就能得到答案。有的即时消息工具提供了状态显示的功能，告诉我们哪些人正在计算机旁或者移动端在线。如果是一个工作用的即时消息工具，真诚地建议我们每天工作的时候让它工作起来，尤其是很有用的状态显示功能。当我们各分布式团队拥有很少的工作时间重叠时，这种工具能发挥最有效的作用。

这类工具都支持建立项目交流群，尽量在群里讨论问题，避免一对一讨论。即使需要一对一讨论，也应该及时给其他人更新信息和结论。

如果使用的是谷歌的邮件系统，使用Hangouts会非常方便。因为可以与公司内的任何人进行即时通信，而不需要添加成联系人。使用Skype建立项目的一些群组，可以很方便地把关注一个主题的范围控制在最小关注群体。不同的关注点，要建立不同的Skype群组。Skype的特点是，只有成为联系人才能进行一对一的沟通，有更高的安全性。不仅如此，Skype还能方便地提供即时视频沟通方式。

我听说有的公司会屏蔽员工使用即时消息工具，认为这种工具会分散员工的注意力，进而影响工作效率。我实在难以理解这种因噎废食的做法。对于分布式团队，它使我们失去了最有效、成本最低的沟通方式。当然，如果他们屏蔽即时消息工具，是为了鼓励员工们拿起电话的话，则另当别论了。

视频会议是分布式团队最常用的面对面的沟通方式，通常需要提前邀请对方参加，对于阐述项目的概况、讨论一个相对复杂的问题或者展示软件的功能等情况使用得比较多。如果有团队无法参加现场会议，我们甚至可以把会议的视频记录下来，发送给他们。对于一些视频，比如项目的背景介绍、技术架构等视频，甚至可以作为团队的知识长久保存下来。当有新人加入团队的时候可以节省人力去讲解。当团队外的人渴望我们项目的分享时，我们就可以直接发送给他们观看。制作一个视频片段所花费的时间要远远少于准备一个文档需要的时间，而且表达的信息也会更清楚。但是我们也需要注意，视频并不适合展示细节性的东西，对于展示综合性、概览性的介绍很有帮助。当然也有例外的情况，我们在向远程团队描述一个缺陷的时候，用录制视频的方式来展示重现的步骤，则很容易让人抓到重点，而文字则很难办到。

我们举行视频会议最常用的工具就是Skype，还有WebEx、GoMeeting和Fuze这些收费的软件工具，它们能提供更稳定的沟通效果。

据我观察，很多分布式团队在举行视频会议的时候，并不是所有人都会打开摄像头。每个人都能看到所有人的笑脸（或者不是）是非常重要的。所以条件允许，包括网速和视频会议支持的线路，鼓励每个人单独拨入视频会议，并且打开摄像头。有时候远程沟通，如果看不到对方的表情，你可能会错过一些暗示。我们的规则是，一旦工作上出现摩擦，就必须通过视频沟通解决问题。

ProcessOn的思维导图支持所有人对同一文件实时协作，项目经理可以直接邀请自己的成员参与协作，每天每项任务的进度，都可以直接标注到思维导图。协作的功能提高大家的沟通效率，同时项目进行的状态可以实时看到，也节省了大家沟通所要消耗的时间。过去我们通过其他方式来共享流程图和思维导图，现在我们也能把这两种图提升到协作的层面了。

2.5.3　工作协作类

团队中的协作不外乎结对编程、代码审核、故障重现、成果展示、项目回顾等场景。综合利用各种常见工具，分布式团队也能轻松达成这些实践目标。

让Teamviewer先出场吧，它是我接触最早的一个远程工具。它本质上提供的是远程的控制，对于不同环境问题的复现非常有意义。不过我们当时主要用来进行移动端工作成果的展示，对方可以在自己的计算机上按照展示的脚本方便地操作。

Screenhero是一款可以共享屏幕、聊天，同时支持双方输入（包括键盘和鼠标）的工具。这对于结对工作很有帮助，比如代码审核、问题重现等场景。它不单可以协作写文档，还可以协作几乎所有事情。

Teambition是一款通过共享和讨论工作中的任务、文件、分享、日程等内容，帮助团队轻松实现日常协作、项目管理等需求的在线协作工具。简单来讲，如果你想研发一款新产品、制作一个文案策划，或者是策划一次婚礼，那么，在Teambition上创建一个项目，将所有相关的团队成员添加到项目里，Teambition就可以为你提供管理任务、日程会议、文件存储、即时讨论等企业和团队所需要的多种协作功能，来实现项目知识的分享、沟通、项目任务的安排及进度监督，以及相关项目的文档存储和分享。所以这个工具对于团队计划完成一个小的里程碑会很有用。

分布式团队在举行回顾会议的时候，也不得不求助在线工具。IdeaBoardz可以友好地支持远程不同的团队的回顾会议和协同决定。它还能支持团队的不记名投票，代替回顾会议实践中的真实投票。

2.5.4　流程控制类

大家在需要团队之间协作的时候，是否遇到过下面这些情况？

• 互相之间不了解对方做的事情以及计划。

• 出于自我保护意识或者惰性的使然，团队之间形成了一些交流的壁垒。

• 一个需要双方来完成的任务，找不到对方团队的负责人。

• 一个团队完成了一个任务，很久以后另一个团队才知道这个信息。

如何打破现有工作习惯和流程，离岸团队需要善于利用各种工具，不仅仅出于交流的目的，还要能做到对项目执行的管控、对团队事务（问题）的跟踪、对需要多人协作任务的快速处理。对一个流程控制类工具来说，项目执行管理、敏捷开发管理、体系流程管理、产品缺陷跟踪、提案跟踪、需求管理、客户服务等领域都是它擅长的。

协作工具会让我们每个团队做的工作更加透明，尤其是能让需求方的同事在工具系统中看到开发任务和排期。比如，客户或者需求方提出的新增功能需求点，很长时间都没有人来执行。从系统中的任务安排上就可以看到，不是远程团队的成员在拖延，而是目前团队人员手头确实有正在处理的高优先级的任务，需要排期。通过这样的系统可以减少冲突和误解，提高沟通效率。这样，信息需求方很容易地得到自己想得到的信息，原本计划开的会也会少很多。

虽然大多数的客户是非常有主见的，但是我们不应放弃向客户推荐一个新工具、新系统的实施机会。对这一类的新东西，可以采取精益的方式，小步前进来推动，但是必须考虑客户的使用习惯。如果客户已经在使用一个类似工具，在推荐新的工具时一定要谨慎，即使新工具有很多的优势。因为推动客户改变现状往往会比较困难，在能满足功能需求的情况下，尽量与客户保持一致。如果确实需要推动新的工具，一定要列清楚带来的价值、风险有多大、学习成本几何等，让所有人一开始使用的时候就有足够的积极性。

案例

　

有一个比较传统的客户非常谨慎，异常担心新事物造成其员工日常工作变化太大而产生对立情绪。所以，当时的方案是分两个阶段实现客户流程的转换。第一阶段先把产品缺陷管理起来，让产品需求、开发和测试部门协同工作，让核心部门里的一部分同事先用起来，摆脱之前使用Word、Excel和电子邮件等跟踪方式。第一批目标用户一定是更容易接受新事物、可以作为种子的用户；第二阶段是面向整个部门，适用于部门各类项目、各类工作（包括产品、设计、开发、测试等）的任务流程管理，使其成为部门工作的备忘录、工作过程的记录。使用这种在线工具可以很容易贯彻戴明博士的PDCA理论。所有确定要做的事情，都必须有一个最终的结束的状态，避免那些领导不催不问或者忘记推进的事情不了了之。

紧接着又从梳理部门相对固定的项目协作流程入手，用当时推荐给客户使用的JIRA进行个性化的定制，包括关键节点状态、项目角色划分、项目资源分配、各环节时间点把控、上线截止时间等。用JIRA工作流按照实际业务流程规则，实现自动化的定制，最后再用JIRA强大的过滤器创建常用的分析统计报表，并生成永久链接放在JIRA导航栏上作为常用入口提供访问，立马就给大家眼前一亮的感觉。这样一来，平时管理缺陷、需求、计划时间点、资源分配情况，各环节部门之间的协作，都通过JIRA串了起来。

后来部门里的人切实感受到了JIRA给实际工作带来的好处，主动用JIRA的同事也越来越多了，经历了从我们主导推荐大家使用JIRA受到阻力，再到大家自己主动想用JIRA的过程。

随着JIRA的深入使用，大家结合自身的工作实际，也提出了越来越多的JIRA应用需求。公司其他部门看到我们支持的部门用JIRA带来的工作管理变革，也主动找我们帮忙给他们搭建、管理和培训JIRA，或者干脆直接就用其他部门的JIRA。这样每个部门的工作效率和业绩都提升了，整个公司的效率和业绩也随之提升。

2.5.5　融合即时沟通和知识分享的工具类

毫不夸张地说，在这个领域做得最好的就是Slack。这是一款基于云端的通信工具，也是聊天群组加工具集成的协作工具，旨在简化团队和组织内的协作，有助于把分布式团队捏合成一个虚拟的团队。把Slack作为日常沟通工具，它是聊天群组、大规模工具集成、文件整合和统一搜索的集合体。

Slack是一款用于企业内部沟通协作的工具，它的目的是将各种分散的信息都整合到一起：电子邮件、信息、文件等，无论是内部沟通的信息还是文件，只要上传到Slack上，都可以通过其内置的搜索工具进行检索。截至2016年年底，Slack已经整合了电子邮件、短信、Google Drive、Twitter、Trello、GitHub、Zendesk和Heroku等多种工具和服务，可以把各种碎片化的企业沟通和协作集中到一起，将它们的通知提醒、缺陷追踪等数据统统融入公司内部的信息流中。这样做的好处是，例如，绑定Google Drive后，在Slack发送一条Google Doc的链接，可以直接显示Doc的内容，并且自动更新Doc内容；绑定Trello后，可以设置某个Board的更新同步到某个Channel。Slack的主流功能还包括搜索团队内的成员、分组群聊、文档分享。它的特点是共享，让团队成员集中在一个地方分享云端的文件，包括Google Drive、GitHub等。

与此同时，Slack提供了消息搜索功能。在工作中使用的所有通知，都能通过搜索随时找到相应的内容，这让不少初创企业在协作上得到了极为方便的体验。Slack的扁平化管理模式、频道式的分类窗口、整合多方接口的特性，从一开始就注定了它要做的是“小而美”的小团队协作。

不仅如此，消息的云端历史记录以及搜索，这是对人员变动比较大的服务外包团队有重要意义的原因。普通的即时聊天工具并不支持云端存储和搜索，如果本地客户端的聊天记录丢失，则无法追溯。而随时可查询可追溯对企业的办公场景来说非常重要，这也是本章所讲的电子邮件仍然是非常重要的沟通联系方式的原因。

我们可以把Slack想象成一个IRC（即互联网中继聊天，在客户端运行，速度非常快）全天开放，就像一群聊天窗口，可以创建按主题组织的持久聊天室（Slack称之为通道）以及私人团体和直接消息，终日与你的队友讨论。可以知道有哪些小群的存在，一定程度上减少了不知道的状况发生，我们可以主动加入一个话题组。

Slack整合了大量企业团队日常使用的第三方应用服务团队，因此团队可以同步收到Slack以外应用的实时通知。

Slack里面所有的内容都是很容易搜索到的，包括文件、对话和人。你可以随意拖动文件和数据来分享给你的同事，因为Slack集成了Dropbox和谷歌云盘之类云存储服务。

我们都知道服务外包团队的人员变动是非常大的，对于新成员加入团队的知识获取，Slack也考虑得很周到。聊天记录变成团队的知识仓库，免除了从讨论一半加入还要重述一遍上下文的烦恼。相似地，对于不在线的时候团队的讨论，在上线以后也能得到完整的讨论过程。

Slack为什么会如此受欢迎？因为用户可以得到两方面的实惠。

其一是透明度的增加。你可以看到别人正在做什么，没有必要一大早开公司例会；你不再需要类似阶段性报告的文件了。它还支持跨部门合作，工程师们可以看到设计师们的工作，技术团队也可以看到客户服务是如何处理的。你所要做的仅仅是从其他频道的数据流上轻轻滑动手指。

其二是公司内所有进行着的通信表现为数字化的知识体系。在大多数系统中，知识基于电子邮件且零碎分散，就好比每个人都有自己的特点。但你将这些提供给他人时，他们在现在以及将来都会受益。所以当某人不管什么时候加入进来时，他的收件箱都不会是空的。曾做出的每个决定，进行的讨论，每次某人提起的资源、公司或组织机构，任何时候任何人分享的链接、交换的文件，所有的这些都是可以搜索到的，你要做的仅仅是回看而已。这是非常有意义的。

由于Slack会起到知识存储的作用，所以我们在对话的时候，要考虑到这个因素，减少与工作无关的对话，提问和回答使用准确的关键字。

Slack并非是一个理想的工具，能够把对话内容整理并生成所需要的下一步行动。如果你看到一条消息，叫你去做什么事情，如果你不立刻记下来，这条信息就溜走了，不会一直提醒你。所以Slack不是一个项目管理工具，而是一个沟通工具。

有了Slack，在电话会议过程中，我们就可以随时给所有人发送图片和链接，让所有人更快地取得一致的理解。这代表了社交化项目管理的趋势，这个趋势非常适合分布式团队。丰富多彩的表情符号也是必不可少的，尤其对于看不到对方时的分布式团队来说，使用表情符号可以很好地表示此时的心情，拉近彼此之间的距离。还有一个好处是，相对于使用微信沟通，我们更倾向于在Slack中使用真名进行沟通，因为用微信的时候，我们经常困惑当前的发言人到底是谁。

Slack有这么多集成方案，支持这么多市面上的工具，它能起到管理好一个团队的知识库的作用吗？尤其是，它能降低上线之后生产环境的问题对开发团队的消耗吗？能容易地把运维的工作转交给客户团队吗？

还有很多追随者厂商也提供了很多类似功能的工具，如“简聊”。有了更多的创新者加入，我们也能迎接更多更人性化的设计，这是团队协作的福音。

在充分利用社交媒体来促进协作、提升生产率和激励创新等方面，公司管理层和IT团队还有很长的路要走。

2.5.6　小结

使用工具作为交流的渠道，要解决刚开始使用时的学习曲线问题。学习工具的使用不应该花费太多的精力，使用过程中也能保证我们的精力在于解决实际问题，而不是花在工具本身上。本质上说，我们对工具的使用，最终的目的是保持分布式团队的连通性。连通性是协作的前提，使用得当，对协作有很好的促进作用。

服务外包行业的特殊性，时间很重要，凡事讲究实效，所以要求新工具学习曲线低。团队学习成长要好好地规划。

选择合适的工具对于团队的协作是很重要的，对于一些成功的工具，我们应该好好利用。这些工具的目的就是为了人与人之间、团队与团队之间更好地协作的。

目前这个领域也在高速发展中，我们对于能够产生价值的工具不能一味地排斥，随时准备接受一个有益的工具也符合敏捷精益的开放性原则。不过有时候，即使在确定一个工具能帮助我们的工作变得更好的条件下，我们也不能随心所欲地引入它。客户会出于安全政策的担忧，阻止我们的使用。有时候仅仅是对安全问题过于敏感，但更多的时候是客户不了解工具真正的安全风险。我们要着眼于帮助客户打消顾虑，而不是停止推广我们的团队所需要的工具，我们应该找到一个勇敢的主管来帮助完成必要的改变。因为有一些客户谨小慎微、做事教条，如果能找到他们的经理，他们对风险管理有更深的理解，并且愿意讨论交替控制来突破一些障碍。

远程的沟通容易产生误解，我们要始终保持积极的沟通意图。

为什么还需要物理白板

　

一开始采用Scrum敏捷实践时，我们选择了JIRA上电子化的敏捷看板，它可以根据不同团队的需要定制看板上的状态、分类、显示方式等，可以说电子看板的功能着实很强大。但一段时间下来，我们发现团队间交互的效果不甚理想，站会上大家面对着计算机自顾自地说，有人看计算机处理自己的事，有人低头玩手机，轮到自己了就对着计算机敲一通键盘。时间久了站会开得更像是一个汇报会，形式大过于内容，大家都觉得是浪费时间。

意识到这个问题后，我们及时调整了策略，虽然有了强大的电子化工具，我们还是建立了物理的看板。说也神奇，自从团队旁边竖起了一面看板，你会发现很多事情自然而然地发生了。我们每天站在白板前，一边与团队交流，一边在板上移动任务卡和自己的头像标签。有了新问题，就立刻写一张任务卡，然后把自己的头像贴上去。有了物理看板墙，大家总算真正地“面对面”了，互动和交流都变得“生动”和“开放”起来。所以我认为，物理白板的使用真的大到可以影响一个组织的文化。

工具的使用并不总是成功的，我目睹了太多次这样的失败：管理者在公司里推行某款工具，而这个工具有特定的运作方式，结果不但没能解决问题，反而妨碍了其他解决问题的努力。工具应当是有所帮助的：帮助人们防止已知的错误产生，帮助我们记忆重复性的任务，而不是取代思考本身。

开发人员可能不喜欢在开发时一直挂着即时沟通工具，因为这样会影响他们的深度思考。那怎么与远程的客户沟通呢？状态设置可以解决这个问题，非紧急的问题就不会中断开发人员的工作了。我们都听说过这个故事吧？一个工匠砸了自己的手指，却怪罪手中的锤子。

2.6　沟通失败的案例

没有沟通渠道，就要去建立沟通渠道。当一件事情需要多个部门协调的时候，一定要争取端到端的沟通，直至落地。“各扫门前雪”式的沟通，虽然感觉上自己份内的事情都做好了，但是团队或部门之间必然会出现误会，最终会造成总体的失败。

2.6.1　麦道飞机DC-10重蹈覆辙发生空难的教训

我们很多人可能没有听说过麦道飞机公司，多年前这可是与波音、空客公司并列的著名飞机制造公司。那为什么现在消失了呢？

这得从麦道公司推出的一款飞机DC-10说起，因为这款飞机在投入市场不久便暴露出货舱门设计的缺陷。DC-10最早的事故出现在美国航空96号客机上，它的货舱门出现一个大洞，该航班最终幸运地迫降成功，没有造成人员伤亡。调查员检查客机的货舱门后发现舱门的设计缺陷是导致事故发生的罪魁祸首。通常情况下，喷气客机的舱门是由外向内打开，舱门面积也要大于门框面积，随着客机升空后海拔的升高，机舱内压力会越来越大，舱门在压力差的作用下会嵌入门框。但是，麦道DC-10型客机为了扩大机舱内的载货体积，却将货舱门设计成向外开启。这就需要DC-10型客机的货舱门关闭之后，保证锁钩会扣住机身门框的门闩，最后搬运工还要压下门杆让锁针穿过锁钩固定好货舱门。

事故调查员发现事故飞机的舱门门闩并未完全扣紧，造成最后一道“保险”的锁针并未卡入正确的位置。随着客机的爬升，机舱的内外压力差逐渐增大，没有完全锁闭的货舱门会被一股强烈的力量弹开。

这次事故暴露出DC-10型客机致命的设计缺陷，负责调查的美国运输安全委员会也明确指出货舱门的问题，并通知了所有购买此类型客机的航空公司，此次事故也对麦道公司产生了巨大的负面影响。遗憾的是，此次事件以后，麦道公司并未对DC-10型客机的货舱门进行及时有效的改进。两年后的土耳其航空981号航班则没有那么幸运，在从巴黎飞往伦敦的途中发生货舱门脱离事故，机上346人无一生还。

调查员在事发地15公里外的农田里发现了飞机货舱门和相连的6张座椅，这些东西在飞机坠毁前便掉落出来。当美国运输安全委员会的调查员看到事故残骸后立刻想起了美国航空96号事故，他不解的是麦道公司并未在事故发生后对货舱门进行改进，土耳其航空981号航班似乎就是此类事故的重演。

美、法双方的事故调查员立刻对客机的货舱门展开了更为深入的调查，结果显示土耳其航空981号发生了与美国航空96号同样的事故，原因是货舱门的门闩并未锁紧，而这次并没有那么幸运，整架飞机摔成一堆碎片。

土耳其航空981号航班调查还未结束，美国运输安全委员会的调查员便返回美国，参加政府召开的特别听证会，询问在美国航空96号就发现的问题，为什么在两年后又造成另一起空难。美国运输安全委员会曾在美国航空96号航班事故发生后一个月便提出了两个明确的建议：修正锁扣装置的设计，在锁针尚未固定正确的位置时无法下压手杆；在DC-10的地板上加装排气孔，以使增压的客舱中发生爆炸性减压后不至于崩塌地板。

但是这两项建议在土耳其航空981号空难发生前都没有得到采用，根源在于美国运输安全委员会没有权力强制要求麦道公司进行改进，只能将建议告诉美国联邦航空总署，总署再以法规的方式推行下去。体制的原因导致问题的解决变成了遥不可及的事情。

美国航空96号空难之后，麦道公司的确修改了货舱门的设计，他们在货舱门的锁针位置处开了一个玻璃窗口，以便让搬运工人能够看到货舱是否锁死，此外货舱门外还加贴了警示标志（英文）。麦道公司还将锁针的长度加长，并在舱门内侧加装了金属板，如果货舱门没有锁住金属板就能阻止外部的手杆下压，工人就会知道货舱门没有锁住。但是这些改进都有局限性，有很多搬运工人根本不知道舱门处玻璃孔的作用，巴黎的货运工人更看不懂英文标志牌的具体含义，而且这架出事的客机也没有加装提示作用的金属板。

如果说美国航空96号航班事故属于意外，土耳其航空981号航班则属于彻头彻尾的人祸。调查员历尽千辛万苦研究事故的点点滴滴，为的就是避免重蹈覆辙，遗憾的是并没有人从美国航空96号航班事故中吸取教训。

深受其害的土耳其航空公司一纸诉状将麦道公司告上法庭，随后DC-10型客机的研发资料也被律师和相关人士拿来翻阅。一名记者从中有了惊人的发现，客机货舱门的供应商康菲尔的产品工程组组长曾在一份备忘录中提示货舱门会发生潜在危险，并警告货舱门早晚会引发严重的事故。这份备忘录于美国航空96号航班事故发生后写成，建议对DC-10型客机的货舱门进行重新设计，备忘录的存在更是坐实了土耳其航空981号航班空难发生的必然性。

诉讼案在开庭审理后又有了戏剧性的进展。新的证据显示麦道公司早在客机研发时期便已经知道这一危险性，美国航空96号航班事发两年前，麦道公司在进行压力测试的时候便爆开过货舱门，明显的设计缺陷却被麦道公司视而不见。虽然最终货舱门的设计得以改进，但是麦道公司却在空难发生后元气大伤，DC-10客机销量更是一落千丈，整个公司被迫于1996年画上终止符，以133亿美元的价格被波音公司收购。

让我们对整个事件进行一下复盘，测试部门发现问题以后，完成了测试报告，至此他们的工作就完成了，至于问题是否解决，何时解决是别的部门的事情。设计部门按照他们自己的想法修正了问题，并没有调研用户（搬运工）的意见，也没有培训他们使用方法。正是这样的工作作风，造成了部门之间沟通上的壁垒。我们要做到一旦发现产品出现设计缺陷就要在第一时间予以解决，任何一方的拖延和无视只能造成更为严重的后果。

2.6.2　某大型能源企业的一次集成失败

某大型能源企业客户在找到我们的时候，刚刚经历了一场惨败。他们的一个供应商承接了他们一个大型系统某一部分模块的功能，各个团队完成各自负责的模块后，集成的时候发现两部分根本不能合并起来。客户为了拯救这个项目做了很多努力，但最终这个项目也没能上线。我们进场做前期调研访谈的时候，发现很多意见集中在需求方面，因为与客户沟通不彻底，所以有很多路径上的需求盲点。

需求是后期所有工作的起点，需求上出现沟通偏差的时候，会造成后期大量的浪费工作，打击开发工程师的积极性，严重时会造成项目失败，而不得不重新开始。

针对分布式团队需求理解困难、不一致等问题，我们专门成立了一个团队，包含各个角色的成员，与客户的所有利益相关者坐到一起去深挖需求，尤其是需求背后的业务目的。最终的结果是所有人真正领会了所有的业务含义。得益于业务价值驱动的思考过程，我们在设计实现时，各个团队对自己的职责都非常明确，减少了扯皮事情的发生。在我方团队和客户团队分别开始各自的工作以后，搭建了持续集成的环境。通过频繁的集成各方的工作，随时保证每个团队都不再偏离需求共识。

2.6.3　L项目首次用户测试失败

这是一个迭代周期为两周的项目，每个月会有一个正式的版本发布到UAT环境，并协调用户上线测试。虽然在宣布用户可以进场测试之前，我们给用户做了已完成的功能展示，但用户还是提报了大量未完成功能的问题以及数据的问题，还有的用户表示这样的系统无法满足他们的要求。

用户不了解敏捷交付，误以为所有的功能都已经开发好了，像以前一样。用户以自己的真实业务目标为导向进行测试，而我们第一次发布的功能做不到端到端。功能展示是告诉用户可以做什么，而用户并不明确不能做什么，哪些暂时是不满足测试条件的。对于不满足测试条件的，我们应该告知用户什么时候能准备好。从上线用户使用、测试的角度看，要考虑好如何安排用户故事卡②的开发顺序，也要考虑功能的优先级。

②用户故事卡同故事卡。

2.6.4　小结

沟通没有达到目的会引起很多无法预知的结果，就像上面的三个案例一样。沟通没有达到目的的原因，也会是五花八门的。因此，提升分布式团队的沟通水平是一个系统工程，需要一个全方位的计划。

进一步说，离岸团队不需要妄自菲薄，要勇敢地站出来沟通，哪怕是领导客户的团队，以完成整体的目标。这些“额外”的工作是不会白做的，所有人都会看得到。往近了说，客户会容易给我们增加预算，给我们更加核心的任务；往远了说，为双方以后的合作增加了重要的砝码。