Get best of the week

“当流程中的巨大变化激励团队时该怎么办。” 成为团队负责人的后端工程师的经验

我在Miro担任后端工程师7年，然后成为团队负责人。在过去的几年中，我们的工程团队已经翻了一番，遍及全球且分布广泛，这带来了许多变化。

其中之一是引入了跨职能团队，这些团队可以完全解决问题，从提出构想到发布功能。为此，后端和前端工程师必须快速学习很多我们以前从未做过的事情：测试，使用发行版，进行Scrum仪式-而不损失速度和质量。



朝这个方向迈出的第一步导致错误数量增加，开发速度下降和团队动力不足。在这个困难时期，我刚刚成为团队负责人，所以我个人对失败的恐惧和我自己的无能增加了普遍的压力。

结果，我们应对了这场风暴，将交货时间缩短了一半，并大大提高了跨职能团队的效率。这主要得益于我们对不断变化的态度的转变，即从固定思维方式向增长思维方式的转变。

以下是我在Saint TeamLead Conf 2019上的表现的视频和成绩单，其中以我的团队为例，讨论使这些改变成为可能的流程和工具。


历史第一 更改开发流程以减少交付时间


2016年，我们的开发团队由20人和5个团队组成。团队之间进行有效的互动，快速交换信息和经验。随着员工和团队的增长，CI / CD流程和代码审查的引入，团队之间的相互依赖关系数量增加了。

例如，为了在产品上发布重要功能，团队需要与另外6个工程团队合作：

  • 提供代码进行代码审查。
  • 为质量检查测试提供功能。如有必要，QA将包括DevOps命令以创建特殊的测试环境。
  • 使用发布管理器来释放该功能，发布管理器负责公司中的所有发布。
  • 如果发行过程中出现问题，请连接其他命令。

而且，这还没有考虑到与营销，设计和技术支持团队的依赖性，后者也积极参与功能的发布。

依赖关系越多，交货时间（即从开发开始到发布的时间）越长。交货时间越高，我们为用户提供的价值就越少。

大量的通信和较低的交付速度使团队动力不足。该怎么办？减少依赖性并缩短交货时间。

我们正在尝试在开发中构建输送机


为了解决这个问题，我们首先尝试构建一个输送机：

  • 描述所有阶段和过程；
  • 引入SLA（服务水平协议，要求的质量水平）来确定任务必须经历的每个阶段的时间；
  • 整理流程以防止任务退回到上一个阶段进行改进。

不幸的是，管道无法正常工作：任何阶段的错误都会导致整个链条暂停，而每个团队都被迫同时解决自己积压的问题。例如，质量检查人员需要选择：处理流水线中的错误或从事改进测试过程的任务。优先级排序的问题导致这样一个事实，我们要么发布了功能，但没有设法改善内部流程，要么进行了流程优化，却没有时间发布功能。

然后，我们决定重建传送带，以将其移动到每个团队中。

试图建立跨职能团队


跨职能团队能够从头到尾处理任务：从构思创意到将完成的功能添加到产品上。为此，团队需要具备所有必要的能力，知识和流程。

我们决定先对多个团队进行实验，然后再对整个公司进行更改。我的团队主要处理低级任务，也参加了实验（我  写了我们的一个工作示例  -实现ActiveMQ和Hazelcast）。该团队由3位后端开发人员，一名兼职质量检查工程师和我作为团队负责人组成。

我们确定相互依赖


首先，我们确定了要摆脱的当前依赖关系：

  • 没有专职的质量检查工程师，因此我们可以等待几天到一周的测试。
  •   ,     -.
  • full-time -, ,   .

还有其他依赖项，但我们决定主要关注这三个方面。现在，我们需要从质量检查工程师，Scrum管理员和发行经理那里学到很多东西。

我们学会独立测试，
以前，工程师独立编写单元测试并测试了基本功能，其余则检查了质量检查。现在，我们已经学习了如何独立测试边界情况并编写端到端测试以测试客户端和服务器之间的交互。

