47,86
Рейтинг
Miro
Online collaborative whiteboard platform
22 апреля

“Что делать, когда кардинальные изменения в процессах демотивируют команду”. Опыт бэкенд-инженера, ставшего тимлидом

Блог компании MiroУправление разработкойУправление проектамиУправление персоналом
🔥 Технотекст 2020
Я 7 лет работал бэкенд-инженером в Miro, затем стал тимлидом. За последние годы наша инженерная команда выросла вдвое, стала распределённой и международной, что повлекло за собой множество изменений.

Одним из них стало введение кросс-функциональных команд, которые бы могли решать задачу полностью, от проработки идеи до релиза фичи. Для этого бэкенд- и фронтенд-инженерам нужно было в короткие сроки освоить многое из того, чем раньше мы никогда не занимались: тестирование, работу с релизами, проведение скрам-ритуалов, — при этом не потерять в скорости и качестве.



Первые шаги в этом направлении привели к росту количества ошибок, снижению скорости разработки и демотивации команд. В этот непростой период я как раз стал тимлидом, поэтому к общему стрессу добавился мой личный страх провала и собственной некомпетентности.

В итоге мы справились со штормом, вдвое уменьшили Lead Time и существенно продвинулись в эффективности кросс-функциональных команд. Этому во многом помогло изменение нашего отношения к происходящим переменам, переход от Fixed mindset к Growth mindset.

Ниже — видео и расшифровка моего выступления на Saint TeamLead Conf 2019, где на примере своей команды я рассказываю про процессы и инструменты, которые сделали эти изменения возможными.


История №1. Изменение процесса разработки для уменьшения Lead Time


В 2016 году наша разработка состояла из 20 человек и 5 команд. Команды эффективно взаимодействовали друг с другом, быстро обменивались информацией и опытом. По мере роста сотрудников и команд, внедрения процессов CI/CD и код-ревью количество взаимозависимостей между командами увеличивалось.

Например, для вывода на прод большой фичи команде нужно было работать с ещё 6 инженерными командами:

  • Отдать код на сode review.
  • Отдать фичу на тест QA. При необходимости QA подключит команду DevOps для создания специального тестового окружения.
  • Зарелизить фичу с помощью релиз-менеджера, который отвечает за все релизы в компании.
  • Подключить дополнительные команды, если во время релиза что-то пойдёт не так.

И это без учёта зависимостей с командами маркетинга, дизайна и технической поддержки, которые тоже активно участвуют в запуске фичей.

Чем больше зависимостей, тем больше Lead Time, то есть время от старта разработки до релиза. Чем выше Lead Time, тем меньше ценности мы доставляем до пользователей.

Большое количество коммуникаций и низкая скорость доставки демотивируют команду. Что делать? Уменьшить количество зависимостей и сократить Lead Time.

Пробуем построить конвейер в разработке


Для решения этой задачи мы первым делом попробовали построить конвейер:

  • описать все этапы и процессы;
  • ввести SLA (Service Level Agreement, уровень необходимого качества), чтобы определить время, за которое задача должна проходить каждый этап;
  • выпрямить потоки, чтобы не допускать повторного ухода задачи на предыдущие этапы для доработок.

К сожалению, конвейер не сработал: ошибка на любом из этапов приводила к остановке всей цепочки, при этом каждая команда параллельно была вынуждена решать задачи из собственного бэклога. Например, QA нужно было выбирать: разбираться с багой на конвейере или заниматься задачами по улучшению процесса тестирования. Эта проблема приоритезации приводила к тому, что мы либо релизили фичи, но не успевали улучшать внутренние процессы, либо занимались оптимизацией процессов и не успевали релизить фичи.

Тогда мы решили перестроить конвейер, чтобы перенести его внутрь каждой команды.

Пробуем построить кросс-функциональные команды


Кросс-функциональные команды способны заниматься задачей от начала и до конца: от проработки идеи до вывода готовой фичи на прод. Для этого команде нужно иметь внутри все необходимые компетенции, знания и процессы.

