Все
Истории
Дизайн
Код
Геймдев
Бизнес
Маркетинг
Управление
Кино
Музыка
Проектная фотография
Развитие
Здоровье
Деньги
Образование
EdTech
Корп. обучение
Блог Skillbox
Глоссарий
Спецпроекты
Профориентация
Как создать, организовать и мотивировать команду в IT: интервью с Михаилом Березиным
Текстовая версия подкаста «Люди и код».
В этом эпизоде мы поговорили о том, как устроена команда разработки и как планировать и оценивать её работу. Аудиоверсию и новые эпизоды подкаста «Люди и код» слушайте на популярных платформах.
Михаил Березин
Учёный-физик, аналитик, бизнесмен, Product Owner MDM-системы «Единый клиент» в HFLabs.
- Как устроена команда
- Как выстраивается иерархия в команде
- Как справляться с конфликтами в команде и предотвращать выгорание сотрудников
- Как сформировать командные ценности и донести их до каждого
- Планирование и управление в команде
- Как перевести бизнес-задачу на язык разработчиков
- Как проходят спринты
- Как оценить, справилась ли команда с задачей
- Как влиться в команду: советы новичкам
Как устроена команда
— Михаил, ваша компания, что называется, широко известна в узких кругах, но массовый потребитель знает о ней довольно мало. На чём вы специализируетесь?
— Вот уже 17 лет мы в HFLabs работаем над качеством клиентских данных. Собираем и обрабатываем всё, что характеризует людей и компании как клиентов: Ф. И. О. и названия (если речь о юридических лицах), документы, адреса и так далее.
Наше ПО устанавливается на серверы банков и страховых компаний и работает с информацией, которая поступает к ним ежедневно. Такую бизнес-модель называют on-premise software.
Сейчас у нас пять продуктовых направлений, и я веду одно из них (актуально на момент записи подкаста. — Ред.). Кроме того, развиваю новые продукты — и, соответственно, продуктовые команды.
— Как устроена ваша команда, какие роли в ней есть?
— Когда я только пришёл в компанию, в продуктовой команде было около десяти человек. Сейчас их больше полусотни. С тех пор моё представление о том, как должна быть устроена команда, постоянно менялось.
Очевидно, что её структура зависит от размеров. В маленьких коллективах все занимаются всем — от разработки до переговоров с заказчиком. Каждый участник сам себе кодер, тестировщик, бизнес-аналитик и сервисный инженер. Плюс есть «внедренцы», которые параллельно работают как проджект-менеджеры. Такова культура стартапов, где условия быстро меняются и люди работают тесно.
По мере роста компании кристаллизуются отдельные роли. У нас первой выделилась техподдержка — как труднее всего поддающаяся планированию. Никто ведь не знает, в какой момент у заказчика случится проблема и какого она будет масштаба. Затем сформировались команды для работы с заказчиками и внедрения.
Сегодня структура продуктовой команды выглядит так: разработчики, тестировщики, продакт-менеджер и аналитики. Причём аналитики делятся на внешних, которые в основном работают с заказчиком, и внутренних, которые заняты продуктом, составляют требования к фичам из roadmap и так далее.
— Сколько примерно человек в команде?
— Над каждым продуктом работает отдельная команда, и все они сильно различаются по размеру — есть группы как из трёх человек, так и из двадцати. У флагманского продукта, над которым я работаю, команда разработки из 27 человек, которая, в свою очередь, делится на группы по фичам.
Как выстраивается иерархия в команде
— Как выстраиваются горизонтальные и вертикальные связи? Есть ли какая-то иерархия: простой разработчик, ведущий разработчик (сеньор), тимлид, техлид, продакт, PM, VP of Engineering?
— Явных грейдов нет. Конечно, у проекта долгая история и нетривиальная бизнес-логика, и они требуют времени на погружение, поэтому разработчиков можно условно поделить на опытных и новичков. Но важные вопросы — например, касающиеся архитектуры или масштабных изменений в проекте — мы обсуждаем всей командой разработки.
Например, недавно решали вопрос единого мониторинга всех наших продуктов. Нужно было договориться всем командам: что и как использовать, куда вынести общий код и так далее. У нас не было центра принятия решений, такого условного техдира, который сказал бы: «Делаем вот так — и всё». Ребята могут договориться сами, и пока нам этого хватает.
— А как в эту историю вписываются продакт-менеджеры?
— Хороший вопрос. Продакты в нашей компании не только отвечают за продукт, но и занимаются people-менеджментом, то есть, дословно, управляют людьми.
Таким образом, вырисовывается трёхуровневая структура. Продакт-менеджер управляет развитием продукта, бэклогом, задачами и коммуникацией с аккаунт-менеджерами, аналитиками, ответственными за работу с заказчиками. Ещё есть производство, в чьи задачи входит планирование, выпуск релизов, регрессионное тестирование, передача проекта заказчику и тому подобное. Плюс в каждой ролевой команде — в тестировании, поддержке, разработке — есть свой тимлид, который отвечает за внутреннюю коммуникацию.
— Есть же и другие отделы, связанные с разработкой? С кем чаще всего взаимодействуют разработчики и как там выстраиваются отношения?
— Традиционный подход, когда компания жёстко делится на отделы, каждый выполняет строго свою часть задачи и потом передаёт другому отделу, нам кажется устаревшим. Это сильно тормозит коммуникацию, а для нас важно, чтобы сотрудники постоянно общались и обменивались знаниями.
У нас это выглядит так: когда в спринт берётся большая фича, вокруг неё собирается кросс-функциональная команда от трёх до шести человек. В неё могут входить разработчики, тестировщики, аналитики, дизайнеры и фронтендеры. Внутри этой мини-команды ребята сами определяют, как им удобнее работать. При этом состав и количество групп не фиксированы — они зависят от конкретной фичи.
Как справляться с конфликтами и предотвращать выгорание сотрудников
— Где и когда обычно возникают конфликты и как вы их разрешаете?
— Главное при разрешении конфликтов — не бояться их возникновения. Нужно создавать культуру, в которой конфликт — это нормально и все понимают, как с ним справиться: с помощью открытого диалога, обсуждения. Мы не ангелы, у всех есть эмоции, но с ними можно работать. У нас для этого предусмотрены соответствующие ритуалы.
Чаще всего недопонимание возникает из-за того, что проект большой, технических деталей много и, каким бы классным аналитиком ты ни был, как бы хорошо ни проработал задачу, всё равно в процессе что-то всплывает. Может выясниться, что задача будет сдана позже, чем ожидалось, или что она вообще невыполнима в начальной постановке. Такое случается нечасто, но всё же раз в год-полгода бывает.
Единого рецепта нет, но я не уверен, что таких случаев нужно избегать. Это нормальные рабочие ситуации, мы умеем с ними справляться.
— В чатах программистов часто проскальзывает: «Я устал, выгорел, мне надоели ваши ИТ». Как мотивировать сотрудников, чтобы не допускать текучки?
— Любая работа со временем надоедает. И случаи выгорания у нас действительно были, но пока получалось с ними справляться.
Во-первых, желательно изначально подбирать людей, разделяющих ценности команды. У нас есть подходы, которые не всем нравятся, — например, то же открытое решение конфликтов или неопределённость при взятии задачи в работу. Она предполагает, что разработчик готов решать какие-то вопросы самостоятельно, брать на себя ответственность. Мы проверяем это на собеседованиях, во время испытательного срока. Чтобы не терять мотивацию, человек изначально должен соответствовать команде, процессам и культуре, в которой ему предстоит работать.
Во-вторых, с людьми нужно разговаривать. Должны быть регулярные one-to-one-встречи. Не обязательно еженедельные — но желательно общаться с каждым из подчинённых хотя бы раз в месяц. Иначе сложно понять, как они себя чувствуют.
Во время таких встреч проясняется, какие задачи нравятся человеку больше, какие технологии его увлекают. Возможно, в итоге вы предложите ему другую роль, переведёте в другую продуктовую команду или отправите в отпуск.
Например, у меня один разработчик несколько месяцев проработал аналитиком: вместо того чтобы сидеть наедине с кодом восемь часов в день, общался с людьми, писал тексты, письма. Это позволило, что называется, перезагрузиться. Также был опыт с отпуском, и это тоже сработало. Но нужно понимать, что может и не сработать.
Понятие допустимой текучести кадров сильно зависит от продукта и подходов, которые вы практикуете. Если это небольшой сервис, в котором можно разобраться за две недели, компания может набирать людей с улицы за небольшие деньги. И текучка для них — нормальное явление: приток новых сотрудников вполне её закрывает. Для нас это слишком дорогое удовольствие: продукт большой, погружение довольно долгое, и ценность команды очень высока. Сплочённость, понимание с полуслова важны, они дают большой прирост производительности.
Поэтому костяк из десяти человек, который был в начале, работает до сих пор. Это центр передачи наших ценностей и культуры новым сотрудникам. Так что текучку мы стараемся минимизировать.
Как сформировать командные ценности и донести их до каждого
— Как рождается стратегия продукта и как ты доносишь её до разработчиков?
— У наших продуктов есть прямая функциональность: мы должны нормализовать огромное количество данных, правильно их объединить и построить некий эталон всех клиентских данных компании. Для этого есть понятные метрики: скорость, качество, процент обратной ошибки, наше место на рынке и так далее.
Но есть и часть стратегии, которая менее предсказуема. У нас, в отличие от SaaS-сервисов с постоянным ростом клиентской базы, заказчиков немного — несколько десятков. Новые появляются в лучшем случае по одному-два в год, причём требования у всех различаются кардинально. Например, заказчик может прийти с запросом, который по объёму данных или по онлайн-нагрузке больше, чем все наши предыдущие продукты, вместе взятые. И это станет вызовом, предсказать который невозможно. У нас такое случалось.
Из-за того, что команда у нас небольшая, я стараюсь поддерживать близкую коммуникацию с разработчиками и доносить до них бизнес-цели. Не нужно спускать OKR на много этажей: у нас все всё понимают.
При этом у нас не заказная разработка. Там совершенно другая бизнес-модель, и мы по ней работать не хотим. Мы не можем делать всё для всех: нужно сохранять продуктовое ядро, и для этого тоже необходим плотный контакт продакт-менеджмента, пресейла и разработки, чтобы не получилось рассинхрона, чтобы внедрение нового не стало для продукта форком или совершенно новой функциональностью, которая никак не ложится в текущее ядро.
Планирование и управление в команде
— Есть ли у вас какая-нибудь система планирования? Долгосрочное, среднесрочное, квартальное, месячное, на спринт?
— Долгосрочное планирование имеет смысл только в больших проектах. Скажем, у нас есть часть функциональности, которая занимается поиском дубликатов. Это буквально сравнение каждого с каждым на больших объёмах данных и выявление похожих друг на друга по каким-то критериям записей. Задача распределена между несколькими продуктами: часть решается в одном, часть в другом, всё собирается в третьем. Мы справлялись, но в какой-то момент поняли, что, если так пойдёт и дальше, через два года появятся объёмы данных, с которыми мы не будем справляться за разумное время.
Это пример долгосрочного планирования: мы заложили большую цель на несколько лет и шли к ней несколькими командами. Затем это нужно было выкатить так, чтобы у всех клиентов всё продолжало работать нормально. Эта история заняла два с половиной года.
Если же говорить об операционном управлении, в моей команде есть несколько процессов, из которых появляются задачи. Первый — дорожная карта продукта, которая содержит большие фичи или изменения частей продукта, запланированные на год. Задачи формируются на верхнем уровне по кварталам, затем декомпозируются до конкретных заданий и планируются в спринты по доступности ресурса.
Кроме того, чем крупнее становятся наши заказчики, тем чаще они хотят, чтобы нужные им фичи делались максимально быстро. Всё-таки наша конечная цель — зарабатывать деньги. И если заказчик готов нам заплатить за функциональность, которая хорошо укладывается в ядро, — мы это сделаем. Проектная работа сочетается с чётким дедлайном и гибкой roadmap, которая хоть и размечена по кварталам, но довольно свободная.
И наконец, продукт эксплуатируется, есть постоянная обратная связь от продакшена. На её основе мы планируем улучшения, исправление багов (они тоже бывают) и небольшие изменения, которые требуют не больше одного дня на разработку.
— На рефакторинг у вас выделяется отдельное время — например, день в неделю?
— Мы пробовали разные подходы. Когда-то давно выделяли для него специальный день. Это не работало, потому что, с одной стороны, за ним тянулись «хвосты» из предыдущих дней, а с другой — одного дня мало для чего-то крупного, поэтому получалось исправлять только мелочи.
Затем мы внедрили технические релизы как полноценный спринт, когда мы не занимаемся ничем, кроме технического долга и рефакторинга. Так мы отработали год, но в какой-то момент поняли, что не можем выделять на это полноценный спринт, потому что у нас есть дедлайны для обещанного заказчикам. Поэтому планировать рефакторинг и решение техдолга стали в каждом спринте по факту, в зависимости от того, сколько можем выделить ресурсов. Почти в каждый спринт можно взять задачку на день-два. Иногда даже получалось выделить целый спринт.
Как перевести бизнес-задачу на язык разработчиков
— Где грань между задачей, сформулированной на языке бизнеса, и задачей для разработчиков? Как бизнес-задача становится технической?
— Я думаю, это зависит от людей, которые решают задачу. Вернёмся к тому, что у нас команда небольшая, строгого стандарта того, в каком виде должна быть поставлена задача, нет. Есть общее понимание, как описывать задачи, — а дальше всё зависит от конкретного разработчика и аналитика. Если разработчику что-то непонятно, это можно выявить на этапе планирования.
Но при этом внутри задачи обязательно должна быть бизнес-формулировка, то есть объяснение, зачем это вообще делается. Возвращаясь к вопросу о мотивации — любому человеку нужно понимать, для чего он работает, какую пользу и кому его работа принесёт.
Если постоянно делать задачи из разряда «переименуй вот это поле», «добавь такую таблицу» и что-то подобное без понимания, как этим будут пользоваться, для какого процесса это нужно, сколько компания заработает на этом денег, — это демотивирует.
Как проходят спринты
— Давай теперь рассмотрим спринт. Как устроен весь процесс?
— За время нашей работы он сильно эволюционировал. Команда выросла, да и ковид повлиял. До него почти все работали в офисе ежедневно. Были офлайновые синхронизации дважды в неделю: с доской, карточками — всё как у людей.
Во время локдауна мы ушли на полную удалёнку — и до сих пор из неё вернулись не все: часть команды работает удалённо, часть гибридно. В общем, как-то перестроились — хотя до пандемии я считал, что так работать не получится.
Раньше мы рассматривали ряд задач, оценённых аналитиками на предмет того, сколько времени и ресурсов потребуется для их решения, и оформленных в отдельные поля в Jira. Набирали в спринт объём задач, который в него умещается, и расставляли приоритеты по важности, сложности, количеству заказчиков и так далее.
Работали двухнедельными спринтами. Один-два раза в неделю проходили митинги-синхронизации, где мы обсуждали, какие задачи в какой стадии, какие проблемы возникают — и к концу спринта подходили с чётким пониманием, где что не получилось. Дальше спринт заканчивался, выпускался релиз, проходило регрессионное тестирование сборок для конкретных заказчиков. Потом всё уходило в саппорт на передачу билдов в эксплуатацию.
Обратную связь из-за того, что заказчики у нас крупные, мы получали позже. Дальше была ретроспектива: после каждого спринта мы собирались и обсуждали, что плохо, что хорошо, что меняем.
А потом случилась пандемия. Команда была сработавшаяся, так что все ритуалы синхронизации я убрал полностью. Люди понимали друг друга без слов, работали без сбоёв, ретроспективы делали раз в два спринта.
Проблемы наступили, когда мы начали расти. Появлялись новые люди, и ранее существовавшее взаимопонимание без дополнительных ритуалов начало ломаться. И тогда мы пришли к мини-командам, которые работают над конкретными фичами и выстраивают вокруг них процессы.
У нас было два варианта. Если ребята давно друг друга знали, они могли обходиться без дополнительных ритуалов. Но если, что случалось чаще, в команде были новенькие, требовалась синхронизация, чтобы быстрее получать от них обратную связь и помогать им.
Ретроспективы теперь — больной для нас вопрос. Мы их давно не проводим. Пробовали несколько вариаций формата, но пока не поняли, как его изменить. Договорились делать ретроспективы вокруг конкретных кейсов. Допустим, у нас что-то пошло не так в работе над какой-то фичей, во взаимодействии, процессе. Собираем команду до 10 человек из тех, кто в теме, и разбираем этот кейс.
— А покер раскладываете, когда оцениваете объём задач? Есть какой-то формализованный процесс или на глаз прикидываете?
— Покер не раскладываем, но планирование заметно эволюционировало. Мы пришли к тому, что собирать всех на одно большое планирование особо не нужно. Мы оцениваем задачи в асинхронном процессе. Он выглядит как некий общий чат, куда поступают задачи на оценку. Выбирается один конкретный оценивающий, но при этом присутствуют все, кто оценивает задачи. Они видят оценки и готовы их скорректировать.
После оценки идёт планирование — примерно так же, как и раньше: спринт наполняется, исходя из доступных ресурсов, из оценок и приоритетов, которые сохранились.
Как оценить, справилась ли команда с задачей
— Что происходит дальше? Есть ли какие-то критерии, по которым вы понимаете, что задача выполнена качественно. Когда она считается принятой? Тесты, код-ревью, ещё что-то?
— Полтора года назад код-ревью у нас вообще не было: они не требовались, так как все разработчики были довольно опытными. С ростом команды начали делать код-ревью по потребностям. А потом поняли, что нужен постоянный процесс. Сейчас есть отдельный статус в Jira: назначается ревьюер, он делает код-ревью задачи, и только после этого она резолвится.
У каждой задачи есть закрывающий тестировщик, который дополняет кейсами наши автотесты. Тестирование автоматизировано. Так как мы работаем с данными, у нас собственный фреймворк по data-driven testing. Нужно создать некое начальное и конечное состояние данных, какие-то операции между ними — то есть кейс. Гоняются кейсы фреймворком на разных уровнях — как на сервисном, так и на полноценном интеграционном, когда поднимаются два или три наших продукта, которые друг с другом взаимодействуют.
Понятно, что условия перехода задачи в резолв — это отсутствие упавших тестов. Тестов у нас довольно много — десятки тысяч. Дальше происходит работа совместно с тестировщиком: смотрим, какие тесты упали правильно, какие неправильно. Если есть проблемы, задача возвращается в разработку.
— Можно описать разработку фичи на конкретном примере?
— Например, есть задачи, которые приходят из саппорта и связаны с проблемами перформанса. Предположим, наш сервис стал медленнее отвечать на запросы. Что делать?
Мы выстроили отдельный процесс и сделали несколько классных фич, которые помогают в этом разбираться. Продукт при появлении триггеров — допустим, увеличении времени ответа по какому-то методу в API — автоматически включается в сбор профилировки. Запускается Flight Recorder.
Параллельно мы собираем nmon, по которому можно понять состояние процессора, диска и других составляющих системы. Все эти метрики собираются, инженер саппорта приходит с ними к разработчику, а тот смотрит. Дальше возможны два сценария.
Первый: очевидная проблема, которую можно пофиксить за 10 минут. Допустим, читаем из базы три раза одно и то же.
Второй, более сложный: когда проблема понятна, но её исправление требует большего ресурса. Например, рефакторинг целого модуля. Сразу это делать сложно, и мы планируем. Смотрим, встречалась ли подобная проблема у других заказчиков. Прогнозируем, с какой периодичностью она может повторяться в будущем: если часто, то можем запланировать её в ближайший спринт. Следующий этап — планирование разработки и непосредственно разработка.
Но как понять, решена ли проблема? Самый простой вариант — выкатить в продакшен и ждать. Но у нас есть четыре разных стресс-стенда под разные базы данных, на которых мы пытаемся повторить усреднённую нагрузку и усреднённое состояние данных наших заказчиков.
Мы смотрим на метрики, пытаемся воссоздавать сложные ситуации с помощью chaos engineering, увеличивая задержку ответа от базы данных или изменяя что-то в параметрах железа в процессе работы продукта, и так далее.
Как влиться в команду: советы новичкам
— Наверное, последний вопрос. Приходит новый человек в команду. Что бы ты ему порекомендовал делать, как себя вести, чтобы быстро освоить процессы, инструменты, понять проект?
— По результатам наших исследований, проб, ошибок и прочего мы составили специальный документ для новичков, который называем квестом. Он состоит из набора пунктов и решает несколько задач.
Первая часть — пошаговое ознакомление с некоторым набором общих принципов и процессов в компании. Например: как оформлять заявление на отпуск и к кому с ним идти, как отмечать больничный, какие у нас культурные особенности, какие продукты мы делаем и зачем, как их использует бизнес и зачем, какие у нас есть команды и как с ними взаимодействовать и так далее.
Вторая часть — погружение в конкретный продукт, которым человек будет заниматься. У этого подквеста есть общая часть, а подробности зависят от роли новичка в команде. Технические детали даны по пунктам, чтобы человек понимал: шаг 1 — прочитать статью, шаг 2 — настроить идею, шаг 3 — запросить доступ в GitLab, клонировать такой-то репозиторий, сбилдить проект, прогнать тест. На этом погружение разработчика в квест заканчивается.
У разработчиков самый короткий квест. У аналитиков, тестировщиков, саппорта ещё несколько частей, потому что в их работе есть особенности.
Правда, со временем мы поняли, что на каком-то этапе разработчикам становится скучно, и они говорят: «Дайте уже реальную задачку, дайте код потрогать. Я устал ваши статьи читать, видео смотреть и вот это всё».
Кроме того, сколько процессы ни описывай, нет лучше способа освоиться, чем взять реальную задачку. Но точно нужен ментор, к которому можно в любой момент прийти с вопросом, если что-то вдруг не получится.
Задачки стараемся подобрать так, чтобы на первых этапах они были из разных частей проекта, чтобы можно было потрогать разные кусочки. Двигаемся, естественно, от простого к сложному. Так что особых сложностей с адаптацией не возникает. В конце концов, мы ведь команда, не так ли?
