变中求生——频繁变化的团队如何打造团队文化

变中求生——频繁变化的团队如何打造团队文化

范文博 师洁

作者介绍:范文博,ThoughtWorks高级咨询师、软件开发工程师、交付中心技术负责人。9年从业经验中,曾就职于恒生电子股份有限公司,也曾加入创业项目,参与过金融服务、金融创新、电子商务、房地产数字广告等行业的软件开发,且在分布式敏捷团队建设方面持续进行着学习和探索。

师洁,ThoughtWorks高级咨询师,现为交付中心经理,从业8年,曾担任过QA,交付组组长、测试组组长等角色。参与过电子商务风控系统、搜索引擎、电信企业、房地产数字广告等行业的软件开发。在分布式敏捷团队管理方面持续探索和实践。

引言

ThoughtWorks是一家敏捷软件咨询和专业软件交付公司,西安办公室的交付团队规模基本上是10人左右的小团队,每一个交付项目的生命周期一般不会超过半年。

随着公司业务规模的不断扩大(从2014年3月,西安办公室从125人增长到现在230多人)、新项目快速启动人员持续增长,每个团队中经验较足的同事会从当前团队转出(Roll off),去重新组建并带领新的交付团队,所以每个项目组人员变化都非常快。

这些交付团队本身规模就不大,随着人员的快速流动,就出现了各种各样的问题。例如团队平均技术能力下降、敏捷实践的理解和执行出现偏差、代码质量追求不再精益求精、交付项目问题及风险层出不穷……

案例分析

在2014年中时,我们团队规模为10人,并行2个项目组,项目中使用的技术主要是Java和前端技术,以Scrum为敏捷方法,作为整个办公室一直平凡的交付小团队,一切似乎都风平浪静。

可是在后续的一年时间里,伴随着公司业务的快速发展,项目中6名经验最丰富的同事离开了团队,新补充进来的12人中有6人是应届毕业生,最终形成19人团队。与此同时,开发技术也从Java切换到Ruby、NodeJS等,迫于进度压力,项目骨干会不自觉地将精力放在交付上,对于新人的培养、团队能力建设等事情就总排不上优先级;而新人(尤其是应届毕业生),自主学习的意识和能力还没有养成,虽然有结对编程等实践帮助,进步依然缓慢。

同时也出现了因为平均英语水平大幅下降而导致的与客户沟通问题,比如英文会议中的团队关注平均时间也就是5~10分钟,只有少数人能继续参与会议讨论等。团队的新领导者其实本身也并没有什么团队管理经验,所有的团队事务都是由领导者发起、组织、主持,更像是团队的“保姆”,很少有精力能够投入到一些真正改善团队的活动中。同时,交付的项目也出现了各种问题,比如速度跟不上、bug增多、需求理解偏差导致返工等。

我们针对这些问题进行了一次长时间的根因分析,结果发现,上述问题的根本原因,大多是团队建设方面的问题。有20%左右的问题是一些无法轻易改变的固定事实,而占据所有问题80%以上的根本原因,都是团队问题。其中最主要的几个问题可以总结为:

  • 团队内部沟通较少、反馈不足;

  • 团队没有内部激励手段;

  • 个人责任感弱、主动性差、对他人的关注不足;

  • 团队凝聚力不强、内部信任不好、环境不安全;

  • 和客户的关系还不是团队合作关系。

我们最初的目的非常单纯,只是希望能解决这些问题,让团队再次成为一个健康、相互信任和支持、能够正常工作的自组织团队。基于这样单纯的目的,我们在团队中持续推行且不断尝试新的团队建设的相关实践。

实践一:回顾

沟通,加强团队的自我认知。

回顾(retrospective)是每一个团队都应该定期开展的活动,本意是通过各种沟通形式唤起大家对团队的集体意识,指出团队或个人在一段时间内的不足并列出相应的行动。

但是很多时候我们都将回顾流于形式,只是走个过场,甚至因为时间紧迫而忽略回顾,这殊为不智。持续而有效的回顾和反馈,可以保证团队关心生产力和效率,了解团队自身的不足和问题,这将成为团队持续改进的起点。

回顾的形式和方法非常多,耳熟能详的就有“Well & Less Well”“红绿灯检查”、“心情曲线”等。回顾的关注点也多种多样,除了“项目开发”之外,还可以关注“敏捷成熟度”“团队角色和职责”“人员技能提升”等。

在坚持回顾的同时,还需要做的是保证回顾的有效性;并且要根据团队建设目标的发展变化,不断调整回顾的关注点和形式,确保回顾能够有针对性地发现团队的缺陷并转化为其他实践。当然,长期有效的回顾和正确的回顾产出,也能够不断提升团队内部的安全感和信任度。

