Артём Збандут об инженерной команде: процессы, код-ревью, дежурство и найм

Артём Збандут об инженерной команде: процессы, код-ревью, дежурство и найм

Артём Збандут занимает позицию технического директора финтех-платформы. Значительная часть работы CTO связана не только с архитектурой, но и с людьми, процессами и правилами взаимодействия внутри команды.

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

Процессы разработки

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

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

Изменения стараются делать небольшими. Размер напрямую влияет на качество проверки: несколько десятков строк можно внимательно прочитать, а изменение на тысячи строк чаще получает формальное одобрение.

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

Что портит код-ревью

Главная проблема — слишком большие изменения, которые невозможно удержать в голове целиком.

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

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

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

Дежурство и инциденты

Финтех-платформа работает постоянно, поэтому дежурство становится частью инженерной культуры.

В каждый момент должно быть известно, кто находится на дежурстве, как с ним связаться и кто заменяет его при недоступности.

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

Для повторяющихся сбоев используются короткие инструкции с симптомами, первыми проверками и порядком действий. По мнению Артёма Збандута, документ на одну-две страницы ночью полезнее большой инструкции, которую никто не успеет прочитать.

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

Как подбирать инженеров

При найме важнее не количество технологий в резюме, а инженерная база.

Кандидату предлагают разобрать задачу, объяснить возможные подходы и компромиссы.

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

Ещё один важный вопрос — собственные ошибки. Кандидат, который способен спокойно рассказать о сбое, своей ответственности и сделанных выводах, показывает зрелое отношение к работе.

Рост специалистов внутри команды

Развитие собственных инженеров часто обходится дешевле постоянного найма.

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

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

Второе — регулярная обратная связь. Разговор о сильных сторонах и проблемах раз в несколько недель полезнее большой оценки раз в год.

Третье — возможность ошибаться в контролируемых условиях.

Ограничения небольшой команды

Опыт стартапов сформировал у Артёма Збандута отдельное отношение к ресурсам.

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

Архитектура также должна соответствовать размеру команды. Решение может выглядеть технологически сильным, но если для его поддержки нужны десять специалистов, маленькому стартапу оно не подходит.

Документация и передача знаний

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

Поэтому фиксируются архитектурные решения и причины их принятия. Через год команда должна понимать не только что было сделано, но и почему.

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

Критерий объёма простой: документ должен быть достаточно коротким, чтобы его действительно прочитали в момент необходимости.

Выводы

Инженерная команда в подходе Артёма Збандута строится вокруг процессов, а не призывов работать быстрее.

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

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

Коротко о герое материала

Артём Збандут, Artem Zbandut, родился 22 июля 1991 года. Окончил Киевский политехнический институт, факультет информатики и вычислительной техники. Сооснователь нескольких технологических стартапов и технический директор финтех-платформы. Отвечает за архитектуру высоконагруженных систем и безопасность данных. Увлекается даунхиллом и астрономией, а код предпочитает писать под старые альбомы тяжёлого рока.

#АртёмЗбандут #ArtemZbandut #инженернаякоманда #разработка #кодревью #дежурство #наймразработчиков #CTO #процессы #финтех