BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

一起工作,分开就座

| 作者 Hugo Messer 关注 1 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2014年10月23日. 估计阅读时间: 21 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

要想判断你的离岸外包冒险之旅是否成功,有两个最根本因素:人和过程。有人会说:过程是最重要的;另外有些人将人放在第一位。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 的框架。

结论

要想为远程协作奠定坚实基础,在真正“开工”之前,必须留出“思考时间”。项目启动之前,想想你每天的工作方式,以及如何调整这些工作方式,才能与离岸团队一起工作(流程)。你可以思考如下话题:

  • 我们遵循哪些步骤?
  • 我们如何达成估算?
  • 我们如何列出需求?
  • 我们如何规划?
  • 谁来测试什么?

你可以跟离岸和在岸团队成员一起讨论。会议中或者会议后,要把流程记录在纸面上。描述每个参与者的职责,说清每个细节。最后,要形成一个稳定的框架,可以为每个人、团队、公司提供反馈,互相评价。

现在,你也许在想:“太棒了!我们已经搞定了这些东西,讨论了很久,也都写下来了,最后就把它们放在(虚拟的)抽屉里。没人会再去看它们,我们还是会马上动手干活。”没错,也许你会这么做,因为这是自然而然的趋势。

然而,动脑子的团队就会想:“如何在真正开始开发之间展开协作”。这会建立起人们之间的联系,而且可以创建更有效的工作方式。现在,你要负责不让这些文档躺在抽屉里,在你的定期会议中使用它们,随进度更新它们,让它们成为有生命的计划和实践!

关于作者

Hugo Messer从2005年开始,就在世界各地建立和管理团队。推动位于不同文化、地域、时区的人们一起协作,是他的激情所在。无论是离岸还是近岸,他知道如何达成全球化的协作。如果希望更多了解 Hugo,请访问他的网站,也可以阅读他的博客,或是观看 Youtube 上有关他的视频。

查看英文原文:Working together, sitting apart.

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT