Posts Tagged: Генри Бабенко

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

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

«Если есть возможность уделить время семье вместо работы, я выберу семью. А чтобы это стало возможным, команда должна работать не дольше, а умнее».

Как устроены процессы без ночных созвонов

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

Асинхронность вместо 24/7

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

Если кто-то не в сети — информация его дождётся. В итоге пропадает иллюзия, что «кто первым ответил в полночь, тот и молодец».

Автоматизация как защита личного времени

Автотесты, мониторинг, отлаженный CI/CD убирают необходимость «дежурить у кнопки». Процессы работают сами, инженеры не сидят ночами, переживая за каждый релиз.

В одном из проектов мы полностью перестроили цикл релиза: документация генерируется прямо из кода, автотесты прогоняются в CI, а релизная система позволяет сделать откат. Раньше релиз означал ночные правки и созвоны; теперь — план в таск-трекере и проверяемый процесс. По нашим измерениям команда экономит до 10 часов в неделю на рутине.

Малые автономные команды

Оптимальный размер — 6–8 человек. У каждого своя зона ответственности, роли не размыты, решения принимаются быстрее. Такая модель не требует лишних совещаний и убирает риск, что «без одного человека всё встанет».

Онбординг без стресса

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

Какие результаты это дает

1. Ни одного ночного релиза. Автоматизация позволяет выкатывать изменения в плановом режиме.
2. До 10 часов экономии в неделю. Благодаря автодокументации и CI/CD команда меньше тратит на рутину.
3. Рост самостоятельности. Команда работает без микроменеджмента — и это повышает ответственность.
4. Прозрачные дедлайны. Риски фиксируются заранее, а не в момент сдачи.

Пример: на одном проекте релиз раньше означал созвоны в 23:00 и «ручное» тестирование. Мы внедрили автотесты, генерацию документации из кода и скрипты отката. Итог — релизы проходят днём, а сотрудники спокойно планируют вечер с семьёй.

Почему это важно для бизнеса

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

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

Чек-лист: как уйти от токсичной культуры переработок

• Настройте правила асинхронной коммуникации.
• Внедрите CI/CD и базовые автотесты.
• Сократите команду до 6–8 человек, распределите зоны ответственности.
• Подбирайте бадди для онбординга.
• Подсчитайте экономию времени — и покажите цифры бизнесу.

Человеческий фактор — ключевой

Многие забывают: инженеры — не машины. Если людям комфортно, они быстрее растут. Я вижу это каждый раз: джуниоры за год становятся уверенными мидлами, мидлы вырастают до опытных сеньоров.

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

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

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

Контакты

Меня зовут Генри Бабенко. Я техлид и IT-эксперт с многолетним опытом. Специализируюсь на создании долгосрочных, поддерживаемых IT-решений, автоматизации бизнес-процессов и построении эффективных команд разработки. Моя философия строится на прозрачности, практичности и ориентации на реальные результаты, а не на «хайп». Я помогаю компаниям оптимизировать затраты, а разработчикам — расти профессионально, избегая карьерных тупиков.

Телеграм-канал: https://t.me/henryhdev

#IT #разработка #управлениепроектом #техлид #управлениекомандой #оптимизация

Как сформировать эффективные команды разработки, масштабировать IT-системы и почему большие отделы мешают работать — объясняет техлид международной IT-компании Генри Бабенко.

Почему не стоит нанимать большую команду?

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

Программисты эффективнее работают в небольших командах (6–10 человек), построенных вокруг одной цели или конкретного направления бизнеса. В такой команде каждый знает свои задачи, легко взаимодействует с коллегами и участвует в принятии решений. В большой группе теряется оперативность из-за сложной структуры и лишних уровней управления. А программисты становятся менее мотивированными, превращаясь в «винтики», не понимающие своей реальной ценности.

Как построить «Dream Team»

Небольшая команда — это возможность создать «Dream Team», где все участники эффективно дополняют друг друга, хорошо ладят и готовы к совместной работе.

Мои принципы построения команды

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

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

Еще один плюс небольших команд — это снижение рисков, связанных с уходом сотрудника, «бас-фактором». Идеальная цель — построить такую систему, которую сможет поддерживать любой новый специалист, буквально человек с улицы. Вам не нужны незаменимые сотрудники. Даже если кто-то уйдет или просто будет недоступен некоторое время (например, в отпуске или на больничном), команда продолжит стабильно работать. Я сам строю процессы так, чтобы работа над проектом, в котором я участвую, могла продолжаться, даже если меня нет рядом.

Пример из практики

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

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

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

В чем эффективность подхода

Так почему небольшие команды работают лучше?

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

Другие посты в личном канале Генри Бабенко в телеграм: t.me/henryhdev