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

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

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

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

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

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

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

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

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

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

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

Дежурство и передача знаний

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

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

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

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

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

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

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

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

Рост внутри команды

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

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

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

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

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

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

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

Документация и договорённости

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

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

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

Частые вопросы

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

Почему размер изменений важен? Короткую правку можно проверить глубоко. Большой пакет изменений почти неизбежно ухудшает качество ревью.

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

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

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

Выводы

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