Как создать, организовать и мотивировать команду в IT: интервью с Михаилом Березиным

В этом эпизоде мы поговорили о том, как устроена команда разработки и как планировать и оценивать её работу. Аудиоверсию и новые эпизоды подкаста «Люди и код» слушайте на популярных платформах.

Михаил Березин

Учёный-физик, аналитик, бизнесмен, Product Owner MDM-системы «Единый клиент» в HFLabs.

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

Как устроена команда

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

— Вот уже 17 лет мы в HFLabs работаем над качеством клиентских данных. Собираем и обрабатываем всё, что характеризует людей и компании как клиентов: Ф. И. О. и названия (если речь о юридических лицах), документы, адреса и так далее.

Наше ПО устанавливается на серверы банков и страховых компаний и работает с информацией, которая поступает к ним ежедневно. Такую бизнес-модель называют on-premise software.

Сейчас у нас пять продуктовых направлений, и я веду одно из них (актуально на момент записи подкаста. — Ред.). Кроме того, развиваю новые продукты — и, соответственно, продуктовые команды.

— Как устроена ваша команда, какие роли в ней есть?

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

Очевидно, что её структура зависит от размеров. В маленьких коллективах все занимаются всем — от разработки до переговоров с заказчиком. Каждый участник сам себе кодер, тестировщик, бизнес-аналитик и сервисный инженер. Плюс есть «внедренцы», которые параллельно работают как проджект-менеджеры. Такова культура стартапов, где условия быстро меняются и люди работают тесно.

Сегодня структура продуктовой команды выглядит так: разработчики, тестировщики, продакт-менеджер и аналитики. Причём аналитики делятся на внешних, которые в основном работают с заказчиком, и внутренних, которые заняты продуктом, составляют требования к фичам из roadmap и так далее.

— Сколько примерно человек в команде?

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

Как выстраивается иерархия в команде

— Как выстраиваются горизонтальные и вертикальные связи? Есть ли какая-то иерархия: простой разработчик, ведущий разработчик (сеньор), тимлид, техлид, продакт, PM, VP of Engineering?

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

Например, недавно решали вопрос единого мониторинга всех наших продуктов. Нужно было договориться всем командам: что и как использовать, куда вынести общий код и так далее. У нас не было центра принятия решений, такого условного техдира, который сказал бы: «Делаем вот так — и всё». Ребята могут договориться сами, и пока нам этого хватает.

— А как в эту историю вписываются продакт-менеджеры?

— Хороший вопрос. Продакты в нашей компании не только отвечают за продукт, но и занимаются people-менеджментом, то есть, дословно, управляют людьми.

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

— Есть же и другие отделы, связанные с разработкой? С кем чаще всего взаимодействуют разработчики и как там выстраиваются отношения?

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

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

Как сформировать командные ценности и донести их до каждого

— Как рождается стратегия продукта и как ты доносишь её до разработчиков?

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

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

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

Планирование и управление в команде

— Есть ли у вас какая-нибудь система планирования? Долгосрочное, среднесрочное, квартальное, месячное, на спринт?

— Долгосрочное планирование имеет смысл только в больших проектах. Скажем, у нас есть часть функциональности, которая занимается поиском дубликатов. Это буквально сравнение каждого с каждым на больших объёмах данных и выявление похожих друг на друга по каким-то критериям записей. Задача распределена между несколькими продуктами: часть решается в одном, часть в другом, всё собирается в третьем. Мы справлялись, но в какой-то момент поняли, что, если так пойдёт и дальше, через два года появятся объёмы данных, с которыми мы не будем справляться за разумное время.

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

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

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

— На рефакторинг у вас выделяется отдельное время — например, день в неделю?

— Мы пробовали разные подходы. Когда-то давно выделяли для него специальный день. Это не работало, потому что, с одной стороны, за ним тянулись «хвосты» из предыдущих дней, а с другой — одного дня мало для чего-то крупного, поэтому получалось исправлять только мелочи.

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