学习释放自己
我们同意我们至少每周要释放一次。为此，我们需要团队中的发布经理。后端开发人员之一成为了他们自己的选择。

我们自己进行Scrum仪式
外部Scrum主管没有时间与所有团队打交道，因此在我们团队内部，我们选择了一个希望担任此职务的人。他需要学习如何独立进行计划，修饰和复古。

自然，没有人把我们扔到路障上。质量保证，发布经理和Scrum主管通过了知识并在困难情况下提供了建议。

第一次失败


第一次冲刺的结果不成功。实际上，我们确实开始更快地将任务带到master分支，但是我们无法独立进行单个发行。事实证明，我们的流程和脚本尚未为此做好准备。发布脚本一次只能发布所有服务，因此我们无法单独发布服务的一部分。

我们扭曲了部分流程，在第二个Sprint结束时，我们将第一个Sprint中的任务放到了发行版中。但是，又出了点问题。已发布功能的一半包含严重错误，因此我们决定回滚该版本。他们面临着一个新问题：我们的后端开发人员和团队中的兼职发布经理学会了发布，但仍然没有学会回滚所做的更改。因此，我们需要外部发行经理的帮助。

所有这些导致了团队的动力不足：我们连续第二次冲刺失败，发布了带有严重错误的功能-感觉我们不能自己做任何事情。

历史第二号。新角色和对错误的恐惧


在跨职能团队的实验开始时，后端工程师之一马克斯（Max）自愿成为Scrum Master。但是，在第一次冲刺之后，他走近我，说他不再想成为一名Scrum Master。Max之后是另一位工程师Andrei，他说他不会进行测试：“我是开发人员，而不是测试人员。” 作为团队负责人，对我来说了解这两个失败的原因很重要。

通常，可以与它们一起使用的4个原因之一是决定放弃任务的基石：

  •    → ,  ,   .
  •   (, , ) → , .
  •   , → :   ,   .
  •    →     .

Max理解了Scrum主管带给团队的价值，但担心不能应付促进会议的艰巨任务。同意担任新职务后，他对Scrum管理员的工作了解甚少，并且没有充分说明自己所需的技能。马克斯担心自己无法应付，他会浪费团队的时间，并且在同事们的眼中显得无能。

在与安德烈（Andrei）的情况下，事实证明，他自己测试了自己的代码，并确保一切都很好。但是，以防万一，我进行了质量检查以进行验证，他发现代码中存在5个错误。重复了几次，这使安德烈感到沮丧，他决定不再进行测试。

我对Max和Andrei的情况非常熟悉。我本人最近已经从经验丰富的后端工程师变成了经验不足的团队负责人。就像我担心自己无法完成任务一样，我也没有辜负期望，总的来说，团队领导不是我的。

成长安装和给定安装


当我成为团队负责人时，斯坦福大学教授Carol Dweck建议我阅读“ 灵活意识 ” 一书。简而言之，它描述了两种类型的思维：

  • 固定的心态-信念和能力是一劳永逸的，不可能影响它们，失败则表示缺乏才能。有这种想法的人尽量不要执行复杂的任务，以免失去动力和对自己的信心。
  • 成长心态是一种信念，即只要努力就可以在一生中提高智力和能力。失败是学习某些东西的原因，因此具有这种思维的人不断尝试摆脱自己的舒适区并承担复杂的任务。

自然地，世界不会分为黑白两部分，在不同的情况下，同一个人可能会受到不同类型的思维的支配。例如，一个人可能认为编程是任何人都可以学习的技能，但与此同时，他也认为美味烹饪是自然界中固有的才能，而这是无法学习的。


整个计划都在Carol Duque网站上发布，

这种方法描述了一个人对正在发生的变化的态度。

固定思维占主导地位的人（理所当然）
  • : «  ,      ».
  •     ,   .   , ,   .

  Growth mindset (  )

  •   ,   ,  .
  •    , .
  •     , .

