在日常的交付工作中，即便大家都更希望在一个氛围轻松、效率高、有成长空间的团队中工作，但实际上不管人数多少、合作的对象是谁，都多多少少会遇到一些问题。建立一支高度团结一致的团队非常难，但其实过程并不复杂，关键是要使事情化繁为简。
文章源自玩技e族-https://www.playezu.com/206118.html
本文从“团队协作的五大障碍”出发，首先对团队协作过程中遇到的各种问题进行抽象归类，然后分享我们试过且效果很好的一些敏捷实践。每个团队情况不同，所列方法不一定适用所有人，不喜轻喷，欢迎来一起讨论分享。文章源自玩技e族-https://www.playezu.com/206118.html
本文会从以下几个方面来展开叙述：文章源自玩技e族-https://www.playezu.com/206118.html
- 团队挑战
- 团队协作的五大障碍
- 针对每一大障碍的具体陈述和对应实践
- 团队文化产出
- 团队建设结果
团队挑战
“家家有本难念的经”，每个团队都有一些内部问题，不论优先级和复杂性，理想情况下我们希望都能够得到解决，首先列出我们遇到的一些主要挑战：文章源自玩技e族-https://www.playezu.com/206118.html
- 技术栈复杂且陡峭。我们组主要技术栈是 Scala FP和TS FP，需要对AWS有一定了解，且也需要一些Ruby，React技能，而Scala FP是出了名的“学习路径陡峭”；
- 业务复杂且非常重要。我们项目的业务会涉及到合同中每一项条款的收费逻辑，所以很多细节和场景都要考虑周到，稍有不慎就会实实在在造成较大的经济损失；
- 项目有严格的交付期限。由于业务的特殊性，很多新功能如果不能及时正常上线，可能会影响用户体验并流失客源；
- 客户人员变动较频繁。在一段时间里，我们所对接的客户角色几乎全部换了一遍，甚至有一段时间客户方零开发，没有人能够与我们对接技术，而对于我们这种纯开发团队来说，除了正常的完成交付外，还需要能够随时填补缺失的能力，比如分析需求、参与项目启动阶段的讨论、进行整个项目进度规划等；
- 团队人数较多，且人员变动大。随时进行相关的人员的调动，且快速帮助新人适应新环境，这本身不是一个复杂问题，但考虑到上面所列的技术栈陡峭、业务复杂、客户人员变动频繁等挑战，这个问题也变得相对棘手；
这些问题，每一个单独拿出来都没有一蹴而就的解决办法，团队管理本身就是一个日积月累的过程，有时候会发现我们把很多细节都做好以后，大部分的问题就迎刃而解了。所以接下来会介绍一些团队协作的障碍，以及对应的实践，这些实践做好并不保证就能解决以上问题，但可以使团队进入高效能状态，与应对这些挑战，并“大事化小，小事化了”。文章源自玩技e族-https://www.playezu.com/206118.html
团队协作的五大障碍
这里借用Patrick Lencioni提出的模型 ——团队协作的五大障碍，对我们日常工作中的问题进行归纳分类。感兴趣的可以阅读原著进行了解，这里只做简单介绍，以便后续内容的展开。文章源自玩技e族-https://www.playezu.com/206118.html
文章源自玩技e族-https://www.playezu.com/206118.html
五大障碍不是各自独立的，他们会共同形成一个模式，使得其中的每一项都有可能成为团队合作的致命杀手。文章源自玩技e族-https://www.playezu.com/206118.html
- 第一大障碍是“缺乏信任”。这个问题源于团队成员可能害怕成为别人攻击的对象，因此不愿相互敞开心扉、承认弱项和缺点，从而导致无法建立相互之间的信任；
- “缺乏信任”会直接导致第二大障碍“惧怕冲突”。由于缺乏信任，团队成员无法产生直接而激烈的思想碰撞，而只有无关痛痒的讨论和意见；
- “惧怕冲突”会进一步导致第三大障碍“欠缺投入”。团队成员之间因为惧怕冲突，就不能在问题的讨论中充分、公开地表达自己的观点，因此即使在会议中“彷佛”上达成一致，但其实并没有真正统一意见，做出团队决策；
- 团队没有真正达成一致，就会导致第四大障碍“逃避责任”。由于没有在计划或者行动上真正达成一致，所以事后出现问题时，有可能会发生“甩锅”现象；
- 第五大障碍“无视结果”是在前面四种障碍的基础上产生的。如果大家互相之间缺乏信任，成员之间不能相互负责、坦诚相待，那么就可能会出现把个人的需要放在整个团队共同利益之上的现象，即“无视结果”；
第一大障碍：缺乏信任？
“信任” 是个经常听到的词汇，但在团队合作里的信任，指的是相信同事的言行是出于好意，因此不用太过于小心或者相互戒备，这需要团队成员敢于承认自己的弱项，并放心接受彼此的批评。但事实上，要在暴露弱点的基础上建立信任是非常不容易的，因为我们从小到大在相互竞争的环境中长大，大多数人已经习惯了要展示自己优秀的一面，要为了团队的利益放弃这几乎本能的东西，着实不易。文章源自玩技e族-https://www.playezu.com/206118.html
没有建立信任，危害是巨大的。团队会需要消耗额外的许多时间和精力在管理个人行为和促进相互沟通上，造成团队氛围不好，效率低下且重复劳动很多。文章源自玩技e族-https://www.playezu.com/206118.html
那么我们是如何解决的呢？
(1) Welcome 新人/ Farewell 老人
对于每个团队成员的每一个项目经历来说，都有怀着忐忑不安上项目的时刻，也有怀着或成就或不舍下项目的时刻。为了让大家感受到团队的温暖和关心，我们会有相应的 Welcome Meeting 和 Farewell Meeting，通常还会有一个 Welcome Cake 和 Farewell Cake，所有人聚在一起，进行自我介绍表示欢迎或者赠送Farewell礼物并附上每个人想说的话，通过这种小小的仪式感，帮助新人消除刚上项目的紧张感，也让老人感受到团队是感谢Ta的。[30min]
(2) Life Journey
通常发生在新人加入项目一到两个月的时间后，这时新人与大家进入相对融入的状态，所谓“Life Journey”理论上是介绍“我自己”，目的是让大家“对我的过去有更多的了解”，没有准确的时间段也没有明确的形式，可以做PPT讲解自己从小到大发生的重大事件，可以现场手绘时间线讲解自己的恋爱史，也可以直接聊聊自己的兴趣爱好等，其他人可以进行提问，场面十分热烈，通过这种方式，迅速加深对彼此的了解，找到更多的共同语言。[30min]
(3) Team Building
团建很重要，但一定要尽量保证所有团队成员都能参与，形式可以多样，不要仅限于吃饭，比如一起烧烤、爬山、轰趴、泡澡等，通过与团队成员更多地经历“工作外”的事情，增进彼此的了解，甚至形成默契。[N/A]
(4) 与远程客户：Teatime
这个实践最好是由客户提出的，我们团队是两周一次，交付紧张的时候会取消，通常发生在周五下班前的半个小时，内容形式都不限，可以是一起做游戏，也可以是组织者分享某一个故事，由于客户一般是国外的，所以对团队来说也是个练习英语的好时机。[30min]
(5) 与远程客户：Fun Channel
每个团队都会与客户有一个工作群，通常我们会在里面发各种交付进度、需求确认、人员安排等工作相关的内容，但我们也会与客户有另一个Fun Channel群，这个群里不聊工作，只与Fun有关，比如两边团建的照片、客户家宠物的搞笑片段、周末去了什么好玩的地方、发生了什么有趣的事情等等，通过这种方式，拉近与客户的距离，建立更多信任。[N/A]
(6) 与远程客户：Virtual Background
这个实践也最好是由客户提出的，我们组通常一周一次，会在周五的远程站会前根据前一天选定的主题换上对应的 Virtual Background，然后在站会开始时大家先彼此介绍一下自己背景的含义，主题不限可以是很多有意思的话题，比如你童年的照片、你最不喜欢的食物、如果不考虑各种限制你最希望有一项什么超能力等等。目的是促进团队成员之间的了解，减小客户远程办公带来的距离感。[10min]
(7) 与远程客户，且作为Leader：Regular Catchup
作为Leader，最好跟客户的主要负责人有一周一次的 Regular Catchup，通常可以聊聊项目进度、工作安排、团队情况、交换一下反馈之类的，如果实在没有话题也可以很快的结束，顺便跟客户闲聊一下团队生活等等，也是一个慢慢建立信任的过程。[30min]
(8) 与团队成员，作为Leader：Regular Catchup
作为Leader，既要对团队负责，也要对团队成员的成长负责，所以需要清楚地知道每个个的兴趣点在哪里、Ta的发展方向是什么、Ta希望得到什么样的帮助等等，这些都可以通过与每个人的Regular Catchup解决，至于频率和方式可以根据自己团队的情况决定。[N/A]
所谓“磨刀不误砍柴工”，在我看来，建立信任的过程就是这个“磨刀”的过程，可能有的人看完会觉得花里胡哨的净搞些不好好交付的事情，所以我在上面每个实践的最后标记了花费的时间，且大部分都不一定是定期发生的，只有在特定场景才需要，团队也可以根据交付的进度和紧张程度进行裁剪，这些“仪式感”看似是在浪费时间，实则极其重要，团队成员之间的信任建立好后，氛围才能“严肃活泼”，做起事情来才能事半功倍，我只能说，真香！
第二大障碍：惧怕冲突？
首先我们应该有一个共识，那就是承认“冲突”是有益的，但这里我们要区分积极的争论和消极的争吵或矛盾，积极的争论仅限于观点不同，对事不对人，不存在人身攻击，但依旧有可能会非常激烈，在表面上和消极的争吵或矛盾很类似。但进行积极争论的团队，是可以在最短的时间内找到最好的解决方案的，他们往往能够快速地推进问题的讨论，并在讨论结束后，不会抱有残留的不满情绪。
惧怕冲突的团队，表面一团和气，但实际上经常反复遇到同样的问题，反复讨论，依旧无法解决，会议低效枯燥，且把很多时间和精力浪费在表面形式上。
那么我们是如何解决的呢？
(1) Pair Metrics
这个实践只能发生在本身就有Pair机制的团队，Pair的好处和必要性我们这里暂且不论，但我们团队是Pair Work的，假设存在小A和小B因为某些神秘的原因不喜欢一起讨论问题或者一起工作，那么我们可以通过一些机制让大家都机会均等的Pair，因为Pair本身其实是一个很深度的合作，通过我的观察发现，即使非常不熟悉的两个人，Pair几个来回之后也会变得成“好兄弟”。可以根据团队技术和业务的复杂性设定一个固定交换Pair的时间，比如我们是一个迭代(两周)，每个迭代结束后，不管当前的故事卡有没有做完，都会根据Pair Metrics的数据进行调换，调换的原则是尽量保证所有人Pair的次数是均衡的，而没做完的故事卡可以让其中一个人带到下一轮Pair中。通过这种方式，加速团队内部业务知识和技术的交流融合，方便后续的进一步沟通交流，表面上看是减少“冲突”发生的可能性，实质上却能有效促进积极的争论。
(2) Speedback
Feedback文化在我司可谓是深入人心，而Speedback其实是一种轻量级的Feedback方式，因为我发现虽然我们有Feedback文化存在，但实质上只有遇到比较正式或者产生影响的事情时，才会有人提出说，“我有一些Feedback想跟你聊聊”，更何况对于新人小伙伴，主动提出Feedback这件事就需要一定的勇气。所以我本身比较喜欢Speedback这种方式，具体形式：会有一个组织者，采用随机两两组合的方式，每个人有四分钟的时间给对方提供简短的Feedback，时间到则二人交换，在八分钟后，则所有人打乱交换，直到每两个人之间都聊过。这里不推荐强行搞Speedback，通常可以在有新人加入、项目进入总结阶段、或者觉得最近团队氛围有些微妙大家需要聊聊天等场景。
(3) Retro
Retro也是我司的一种老文化了，所以就不做过多的介绍了，但这里想强调一下和客户一起Retro的场景，除非特殊情况，否则应该在客户面前直面问题，问题发生，客户是能感知到的，没有必要躲躲藏藏，我所在的团队在Retro上会主动把问题抛出来，并且和客户一起讨论商量解决方案，非常不推荐跟客户Retro一遍，然后自己内部又Retro的行为，把问题摆在桌面上大家一起讨论，一方面能够促进问题更好地快速解决，另一方面客户也能感受到我们的专业性。
惧怕冲突最常见的表现是会议参与度不高，或者团队成员会觉得会议很无聊。为什么开会无聊？可以类比一下，大部分人都喜欢看电影吧，为什么不会觉得看电影无聊？因为电影中存在冲突！这个冲突可能是亲情、友情、爱情、立场、政治等，甚至是多种因素交杂在一起，因为有冲突，所以引人入胜，观众想知道到底会怎么样了。同理开会也是，开会的目的大部分是解决某个问题，团队成员每个人的想法不可能完全一致，如果每个人都能积极地参与其中，碰撞出冲突，进行思想的深度交流，会议是不可能无聊的。
第三大障碍：欠缺投入？
团队成员如果不能切实投入，在热烈、公开的辩论中表达自己的意见，即使似乎在会议上达成了一致，也很少能真正统一意见，作出决策。在很多情况下，团队拥有足够的信息，但这些信息分别存在于各个成员的意识中，所以需要展开自由充分的讨论才能把这些信息汇集起来，而只有每个人都把自己的意见完全表达，大家才能对作出的决定有足够的信心，因为这是集体智慧的结晶。优秀的团队可以在很短的时间内达成明确的共识，大家都同意按照最终决定进行工作，即使先前反对这项决定的人也是如此。
如果团队总是因为欠缺投入而无法达成一致，最坏的情况是内部长期存在深层次的无法解决的矛盾。
那么我们是如何解决的呢？
(1) Awesome Sharing
欠缺投入的主要原因是团队成员没有完全积极地参与到会议等团队事务中，所以我们要做的是为大家营造一个安全的讨论环境，让大家养成自由讨论、积极参与的习惯，我所在团队会每周搞一次“Awsome Sharing”，也就是轮流进行分享，这个分享不限主题和形式，可以是最近正在学习的一项技术、刚掌握的一门技能、科普类的知识、甚至是一篇博客等都可以，为了不影响大家交付，这个Session不需要过于正式，也不用准备的很充分，其目的只是为了Share给其他人，发起一个Topic，让所有人一起加入讨论，互相学习，如果每个人都能积极的加入进去，慢慢的团队会越来越有技术氛围，且每个人都养成了积极提问、主动加入讨论的习惯。
下图所示是近期我们组内做过的一些主题，其中有些是游戏，主要发生在疫情WFH期间，有些是科普类的，大部分还是和技术相关的一些讨论：
- 海龟汤
- 吉他弹唱
- 你画我猜
- Swartz and Modern Intern
- 哈耶克
- 鉴权之路
- Oauth2
- MD5用法和解析
- Scala Monad Transformer
- Type system of Typescript
- Types in FP-TS
- Http4s newrelic
- Http4s Route
- Elasticsearch原理初识
- Rust浅析
- 范畴论
- Web3
(2) 直接指出
最简单也是最有效的方式，当你发现某个人没有充分的参与团队事务的时候，可以友善的进行提醒，但也要根据实际情况，这里的前提是已经建立好了前面所说的信任，只要发出提醒的人了解被提醒人的性格和追求，明白什么程度的提醒不会对被提醒人造成伤害，那就没问题，简单高效，且能快速拉回所有人的注意力。
第四大障碍：逃避责任？
这里的逃避责任指的是在团队协作中，团队成员看到同事的表现或行为不利于集体利益时，不能够及时的给予提醒。优秀的团队成员通过担负责任来促进彼此的关系，他们会彼此相互尊重，并对别人的表现抱有较高的期待。
逃避责任，主要原因是不愿意在指出别人的不妥行为后，承担有可能造成人际关系紧张的风险，但事实上，当团队成员由于逃避责任而导致整体利益下降时，就真的可能会发生互相“甩锅了”。
那么我们是如何解决的呢？
(1) 值日生轮换制
要保证团队高效率地工作，最有效的方式就是同事间相互施加压力。值日生轮换制的中心思想就是基于此，让团队成员每个人都轮流承担“值日生”的角色，轮换时间团队内部自己协商，我们是一周一次，在做值日生期间，需要承担很多职责，如提醒大家准时参会、提前预定会议室、监督迟到的同学买酸奶、组织进行Awsome Sharing等等，刚开始大家可能不是很适应，需要Leader善意的提醒，但执行了几轮之后，会惊喜的发现整个团队的专业性更高了，大家敏捷实践的执行度也更好了。害怕辜负同事的期望，这比任何规定和制度都更能够促使大家努力工作变得更好。
(2) 作为Leader：低风险激励法
作为Leader，需要能够识别和判断团队成员每个人的特质和状态，对于一些风险较小且相对独立的模块或功能，可以交给团队中符合一定条件的人来负责，最好是该功能或模块对这个人来说有一定成长空间，且该同事需要承担更多的责任。通过这种方式，培养组内成员责任心，既能减轻团队压力，又有助于内部能力建设。
第五大障碍：无视结果？
无视结果指的是团队成员更倾向于关注集体工作目标以外的事情。但实际上，齐心协力、坚持不懈地追求特定目标和结果，这才是衡量一个团队工作表现的标准。
无视结果的一个重要体现是把个人成绩排在集体利益之上，这种障碍最好必须清除，最坏的结果是导致该团队的存在不是为了体现其价值，而是为了存在而存在。
这里就不列出具体的实践了，因为这个障碍比较严重，我们组暂时没有发生过，只有一些小的例子有这个倾向，但都是根据不同的背景提出不同的具体方法解决，比如人事调动、请假问题、具体项目的具体安排等，不具有普适性，所以这里就不列了。
以上就是关于团队协作五大障碍的简单介绍，并根据不同的障碍介绍了与之对应的相关实践，可以看出金字塔结构本身就有一些含义，五种障碍层层递进，下层可能是引发上层障碍的原因，而越往下发生的可能性就越高，也越简单，我们能提出的解决办法也越多。团队建立的过程本身就不容易，尽量把每一件小事做好，尊重每一个团队成员的意愿和追求，就不会有太大的问题发生。团队也要有包容性，正是因为团队是由不同的不完美的人组成，才可能取得成功。
团队文化产出
上面的所有实践都真实的发生在我们组的，当然万事不可能一帆风顺，但经过一定时间的积淀和所有人的努力，我们也形成了自己的团队文化：
“严肃！活泼！团结！紧张！”
这里就不展开讲了，每个团队都有自己的性格，有自己的文化。这些文化，是在平常一点一滴中积累而来，并不会有人说我们要什么样的文化，便会有什么样的文化。文化是一种沉淀和积累，只有整个团队一起共同努力、共同经历后，才会形成团队自己的味道，自己的文化。
团队建设结果
实践证明，在小团队中，要推行什么实践，要做什么事情，从一开始就做一个完美、缜密的计划然后按部就班去实行，是不可取的。在自组织的小团队中，只需要告诉大家，想法是什么，为什么要做，能解决什么问题或者能带来什么价值，然后怎么做，什么时候做，产出是什么，所有的这些，团队会给你最合适的答案。以下是一年内我们团队建设的结果：
- 高效会议：所有人充分参与会议讨论，思想碰撞，并最终达成一致；
- 乐于分享：技术氛围浓厚，乐于自我探寻，并坚持每周Awsome Sharing，分享新技术新思想；
- 高内聚低耦合：面对困难凝聚力强，团队利益第一位，而每一位团队成员拿出来也都很能打；
- 自组织团队：团队自发的进行工作，且有能力面对突发事件；
评论