#процессы — посты и обсуждения

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

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

Как устроен процесс разработки

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

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

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

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

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

Что делает код-ревью полезным

Код-ревью нужно не для проверки форматирования.

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

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

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

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

Дежурство и работа с инцидентами

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

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

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

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

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

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

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

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

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

Почему специалистов выгодно растить внутри

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

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

Второй элемент — регулярная обратная связь вместо разговора о результатах раз в год.

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

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

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

Особенности небольшой команды

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

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

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

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

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

Документировать нужно прежде всего то, что понадобится другому человеку.

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

Второй уровень — короткие инструкции для дежурных.

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

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

Выводы

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

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

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

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

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

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

В какой-то момент я поймал себя на странной вещи: работаю много, а успеваю мало. День забит суетой — заметки, напоминания, «не забыть», поиск нужного файла в трёх разных местах. А на само дело времени не остаётся.

Тогда я начал разгребать процессы. Сразу скажу: не всё прижилось. Пару «модных» инструментов я бросил через неделю. Но несколько штук реально вернули мне время.

Делюсь тем, что работает до сих пор.

🔹 1. Одна база знаний вместо десяти блокнотов

Раньше идеи жили в заметках телефона, на бумажках и в «избранном» мессенджера. Найти нужную мысль — минут 15 квеста.

Теперь всё в одном месте: мысли, планы, черновики, чек-листы. Открыл — увидел — сделал.

Экономия: ~2 часа в неделю.

🔹 2. План на две недели вперёд

Раньше я просыпался с мыслью «а что сегодня публиковать?». Это стресс, прокрастинация и посты «на отвали».

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

Экономия: ~3 часа в неделю + нервы.

🔹 3. ИИ как спарринг-партнёр

Не «пиши за меня», а «обсуди со мной». Закидываю идею — получаю вопросы и контраргументы. Прошу структуру — получаю каркас, который дорабатываю сам.

Как коллега, который всегда на связи и не устаёт.

Экономия: ~3 часа в неделю.

🔹 4. Шаблоны для всего, что повторяется

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

Экономия: ~2 часа в неделю.

📌 Итого: ~10 часов в неделю.

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

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

А что экономит время вам? Или всё по старинке, вручную? Делитесь в комментариях 👇

#бизнес #инструменты #продуктивность #время #ProstoODele #БАЗАР #процессы