Технический руководитель Генри Бабенко — о том, как создавать IT-системы, которые работают годами, а не рушатся через год.
Почему многие IT-системы перестают работать уже через год после запуска? Генри — инженер и архитектор систем с более чем 15-летним опытом — считает, что причина не в технологиях, а в подходе к работе. Он знает, как создавать проекты, которые выдерживают изменения и остаются эффективными на протяжении многих лет.
Что пошло не так?
«Чаще всего решения, сделанные «по-быстрому», не жизнеспособны в долгосрочной перспективе. Сегодня клиент видит магию, а завтра система становится сложной в поддержке из-за ограничений архитектуры. Любая доработка оказывается дороже, чем сэкономленные деньги», — говорит Генри.
Наиболее частые проблемы:
- архитектура продумана наспех;
- код плохо масштабируется;
- документация отсутствует или бесполезна;
- команда разобщена и дезорганизована;
- сложность погружения новых сотрудников.
Что действительно работает?
Генри предлагает другой подход — системный, прозрачный и ориентированный на людей.
Я проектирую системы так, чтобы их мог поддерживать разработчик «с улицы», без долгих объяснений. Это требует времени на старте, но экономит компании до 50% расходов в будущем».
В этом помогают ключевые принципы Генри.
- Долговечная архитектура
Не гнаться за модными технологиями, а строить понятную, устойчивую структуру. Если архитектура не продумана с самого начала, последующие изменения будут дороже. Структура и код должны быть в первую очередь поняты человеку. Даже если это немного увеличивает расходы на серверную инфраструктуру.
- Небольшие команды с чёткими ролями
Оптимальный размер команды — 6–10 человек. Каждый знает свою роль и не мешает друг другу. Участники команды должны быть вовлечены в каждый этап создания своей части проекта. Это влияет на ответственность каждого за качество и скорость разработки новых фичей.
- Простые инструменты и автоматизация рутины
Любая автоматизация снижает риск ошибок и экономит время. Например, автоматизированное тестирование, сборка и деплой кодовой базы в продакшн — поможет избежать человеческого фактора и избавит разработчиков от непрофильной работы.
- Менторство и культура обучения
В команде должны быть выстроенные процессы онбординга. На время интеграции человеку назначается наставник, который помогает быстрее погружаться в рабочие процессы. У остальных должна быть понятная система роста, ведь профессионал всегда имеет запрос на развитие. У тимлида должны быть полномочия помогать с такими запросами.
- Фокус на людях, а не на технологиях
Процессы и технологии в команде должны отталкиваться от самих людей. Если у вас вся команда пишет на одном языке программирования — то эффективнее будет взять этот язык, чем пытаться писать на другом, даже более современном. Бизнес-заказчикам должно быть понятно как доносить свои пожелания. Все задачи должны иметь чёткий прогнозируемый флоу, гибко настроенный под команду.
Что разрушает ИТ проекты?
«Проекты проваливаются, потому что их создатели не думают о будущем. Они сосредоточены на краткосрочном результате, а не на устойчивости».
Основные ошибки:
- Отсутствие долгосрочной цели. Отсутствие планов на спринт, квартал, год.
- Недостаток или полное отсутствие документации и тестов.
- Переоценка важности конкретных людей. Потакание опыту старожил (которые лучше всех “знают проект”) в ущерб атмосфере в команде и проблемам с софт-скиллами.
- Неверный подход к назначению ролей. Например, лидом иногда ставят хорошего разработчика, который начинает меньше писать код и тратит время на менеджмент.
Но если проект нужен уже сейчас?
Например, для обкатки бизнес идеи, а времени на полноценную разработку и выстраивание команд нет.
Надо понимать, что сами по себе быстрые решения допустимы, когда нужно показать демо-версию или MVP — но важно понимать, что в MVP нет полноценной архитектуры. Уже следующая версия должна проектироваться на основе тщательно проработанного технического задания, с учётом выбранной архитектуры и ключевых бизнес-требований, основанных на долгосрочных целях и уже известных планах. Иногда такая версия может иметь более скромный функционал по сравнению с MVP, зато обеспечит надёжный «скелет» системы, который позволит удобно развивать и поддерживать проект как минимум на ближайший год, не превращая кодовую базу в хаотичное легаси.
Чек-лист: 5 вопросов перед стартом проекта
Перед запуском команда должна спросить у себя:
- Сможет ли поддерживать систему тот кто придёт через 2–3 года?
- Погрузиться ли новый человек в кодовую базу без объяснений?
- Есть ли документация, которую реально читают?
- Как быстро можно развернуть проект с нуля?
- Может ли команда работать без “ключевого” сотрудника?
Если на любой из вопросов нет внятного ответа — ваш проект под угрозой.
Генри — инженер со своим подходом
Генри не просто пишет код — он выстраивает процессы. За его плечами:
- опыт создания собственной компании разработки веб решений;
- управление удаленными командами;
- опыт менторства и наставничества для программистов;
- успешные проекты, живущие дольше своих конкурентов;
«Программирование — это искусство, а не рутина. Я делаю так, чтобы после моего ухода проект продолжал отлажено работать».
Вместо хайпа — честная работа
Генри — сторонник здравого, прозрачного подхода. Его опыт будет полезен:
- руководителям команд — чтобы настраивать процессы и уменьшать скрытые издержки;
- разработчикам — чтобы вырасти внутри команды;
- стартапам — чтобы не тратить бюджет на «волшебные коробки» без содержания;
Он открыт к диалогу, готов делиться практиками, выступать и консультировать.
Контакты для связи
Сайт — henrydev.me
ТГ-канал — t.me/henryhdev
Другие статьи от Генри Бабенко:
Комментариев пока нет.