Мы решили провести эксперимент на нескольких командах, прежде чем раскатывать изменения на всю компанию. В эксперимент попала и моя команда, которая занимается в основном низкоуровневыми задачами (я писал про один из примеров нашей работы — внедрении ActiveMQ и Hazelcast). Команда состояла из 3 бэкенд-разработчиков, part-time QA-инженера и меня в роли тимлида.

Определяем взаимозависимости


Первым делом мы определили текущие зависимости, от которых хотим избавиться:

  • Нет своего full-time QA-инженера, в результате чего можем ждать тестирование от нескольких дней до недели.
  • Не можем самостоятельно релизить фичи, потому что за вывод на прод отвечает релиз-менеджер.
  • Нет своего full-time скрам-мастера, поэтому иногда пропускаем груминги или ретроспективы, что приводит к снижению эффективности.

Были и другие зависимости, но мы решили в первую очередь сфокусироваться на перечисленных трёх. Теперь нам нужно было научиться многому из того, чем раньше занимались QA-инженер, скрам-мастер и релиз-менеджер.

Учимся тестировать самостоятельно
Раньше инженеры самостоятельно писали unit-тесты и тестировали базовый функционал, остальное проверял QA. Теперь мы учились самостоятельно тестировать пограничные ситуации и писать end-to-end тесты, чтобы проверять взаимодействие между клиентом и сервером.

Учимся релизить самостоятельно
Мы договорились, что хотим релизить как минимум раз в неделю. Для этого нам нужен релиз-менеджер внутри команды. Им по собственному желанию стал один из бэкенд-разработчиков.

Проводим скрам-ритуалы самостоятельно
Внешний скрам-мастер не успевал заниматься всеми командами, поэтому внутри своей команды мы выбрали желающего на эту роль. Ему нужно было научится самостоятельно проводить планинги, груминги и ретро.

Естественно, никто не бросал нас на баррикады. QA, релиз-менеджер и скрам-мастер передавали знания и консультировали в трудных случаях.

Первые провалы


Результаты первого же спринта оказались неудачными. Мы действительно стали гораздо быстрее доводить задачи до master-ветки, но нам не удалось самостоятельно сделать ни одного релиза. Оказалось, наши процессы и скрипты не были к этому готовы. Скрипт релиза умел релизить только все сервисы одновременно, поэтому мы не могли зарелизить нашу часть сервиса отдельно.

Мы подкрутили часть процессов и в конце второго спринта вывели в релиз задачи из первого спринта. Однако что-то снова пошло не так. Половина выпущенного функционала содержала критичные баги, поэтому мы приняли решение откатить релиз. И столкнулись с новой проблемой: наш бэкенд-разработчик и по совместительству релиз-менеджер в команде, научился релизить, но ещё не научился откатывать изменения. Поэтому нам потребовалась помощь внешнего релиз-менеджера.

Всё это привело к демотивации команды: мы фейлим второй спринт подряд, выпускаем функциональность с критичными багами, — ощущение, что мы не можем делать ничего самостоятельно.

История № 2. Новая роль и страх ошибки


В начале эксперимента с кросс-функциональными командами стать скрам-мастером вызвался Макс, один из бэкенд-инженеров. Однако после первого спринта он подошёл ко мне и сказал, что больше не хочет быть скрам-мастером. Вслед за Максом пришёл Андрей, ещё один инженер, и сказал, что он не будет заниматься тестированием: «Я разработчик, а не тестировщик». Мне как тимлиду было важно разобраться в причинах обоих отказов.

В основе решения отказа от задачи лежит, как правило, одна из 4 причин, с каждой из которых можно работать:

  • Я не вижу ценности → донести ценность, переформулировать задачу или отказаться от задачи, если в ней действительно нет ценности.
  • У меня нет нужных ресурсов (времени, процессов, инструментов) → предоставить эти ресурсы, если это возможно.
  • Я не знаю, как это делать → предоставить необходимые знания: подсказать как и где найти информацию, познакомить с нужным человеком.
  • Я не хочу это делать → личная неприязнь к вам либо плохо проработанная одна из перечисленных выше причин.

