👩🏾‍🚒 🛶 ✊🏿 多项目模式下的分布式团队管理（审阅和视频报告） 🚶🏼 👳 🧜🏻

9月23日至24日， Saint TeamLead Conf 2019在圣彼得堡举行。 Flant积极参与其中：Igor Tsupko（我们的未知事务主管）举行了一次会议，与会者了解了如何在组织中发现和揭示秘密知识，Sergey Goncharuk（项目经理）作了题为“管理分布式团队”的演讲。多投影。” 按照传统，我们会发布一份报告及其视频的评论（约37分钟）。

“分布式团队”和“多项目”

在一个分散的团队的领导下，不同的公司了解非常不同的事物-例如，分支机构网络或办公室以及远程工作人员...但是在我们的情况下，没有“真正”意义上的办公室。

现在，我们有80多名员工，他们生活在俄罗斯20多个城市和其他地区。在“弗兰达”生日那天，我们大多数人每年仅两天见到彼此“活着”。

其余时间我们住在莫斯科，萨马拉，秋明州，下诺夫哥罗德或其他任何城市，我们与鸟鸣或咖啡味一起工作。我们不用租房，而是将钱投资在真正有用的东西上。而且，由于每个人都在远程工作，所以我们没有划分为“分支”或“ castes”。

最重要的是-尽管有任何限制，我们都聘请最优秀的人才！这就是我们所理解的“分布”的含义。

现在让我们处理多种设计，但首先，请务必深入使用Flanta设备。

我们是一家工程公司，我们有很多工程师。在团队负责人和经理的指导下，由五到七名工程师组成团队。有几个这样的团队，每个团队都有自己的项目集。

对我们来说，项目是一个产品或一个开发团队的客户基础结构。也就是说，该项目有明确的界限，但对增长和发展没有任何限制！

每个项目都有自己的需求，需要以某种方式传达给团队。
这是由经理完成的。这些是“多重设计”的基础。

现在我们对报告标题中的术语有了共识，问题是：需要什么来确保在这样的条件下一切不仅起作用，而且还能正常工作？

团队经理负责解决此问题。从客户到工程师的“翻译”是他的主要能力之一。第二个是组织团队内部以及与客户的建设性沟通。第三项核心能力是在工作流程和工程师的实际能力之间找到平衡：

我们将更详细地分析每个能力。

1.广播期望

甚至同一位客户也可能会有相互矛盾的期望。例如，客户的业务要求赚钱的产品稳定。此外，它还不断补充有有助于增加收入的新功能。
好吧，如果发生任何事故（企业已准备好发生事故），它将尽快消除。听起来很可预测，对吧？

但是此客户也有开发人员。事实证明，他们的期望是完全不同的！对于开发人员而言，生产更为重要（毕竟，业务也要压在他们身上），他们还希望他们的任何要求都可以立即听到并提出（通常用“毕竟，要花5分钟的时间来形容”一词来形容）。

使业务和开发人员都满足需求的唯一一件事是，双方都希望计划的任务能够准确，及时地完成。

让我们从整体上看一下图片。是的，它立刻充满了相互排斥的段落！

添加新功能总是会增加新的故障点。 b！周五发布后，生产不稳定。
我们的工程师在一天中尽可能快地执行开发人员要求的一切，因此计划的任务保持不变。
还是这里的故事：需要更多关注的稳定环境？我们通过为此分配资源来稳定开发人员，但是在又一次推出之后，产量开始下降！
一个经常发生的情况：生产出现故障，整个团队都去修理它。当然，与此同时，计划任务没有任何进展，甚至印度的开发人员也已经在聊天中切换到俄语聊天，因为他们迫不及待地要回答。

我们知道需求本身是矛盾的，这意味着不可能直接传输它们。

2.通讯

广播期望确实存在问题。好吧，也许然后至少通过交流，一切都变得容易了吗？

为了彼此之间以及与客户之间的沟通，我们使用Slack编写文本，使用Google Meet进行会议和场合，说起来比写起来容易。但是在聊天中，我们经常收到的消息中没有有用的含义或包含太多错误，以致于难以理解含义！

我们为什么要注意这一点？事实是，例如，仅在2019年7月，我们在Slack收到了1993年客户的要求，需要强制响应。并且，当然，随着客户数量的增长，此类请求数量的增长呈稳定趋势。在7月，我们花费了大约165个工程小时来响应此类呼叫。但是对于每个上诉，也有必要做一些事情！

非常遗憾的是，工程师们的时间被浪费在了本可以花在计划任务，对其他电话的反应甚至是维修事故上的时间上。

聊天室的问题很明显，但是视频会议可能没有问题吗？

