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