Макс понимал ценность, которую приносит команде скрам-мастер, но боялся не справиться со сложными задачами фасилитации встреч. Соглашаясь на новую роль, он мало знал о работе скрам-мастера и не отдавал себе полного отчёта в умениях, которые ему для этого потребуются. Макс боялся, что не справится, потратит время команды впустую и будет выглядеть некомпетентным в глазах коллег.

В ситуации с Андреем оказалось, что он протестировал самостоятельно свой код и был уверен, что всё хорошо. Однако на всякий случай отдал на проверку QA, а тот нашёл в коде 5 багов. Это повторялось несколько раз, что демотивировало Андрея, и он решил больше не заниматься тестированием.

Мне были хорошо знакомы ситуации Макса и Андрея. Я сам ещё недавно превратился из опытного бэкенд-инженеры в неопытного тимлида. И точно также боялся, что не справлюсь с задачами, не оправдаю ожиданий и вообще тимлидерство — не моё.

Установка на рост и установка на данность


Когда я стал тимлидом, мне посоветовали прочитать книгу «Гибкое сознание» профессора Стэнфордского университета Кэрол Дуэк (Carol Dweck). Если кратко, то в ней рассказывается о двух типах мышления:

  • Fixed mindset — убеждение в том, что интеллект и способности раз и навсегда зафиксированы, влиять на них нельзя, а неудача говорит об отсутствии таланта. Люди с таким мышлением стараются не брать сложных задач, чтобы не терять мотивации и веры в себя.
  • Growth mindset — убеждение в том, что интеллект и способности могут совершенствоваться в течение жизни, если прилагать для этого усилия. Неудача — повод чему-то научиться, поэтому люди с таким мышлением постоянно пытаются выйти из зоны комфорта и берутся за сложные задачи.

Естественно, мир не делится на чёрное и белое, в разных ситуациях у одного и того же человека может преобладать разный тип мышления. Например, человек может считать, что программирование — это навык, которому может научиться любой человек, но он же одновременно считает, что вкусно готовить — это талант, заложенный природой, и научиться этому нельзя.


Вся схема — на сайте Кэрол Дуэк

Этот подход хорошо описывает отношение человека к происходящим изменениям.

Люди с преобладанием Fixed mindset (установка на данность)
  • Жертва изменений: «Я так хорошо работал, а тут пришли вы и начали всё менять».
  • Не разбираются в истинных причинах, а просто возмущаются. Если процесс идёт не по плану, они говорят, что всё плохо и нужно возвращать всё как было раньше.

Люди с преобладанием Growth mindset (установка на рост)

  • Я совладелец изменений, поэтому хочу понять цель изменений и помочь исправить ошибки, которые возникают по ходу.
  • Дают конструктивную критику и пытаются исправить самостоятельно то, что могут.
  • Нормально относятся к ошибкам и не считают, что это конец света.

Этот подход помог мне изменить своё отношения к ошибкам. Поэтому я решил рассказать о подходе команде, так как он мог дать нам единую систему координат, научить иначе относиться к изменениям и снизить страх ошибок. Как и любой инструмент, установка на рост работает для решения конкретных проблем, поэтому я рассказывал о ней на встречах 1:1, чтобы дать каждому ту информацию, которая будет полезна именно ему для решения его ситуации.

Дополнительно я рассказывал каждому в команде о собственном примере работы с установками в момент смены роли с инженера на тимлида. Это добавляло остальным уверенности в себе («не я один с этим столкнулся», «эту ситуацию реально изменить»).

Продолжение истории № 2


Эксперимент снижает уровень ожиданий и стресса. После обсуждения подхода с Growth & Fixed mindset мы договорились с Максом запустить эксперимент в рамках которого он попробует новую для себя роль скрам-мастера. Слово «эксперимент» хорошо снижает градус напряжения. В эксперименте не страшно ошибаться, но важно делать работу над ошибками и выносить полезный опыт. В этом же ключе мы рассказали о новой роли Макса команде, что снизило ожидания у команды.