上面我们说过，我们使用Google Meet进行团队日常集会，其余时间则执行我们在集会中整理的任务。每天我们在集会上花费大约一个小时。我们尝试每天至少花费7个小时进行直接工作，也就是说，剩下6个小时来完成任务。但是我们的任务在持续时间上有很大的不同。

事实证明，在集会的一个小时内，我们可以完成几个小的任务，但对于我们的客户任务可能很重要。我们需要了解是否真的需要观看会议，或者这次去工作更好吗？

如果您尝试解决沟通问题，我们会发现聊天会产生无用的打扰，定期聚会会“浪费”工作时间。

有效的沟通并不能靠自己。

3.规划

好吧，我们需要解决通信和广播期望中的问题，但是在规划中，可能没有陷阱吗？让我们弄清楚。

每天都会创建大量新任务。我希望我们尽快完成任务。但是在生活中，理想是很难实现的。首先，有时基础架构出现故障。其次，总有一些小事情容易立即完成。第三，我们同意在团队聚会中解决的任务：

有时，由于事故和琐事的发生，根本不可能达到计划的目标！同时，新任务不会停止到达-所有承诺的最后期限都被打破。

我们的食谱

但是，对于期望转换，沟通和计划，填充锥体的方法所遇到的所有问题，我们似乎都能找到正确的答案。

团队会议是影响所有三个核心能力的关键业务流程之一。并且我们假设，如果我们使团队会议有效，那么我们可以用20％的努力实现80％的结果？我们测试了这个理论。

您还记得，我们有一个团队为我们的项目服务。她对这些项目有一定的要求清单。但是，通常，每个需求只是一系列相互关联的任务中的一个。在每个项目中都是如此！在执行新任务之前，我们需要了解我们是否已经完成上一个阶段？

昨天，任务A-1由Egor，任务B-1-Semyon和任务B-1-Jeanne执行。但是我们如何使所有工程师沉浸在所有项目中，以使Yegor成功完成任务B，而Semyon则成功完成了两个小任务A和B。“为什么所有这些困难？” -你问。是的，事实是Zhanna今天不会在假期完成计划的任务！

我们的重点是很多类似的任务。平均而言，每个工作日我们为每个团队接收约25个新任务。而且由于任务很多，它们之间的连接很混乱，无法理解前一天的所有任务是否已经完成。为了解决所有这些问题，我们需要在每个工作日进行团队集会，否则我们将无法管理此流程。

考虑到流量，值得提前准备集会。在没有工程师的情况下进行的培训中，我们将无法理解哪些任务已完全完成，哪些任务尚未完成。而且，当然，我们将无法在工程师之间传递知识。但是我们无疑能够确定执行新任务的优先级。

任务优先级

在确定任务优先级时我们基于什么？首先，我们与客户就需要实现的目标达成战略协议。其次，我们每周更新一次与客户进行在线会议的战术计划。经理坚持客户的准备需求，团队领导则是技术上的必要性和完成一项或另一项任务的程序。没错，基于团队负责人和经理的意见相同，就形成了一天的任务清单。

团队会议的文化

一旦我们确定了当天的任务清单以澄清已完成的工作并让我们的同事沉浸在细节中，我们便开始了一次团队会议，每位工程师必须详细告知他昨天的工作，并且整个团队都应该听到并且最重要的是，了解已经发生的变化。但这说起来容易做起来难。

我们介绍了集会的许多文化特征，这些特征使我们能够达到预期的结果：

集会开始时，每个人都在聚会时，我们花10-15分钟谈论生活。关于与工作无关的新闻和事件，关于同事的爱好。因此，位于不同城市且几乎从未见过彼此的工程师成为朋友甚至朋友。 每天这10到15分钟可以帮助团队更加团结 。

在团队建设对话之后，我们进入实质性部分。让我们回去一点。

还记得这个插图吗？事实是，Semyon和Yegor都不知道在集会开始之前他们今天将执行哪些任务和项目。出于多种原因：休假，商务旅行，疾病，职务等。 -任务可以每天改变执行者，直到完全解决为止。每个工程师都知道今天可以分配一个任务，也就是说，所有工程师最初都已经对钻研每个任务的细节感兴趣 。

在集会上，我们分析了整个团队遇到的障碍。我们坚持要求整个团队参与解决演讲者的问题。因此，我们积极投入工作并共同解决这些问题 。

如果团队在办公室工作，则非正式交流通常是在“较凉的地方”进行的。但是在分布式团队中，需要进行此类交流。这就是为什么在讨论任务时，对话通常会朝错误的方向泄漏。但我们停止任何干扰。到底如何我们设法做到这一点很容易：毕竟，抽象对话有一个特别分配的时间，现在是工作时间。因此，即使是通常的口头“让我们着重点”也足以使每个人回到业务议程。通过在分析任务的过程中停止分心，我们组建了工作团队 。