Как перевести бизнес-задачу на язык разработчиков

— Где грань между задачей, сформулированной на языке бизнеса, и задачей для разработчиков? Как бизнес-задача становится технической?

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

Если постоянно делать задачи из разряда «переименуй вот это поле», «добавь такую таблицу» и что-то подобное без понимания, как этим будут пользоваться, для какого процесса это нужно, сколько компания заработает на этом денег, — это демотивирует.

Как проходят спринты

— Давай теперь рассмотрим спринт. Как устроен весь процесс?

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

Раньше мы рассматривали ряд задач, оценённых аналитиками на предмет того, сколько времени и ресурсов потребуется для их решения, и оформленных в отдельные поля в Jira. Набирали в спринт объём задач, который в него умещается, и расставляли приоритеты по важности, сложности, количеству заказчиков и так далее.

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

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

А потом случилась пандемия. Команда была сработавшаяся, так что все ритуалы синхронизации я убрал полностью. Люди понимали друг друга без слов, работали без сбоёв, ретроспективы делали раз в два спринта.

У нас было два варианта. Если ребята давно друг друга знали, они могли обходиться без дополнительных ритуалов. Но если, что случалось чаще, в команде были новенькие, требовалась синхронизация, чтобы быстрее получать от них обратную связь и помогать им.

Ретроспективы теперь — больной для нас вопрос. Мы их давно не проводим. Пробовали несколько вариаций формата, но пока не поняли, как его изменить. Договорились делать ретроспективы вокруг конкретных кейсов. Допустим, у нас что-то пошло не так в работе над какой-то фичей, во взаимодействии, процессе. Собираем команду до 10 человек из тех, кто в теме, и разбираем этот кейс.

— А покер раскладываете, когда оцениваете объём задач? Есть какой-то формализованный процесс или на глаз прикидываете?

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

После оценки идёт планирование — примерно так же, как и раньше: спринт наполняется, исходя из доступных ресурсов, из оценок и приоритетов, которые сохранились.

Как оценить, справилась ли команда с задачей

— Что происходит дальше? Есть ли какие-то критерии, по которым вы понимаете, что задача выполнена качественно. Когда она считается принятой? Тесты, код-ревью, ещё что-то?

— Полтора года назад код-ревью у нас вообще не было: они не требовались, так как все разработчики были довольно опытными. С ростом команды начали делать код-ревью по потребностям. А потом поняли, что нужен постоянный процесс. Сейчас есть отдельный статус в Jira: назначается ревьюер, он делает код-ревью задачи, и только после этого она резолвится.

У каждой задачи есть закрывающий тестировщик, который дополняет кейсами наши автотесты. Тестирование автоматизировано. Так как мы работаем с данными, у нас собственный фреймворк по data-driven testing. Нужно создать некое начальное и конечное состояние данных, какие-то операции между ними — то есть кейс. Гоняются кейсы фреймворком на разных уровнях — как на сервисном, так и на полноценном интеграционном, когда поднимаются два или три наших продукта, которые друг с другом взаимодействуют.

— Можно описать разработку фичи на конкретном примере?

— Например, есть задачи, которые приходят из саппорта и связаны с проблемами перформанса. Предположим, наш сервис стал медленнее отвечать на запросы. Что делать?

Мы выстроили отдельный процесс и сделали несколько классных фич, которые помогают в этом разбираться. Продукт при появлении триггеров — допустим, увеличении времени ответа по какому-то методу в API — автоматически включается в сбор профилировки. Запускается Flight Recorder.

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

Первый: очевидная проблема, которую можно пофиксить за 10 минут. Допустим, читаем из базы три раза одно и то же.

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

Мы смотрим на метрики, пытаемся воссоздавать сложные ситуации с помощью chaos engineering, увеличивая задержку ответа от базы данных или изменяя что-то в параметрах железа в процессе работы продукта, и так далее.