Талант — это заработанный опыт. Андрей при обсуждении его отказа тестировать обронил фразу: «Я талантлив в программировании». Оказалось, что Андрей считал программирование и тестирование — врождёнными талантами. Первый у него был, а второй — нет. Мы начали обсуждать опыт Андрея и поняли, что Андрей прошёл в программировании через бессонные ночи в поисках ошибок, дни погружения в чужие проекты, написал самостоятельно десятки тысяч строк кода. Получается, что его экспертиза в программировании — не талант, а опыт, к которому он долго и целенаправленно шёл. Просто научившись чему-то, мы часто забываем о первых шагах, сделанных в этом направлении.

Персональные OKRs. Для того, чтобы сделать наш прогресс видимым даже при незначительном продвижении вперёд, мы договорились с командой, что будем трекать прогресс обучения каждого. Это поможет не только видеть пройденный путь, но и понимать, сколько ещё нужно пройти до намеченной цели.

На уровне всей компании у нас работает система OKRs, поэтому мы решили применить её для уровня личного обучения. Условия были такие:

  • Добавляем в личные OKRs только то, что помогает в текущей работе;
  • Key Results должны быть измеримы в любой момент времени и помогать отвечать на вопрос «Насколько я продвинулся в сравнении с прошлой неделей?;
  • У каждого ключевого результата есть список инициатив, которые позволяют его достичь;
  • Можно добавлять внерабочие активности (спортивные, творческие), они помогают отдыхать и переключать контекст, а это повышает эффективность на работе;
  • Трекаем прогресс по OKRs на регулярных встречах 1:1.

Внедрение персональных OKRs на квартал
Через несколько недель после запуска инициативы мы поняли, что ничего не происходит. Оказалось, что мы встали на собственные грабли — завысили собственные ожидания. Команда переживала, что нужно сделать идеальные OKRs на длительный срок и это вводило в ступор.

Тогда мы договорились, что будем относится к этому как к одной из итераций. OKRs всегда можно пересмотреть и доработать, это не что-то высеченное в камне, а скорее лишь направление, куда ты хочешь развиваться. Это помогло воспринять инициативу как интересную игру, и дело пошло.

Пример OKRs Андрея



Бонусом мы договорились поделиться личными OKRs внутри команды. Это помогает учиться друг у друга и работает как публичный коммит.

Продолжение истории № 1


Благодаря изменению установки, на ретроспективах мы начали исктать причины сложностей в самих себе, а не снаружи. Теперь уже не было оправданий, которые могли звучать раньше: «Так выстроен процесс, что я могу поделать». Мы начали дорабатывать процессы, которые нас не устраивали. У команды появилось ощущение владения происходящими процессами.

Это позволило нам начать стабильно реализовывать небольшое количество задач. Пусть оно было в два раза меньше, чем раньше, но мы доводили его до прода полностью самостоятельно и без багов.

Всё это добавило нам уверенности в собственных силах. Через какое-то время Андрей самостоятельно автоматизировал сложные тест-кейсы. Рома, отвечающий за релизы, оптимизировал процесс так, что каждый участник команды теперь мог релизить самостоятельно.

В итоге по результатам квартала нам удалось снизить Lead Time в 2 раза за счёт уменьшения зависимостей, увеличения компетенций внутри команды и изменения отношения к сложностям и ошибкам.



На нашу продуктивность влияют не только знания и умения, которыми мы обладаем сейчас, но и то, как мы относятся к переменам в компании. Иногда новые процессы могут демотивировать, а слишком сложные задачи — подкосить уверенность в себе. Но с этим можно работать как для себя, так и на уровне всей команды.

Моей команде помог справиться с изменениями и отношением к ошибкам Growth & Fixed mindset. Мы относимся к нему как к рабочему инструменту, который решает конкретные задачи. Разумеется, изменение установки не произошло за несколько недель и месяцев. Но меняя отношение к конкретным ситуациям, мы смогли за квартал сильно продвинуться вперёд в отношении к ежедневным рабочим задачам и сложностям.
Теги:mirorealtimeboardкросс-функциональные командыgrowth mindsetfixed mindset
Хабы: Блог компании Miro Управление разработкой Управление проектами Управление персоналом
+9
5,6k 20
Комментарии 16
Похожие публикации
▇▅▄▅▅▄ ▇▄▅