我们试图控制每个工程师的报告时间。有时要深入研究细节，我们需要有关该任务的详尽而详尽的故事。但是，在大多数情况下，我们尽量不扩大集会 。

有效的集会-银弹？

得益于团队负责人和经理的意见均等，并根据我们的文化特点，为集会做准备，我们的确使他们有效。但是，您是否设法关闭了全部能力的80％？不完全是

我们在广播期望方面做得很好，但是通信中的闲聊消息仍然存在问题，并且计划中的中断使我们无法有效地执行预定的任务。

是的，但是非信息性的聊天消息也会中断。我们需要找到一种机制来帮助我们有效地处理各种中断。

对抗打扰

我们认为，如果我们有一个单独的人将与自己“覆盖”一个团队来处理中断流程中的计划任务，该怎么办？

这个想法不是一个新想法，而且总体上来说还不错，但是到底谁会做到呢？我们考虑了两种选择：寻找和雇用这样的服务或使用现有的工程师。寻找新人需要时间和财力，现有工程师已经在“战役中经受过考验”，并且沉浸在团队的所有项目中。因此，拒绝雇用新人。

当前工程师如何组织这样的服务还有待决定。这是表面上的解决方案：他们只是按计划执行任务，并由团队中的工程师轮流担任。我们将值班时间表保存在Google日历中，并在Slack中设置有关今天谁在值班的通知。

看来现在一切都应该没事了？万岁不，实际上问题仍然存在。请记住，之前我们曾说过，仅在Slack上，我们每个月就会获得近2,000次点击，每个团队每天约有16次点击。但是，除了Slack之外，服务员还必须处理来自监视系统的消息，并在当天进行处理：

112-来自普罗米修斯；
16-来自okometer;
25-来自外部黑盒监控系统；
14-来自各种自定义脚本；
甚至有2个来自客户的电话。

每天有来自不同来源的198次中断！但实际上，还有更多来源：

几乎每个客户都有普罗米修斯；
Okmeter安装在每个客户端上；
但是自定义脚本，即使一个客户端也可以拥有任意数量的...

为了使团队中的任何工程师都能在没有魔术和超能力的情况下进行处理，我们将所有中断源的警报收集在一处。我们称此工具为Madison，其中的每个消息都是一个事件。

但是麦迪逊只收集事件并为它们保留财富。但是，我们需要了解首先要处理的事件类型，即进行分类，具有明确的处理和升级顺序，以便在压力很大的情况下轻松进行处理。

我们还创建了这样一种工具-称为Polk：

Polk是值班工程师的工作场所。它使服务人员仅关注事件，而不会被计划的任务分散注意力，在一处接收来自所有来源的事件，根据预定义的严重性帮助确定事件的严重性，具有一组明确定义的状态以及确定这些状态运动的处理算法。

聊天的技术和文化特色

优秀：现在，服务员配备了如此强大的工具，真的使团队免受干扰。但是即使使用了这样的工具，手表也很累，无用的打扰只会使火上加油。

为了解决无用的聊天中断问题，我们可以使用一小组技术工具，但是解决此问题的主要方法肯定是在文化层面。

从技术角度来看，我们在Slack上共享项目信息，并创建了一个单独的渠道与客户代表进行交流，并且为每个项目提供了一个工程师讨论其工作的渠道。我们还编写了@flant机器人，当由Polk访问时，系统会自动创建一个事件，由值班人员处理。

此外，我们建议客户使用@flant和@channel （通知所有频道成员的事件）和@here （通知所有频道成员在线的事件）仅在您确实无法使用它们的极少数情况下使用（例如，当@flant机器人不可用时）。

与客户合作的第一天，我们会在渠道中发布有关互动的详细说明。在第一次例会上，我们一定会讨论交互，包括@channel ， @here和@flant之间的区别。

特别是，我们关注以下事实：对我们来说， @flant的调用首先是具有强制性反应的操作，而对于大多数团队来说， @channel和@here只是一个中断，这也是无地址的，可以忽略同时分散整个团队的精力来解决计划中的任务，包括该项目。

但是，新同事还是从不了解该漫游器的客户那里进行聊天。其他人只是忘记了。如果发生这种情况，我们轻轻回想一下它的存在。

对于工程师之间的通信，我们对@channel使用相同的规则
和@here ：除非绝对必要，否则请勿使用它们。但是，我们坚持遵守“在聊天中不要只是说“你好”-立即提出想法”的规则。该规则是所有初学者必读的。那些忘记它的人将被提醒这一点-必要时进行部署。

总计：随着班次的引入和聊天中沟通问题的纠正，我们解决了大多数无用的中断以及中断对计划任务执行的影响。