实践二:团队反馈

沟通,构建团队信任,持续改进。

这是一种和回顾较为类似的沟通实践。但是回顾的出发点是团队,往往会回避针对具体个人的问题,否则容易影响回顾的安全度。而团队反馈(team feedback)实践是尽量创造出安全的反馈环境,以一种让人舒服的方式提出和收集针对个人的反馈。

反馈实践也是定期进行的。实施时,每人都需要向其他所有人通过写卡片提出反馈,收集反馈后选择其中的一两条展示出来,并给出一些针对性措施。

提出反馈一共进行两轮,第一轮只提正面反馈,通过鼓励和承认营造安全感;第二轮只提负面反馈,通过卡片来加强隐私性。当然最后也需要确保改进措施能够落在实处。

除了通过写卡片的方法,我们也尝试了类似相亲会的“8分钟反馈(feedback)”活动:两两结对,8分钟面对面给出意见并接受反馈。每8分钟后换人,直至每个人都和其他所有人结对过。事实证明,若是能将各种实践赋予趣味性,那么效果便会事半功倍。

实践的结果非常喜人,通过多次迭代式地进行小组反馈,每个人不仅在反馈中提及的能力有了明显的进步,而且主动收集反馈的意愿和接受反馈的能力都有显著的提高。

实践三:鼓励豆

内部激励,关注团队个人。

这本来是一种通过外部激励来加强团队主动性的实践。每人每周都有50个虚拟的豆子,可以以任何理由,送任何数量的豆子给团队的其他成员(如图5-1所示)。

图像说明文字

图5-1 优秀豆子

例如:“我给清波15个,他帮我的Pair萌萌解决了一个Isolated Scope属性继承的问题”。每周我们都会对豆子进行统计并公示,而当月的冠军们也能够获得来自项目组的咖啡等礼品。

然而在实践的过程中我们却发现,或许是外部激励来得不够猛烈,根本没人在乎这些激励。大家在意的其实是“来自于他人的关注和认可”这样的内部激励。

因为鼓励豆(merit beans)会隐性地要求团队里的每一个人关注其他人,所以同理,每一个人也在被其他所有人所关注和认可。

举个例子,Larry是我们项目组的一名加拿大籍员工,虽然会说中文,且工作非常努力,但是他总担心和大家会有隔阂,担心自己不被团队认可。 在做“鼓励豆”实践的时候,他收到了非常多的豆子,他发现他做的每一件事都被其他人记住并且认可了,这令他非常感动和鼓舞。

于是我们发现,这个实践真正工作的并不是外部激励,而是内在激励,它会对团队内部的集体意识和相互信任产生极大的促进,尤其是对新加入的成员。

实践四:激励图谱

了解团队成员所关注的激励方式,形成团队激励图谱。

通过多轮排除法,让每个人在“成就感”“被尊重”“好奇心”“自主性”“交际”“经济驱动”“自由”“领导他人”“被赞扬”“能力成长”“成为专家”“目标性”等驱动力中选出最能激励自己的三项以及最不能激励自己的一项并排序,从而得出个人及团队的激励图谱。

参考激励图谱(如图5-2所示),通过集体努力,尽量有计划地为组员提供合适的工作机会和挑战,从而加深成员对团队的认同,同时也能培养个人的相关能力。

图像说明文字

图5-2 激励图谱

实践五:蛋糕

肯定及激励团队。

给团队买蛋糕庆祝。任何团队和个人的成就都值得鼓励,团队能力进步、项目里程碑达成、个人做出突出贡献,全都通过一起吃蛋糕的形式进行庆祝。

这不仅是通过蛋糕内部鼓励一下团队,也是通过“来一起吃蛋糕吧”的邀请,告诉其他项目组,“我们多厉害”,帮助团队在大环境下取得集体荣誉感。

每次的庆祝蛋糕,组员们都会邀请其他项目组的同事朋友们一起分享,分享的除了蛋糕,还有整个团队的成功故事。“你们才几天业务就破万了,好厉害”“菁姐你ES这么牛,来帮我们解决个难题吧”这样的赞叹才是对团队成功的最大鼓励。

实践六:知识分享和学习—自主学习和成长

为了提高同事们对知识的理解以及自主学习意识,加深团队知识储备的深度和广度,我们在周期性地组织知识分享活动之外,也鼓励自发的知识分享。知识单元可能小到“运行bundle install时会发生什么”,也可能大到“微服务开发最佳实践”,甚至会涉及“量子力学初探”。学习的形式也多种多样,演讲、工坊练习、读书会、英语泛听活动……