这种方法帮助我改变了对错误的态度。因此，我决定谈论对团队的方法，因为它可以给我们一个统一的坐标系，教会我们以不同的方式对待变化并减少对错误的恐惧。像其他任何工具一样，成长导向可以解决特定的问题，因此我在1：1的会议上讨论了这一问题，旨在向所有人提供对他特别有用的信息，以解决他的处境。

另外，我向团队中的每个人介绍了我自己的示例，即在将角色从工程师更改为团队负责人时使用设置的情况。这增加了其余的自信（“我不是唯一遇到这种情况的人”，“这种情况确实可以改变”）。

故事编号2的延续


实验可以减少期望和压力。在讨论了“成长与固定”思维方式的方法之后，我们同意Max发起一个实验，在其中他将尝试担任Scrum Master的新角色。 “实验”一词很好地减轻了压力。在实验中，犯错并不可怕，但重要的是要对错误进行处理并获得有益的经验。同样，我们谈到了Max对团队的新角色，这降低了团队的期望。

人才是经验。在讨论拒绝测试时，安德烈（Andrei）放弃了这句话：“我在编程方面很有才华。”事实证明，安德烈（Andrei）认为编程和测试是天生的才能。他有第一个，但没有第二个。我们开始讨论Andrei的经历，并意识到Andrei经历了不眠之夜的编程工作，以寻找错误，沉浸在他人项目中的日子，并独立编写了成千上万行代码。事实证明，他在编程方面的专业技能不是天赋，而是他长期有目的地追求的经验。仅通过学习一些东西，我们就经常忘记朝着这个方向迈出的第一步。

个人OKR。为了使我们的进度即使稍有进步也可以看到，我们与团队达成协议，我们将跟踪每次培训的进度。这不仅可以帮助您了解所走的路，而且还可以帮助您了解达到预期目标还需要多少。

在公司一级，我们有OKR，因此我们决定将其应用于个人培训级别。条件如下：

  • 我们仅将对当前工作有所帮助的内容添加到个人OKR；
  • 关键结果应该在任何给定时间都是可测量的，并有助于回答以下问题：“与上周相比，我进步了多少？
  • 每个关键成果都有一系列可以实现的倡议；
  • (, ),   ,    ;
  •  OKRs   1:1.

在本季度实施个人OKRs
在该计划启动几周后，我们意识到什么都没有发生。原来，我们站在自己的耙子上-高估了自己的期望。团队担心长时间以来必须制定理想的OKR，这真是愚蠢。

然后我们同意将其视为迭代之一。OKR始终可以进行审查和完善，这不是刻在石头上的东西，而只是您想要发展的方向。这有助于将主动性视为有趣的游戏，结果一切顺利。

Andrey



Bonus提供的OKR示例，我们同意在团队中共享个人OKR。它有助于彼此学习，并且像公共承诺一样工作。

故事编号1的延续


由于态度的变化，回想起来，我们开始寻找自己而不是外部的困难原因。现在没有比这更早的借口了：“因此建立了流程，我该怎么办。”我们开始完善不适合我们的流程。团队对正在进行的流程有主人翁感。

这使我们开始稳定地执行少量任务。虽然是以前的一半，但我们完全独立地将其出售，没有漏洞。

所有这些使我们更加自信。一段时间后，Andrey独立地使复杂的测试用例自动化。负责发布的Roma优化了流程，以便每个团队成员现在都可以独立发布。

结果，基于该季度的结果，由于减少了依赖性，团队内部能力的增强以及对困难和错误的态度的转变，我们能够将交货时间减少2倍。


我们的生产力不仅受到我们现在拥有的知识和技能的影响，而且还受到我们与公司变革的关系的影响。有时，新流程可能会令人沮丧，而过于复杂的任务可能会破坏自信心。但是，您可以为自己，也可以在整个团队中工作。

我的团队得到了帮助，以应对增长和固定思维方式错误的变化和态度。我们将其视为解决特定问题的工具。当然，安装在几周和几个月内都没有改变。但是，通过改变对特定情况的态度，我们能够在季度内在日常工作任务和困难方面取得重大进展。

More articles:


All Articles