不强制制订学习的范围,是为了维护主动分享的乐趣和自发性。如果只限定在工作范围内,知识分享在新人眼里往往会看作一种考核,从而丧失主动性。

长期坚持实践执行的结果就是,在没有做任何强制要求的情况下,每个人也都乐于主动分享自己的知识,各种学习活动会如期展开并经常创新,学习效果也能从多元化的学习方式中得到保障。

实践七:团队创新大赛

兴趣与成长相结合,主动完成技术提升。

Hackday(中文称为极客马拉松、骇客马拉松、极客日等)是一种特殊的编程活动,我们项目上也会采用这种方式,定期投入一些时间来完成一些和工作无关或弱相关的创新工作。这项实践在ThoughtWorks和一些极具创新基因和文化的客户项目中,会每三个月就开展一次。

每个人都可以展示自己的创意,自由组队,一起在接下来的3天里全力以赴,开发出可以进行展示的原型。此项活动旨在鼓励创新,增进团队尤其是不同角色之间的协作,提升团队活力。这项活动在帮助提升设计、编程等方面技能的同时,也给平静的工作生活带来一些新意,如果能够借此孵化出一些新的项目和产品那自然是更好。

在公司级别的为期3天的Hackday中,我们的感受可以用这些关键词来描述:脑洞大开、积极学习、热情合作、全力参与等。但遗憾的是,也有很多有新意的好玩创意因为时间和人力不足的关系没法实现。大家都希望公司能更多地举行类似的活动,但是由于成本问题无法实现。

那么为什么不能由项目组发起,利用非工作时间来开展活动呢?

项目组内部的第一个Hackday项目就是“啤酒自动化酿造”。这是一个结合了硬件(包括开源硬件)、嵌入式开发、云、消息推送、Web开发、工作中使用到的工具等技术完成的啤酒酿造半流水线。至今已酿可饮用啤酒十数批,也大大提高了团队的硬件知识、编程兴趣、编程技能、对工作相关工具的熟悉程度。

兴趣与成长相结合,不仅做得开心,也能在技术、热情、合作、信任、沟通等方面得到巨大的提升,何乐而不为呢?

实践八:直接责任人

培养责任心和团队意识。

在日常工作中有非常多的团队事务,组织站会、组织回顾、代码审核……如果所有的事情都让同一个人来负责,会让他觉得工作非常杂乱,严重影响他的工作进度。

我们期待的理想状况,是项目组中的每个成员都能主动承担起一部分团队事务,积极地维持团队工作。

如图5-3所示,DRI(direct responsibility individual,直接责任人),根据团队中常规重要职责和任务虚拟出不同角色,团队成员定期轮转承担。将责任感和日常工作的融合,每个人都会在日常事务中培养起主人翁意识。同时此实践能大大降低团队日常运行对团队组长的依赖,帮助形成自组织团队。

图像说明文字

图5-3 DRI

实践九:事故后回顾—责任及文化

项目中总会出现问题,尤其是较为严重的线上问题。在发生“文博手滑清空了生产数据库”这个严重问题后,除了恢复数据库修复问题本身之外,如何在保护当事人的同时归纳总结经验教训,则是另一件重要的事情。

事故后回顾(post incident reviews)就是在问题修复后,针对严重事故的一种特殊回顾。在回顾会上,会从团队集体的角度出发,列出事故发生过程中重要事件的时间点来帮助回忆。同时需要理清受到事故影响的用户和业务,并分析严重性,再以根因分析法不断演进事故发生的各种原因。最后要总结应对措施,确保不会再次发生同样的问题。面对困境时,团队才是承担责任的最佳角色。我们坚信,所有的问题都不会是单独某个人的问题,我们需要从团队整体角度进行分析,提升系统的工作机制(system of work)。所以在分析和总结时,我们的原则是不指责(no pointing finger)。

通过PIR,不仅可以通过集体责任来保护当事人,加强内部信任,还可以通过集体危机意识加强个人和团队的责任心,也能减少再次发生类似问题的可能。

实践十:分布式团队建设

完善团队合作关系。

我们绝不希望也不能将交付项目做成外包项目,把客户合作做成甲乙方关系。在交付项目中,除了优秀的团队能力、平等的工作合作、稳定的交付能力等要求之外,良好的客户关系也是确保项目成功的一项重要指标。

常规的项目相关实践都是能够和其他远程的工作伙伴一起进行的,并不受到地域距离的限制。但团队建设(team building),尤其是吃吃喝喝之外的一些增进团队合作的游戏、工作坊之类很难一起进行。很难想象当一群西安的小伙伴自驾去山里烧烤时,能让远在千里之外的国外团队也感受到同样的乐趣,所以如何组织能够远程分享乐趣的团队活动就成为了一个重要问题。

最终我们将目光集中在“通过视频会议一起玩各种以沟通和交流为主的有趣游戏”上。例如加深敏捷实践的乐高游戏,颠倒工作中的角色,PO来做DEV、QA扮演UX,进行一次基于乐高的敏捷工程开发;还比如提高语言技巧的故事游戏,双方利用手边的素材轮流发言,共同完成一个传奇般的故事。任何有趣并且能加强沟通的游戏都可以作为远程团队建设的手段。

远程团队建设弥补了分布式团队建设生命周期中缺少的一环,在分享快乐的同时,加深了分布式团队之间的认知和人际关系。

团队文化总结

团队文化是指团队成员在相互合作的过程中,为实现各自的目标及价值,为完成团队共同目标而形成的一种潜意识文化。

团队文化可以包含价值观、最高目标、行为准则、管理制度、道德风尚等内容。它以全体员工为工作对象,以最大限度地统一成员价值观,凝聚力量,为团队总目标服务。

通过持续不断的实践,的确能够有效地进行团队建设。但是随着团队能力、自我管理改善达到一定程度时,会发现团队越来越难管理(不同意见太多、决定难做、众口难调、只有讨论没有行动等)。

对于团队来说,文化就像一束光,是团队走出混沌,走向自组织的向导。这束光是团队自己定义的。

我们这个团队,在经历了这些问题、困惑、改进、感悟后,一起组织了一次团队文化的“workshop”。这个“workshop”的目的是让大家回顾并对比过去,感受团队的发展变化,定义在这个团队中,有哪些共同的特质或者感受是大家所珍视的、能帮助团队朝大家所期望的方向发展的、希望以后能在团队中继续发扬光大的。

在一次两岸分布式团队大部分人齐聚一地的时候,大家在一面贴满了回忆照片的墙面前坐下来,分享并回顾在这个团队中所深受感动的人和事,并给每件事贴上自己感受较深的关键词,如家、敬业、笑声等。

当把所有关键词分类并精炼概括后,就可以找到团队的“文化”。最后,大家集思广益,用喜欢的形式和方法,将这些文化、故事表现出来,加上注解,就形成了自己的“Culture Book”。这一点上,我们借鉴了Zappos公司。在制作“Culture Book”之前,我们并不清楚能否做成,最开始也只是想找到团队自己的文化定义,并没有预期到,最终会有这么一本“Culture Book”诞生。

这样的一件事情,会给团队带来什么样的正面影响?在交付压力巨大的情况下,团队成员是否愿意花时间做这样的事情?所以这件事,也是跟其他实践一样,先有个想法,找几个人聊一聊,听听大家意见,然后任务分解,小步快跑,看看团队成员反映,然后进行下一步。

在最开始的过程中,确实有成员不愿意参加,想着要赶紧去写代码赶交付,但是在试了第一个阶段:看照片分享回忆之后,根本停不下来!甚至在既定时间内,没有完成“Culture Book”的制作时,大家纷纷主动领硬卡纸,在下班后,三三两两聚在一起花了很多时间去构思怎么才能把它做得更完美。

实践证明,在小团队中,要推行什么实践,要做什么事情,从一开始就做一个完美、缜密的计划然后按部就班去实行,是不可取的。在自组织的小团队中,只需要告诉大家,想法是什么、为什么要做、能解决什么问题或者能带来什么价值,然后怎么做、什么时候做、产出是什么,所有的这些,团队会找出最合适的答案。

以下便是这个团队的文化定义:

  • 合作;

  • 尊重;

  • 快乐;

  • 家庭;

  • 优秀。

每个团队都有自己的性格,有自己的文化。这些文化,是在平常一点一滴积累而来,并不会有人说我们要什么样的文化,便会有什么样的文化。文化是一种沉淀和积累,只有整个团队一起共同努力、共同经历后,才会形成团队自己的味道,自己的文化。

团队建设宣言

我们一直在实践中探寻更好的团队建设方法,身体力行的同时也帮助他人。由此建立了如下团队建设宣言:

内在激励    高于    外部激励

我要做    高于    要我做

自我驱动的团队    高于    经验丰富的领导

个人能力    高于    职责要求

团队关系    高于    工作合作

也就是说,尽管右侧项有其作用,但我们更重视左侧项的价值。

目录

相关技术