Мы слишком много говорим о технологиях. И слишком мало — об инженерных системах.
За последние годы я все чаще замечаю одну закономерность.
Когда в компании возникают проблемы с разработкой, обсуждение почти всегда начинается одинаково.
«Нам нужна новая архитектура.»
Или:
«Пора переходить на микросервисы.»
Или:
«Давайте внедрим AI — он ускорит разработку.»
Технологии становятся первой гипотезой практически для любой проблемы.
Но за годы работы с крупными цифровыми платформами я пришла к выводу, что технологии редко являются настоящей причиной успеха или неудачи.
Чаще всего проблема находится гораздо глубже.
Когда микросервисы не помогают
Представьте ситуацию.
Бизнес недоволен скоростью вывода новых функций.
Каждый релиз занимает месяцы.
Разработчики перегружены.
В тестировании постоянно находятся критические ошибки.
Архитекторы предлагают очевидное решение:
Нужно разделить монолит.
Команды начинают масштабную программу трансформации.
Через год появляется несколько десятков сервисов.
Появляются Kubernetes, Kafka, Service Mesh...
Но скорость бизнеса почти не меняется.
Почему?
Потому что монолит был не главной проблемой.
Главной проблемой была инженерная система.
Что на самом деле тормозит разработку
За последние годы я чаще сталкивалась с другими причинами.
Архитектура существует отдельно от бизнеса
Команды проектируют красивые технические решения.
Но никто не отвечает на вопрос:
Как это повлияет на скорость развития продукта через два года?
Архитектура становится самоцелью.
Требования приходят слишком поздно
Разработка начинается тогда, когда половина решений уже принята.
Аналитика превращается в передачу документов.
Вместо совместного поиска лучшего решения команда начинает обсуждать ограничения уже готовой идеи.
Процессы не помогают принимать решения
Очень часто слышу фразу:
У нас слишком много процессов.
Но проблема обычно не в количестве процессов.
Проблема в том, что процессы отвечают на вопрос:
Кто что должен сделать.
Вместо вопроса:
Как нам быстрее принимать правильные решения?
Команды работают изолированно
Архитекторы думают отдельно.
Аналитики отдельно.
Разработка отдельно.
Эксплуатация отдельно.
В результате появляются локально правильные решения.
Но система в целом становится сложнее.
Где здесь AI?
Последние два года AI стал практически обязательной темой любой технологической конференции.
И это здорово.
Мы тоже активно экспериментируем с использованием AI в инженерных процессах.
Например, для анализа бизнес-требований, подготовки вопросов к требованиям и ускорения работы аналитиков.
Но есть важное наблюдение.
AI способен ускорить работу команды.
Он не способен заменить инженерное мышление.
Если требования противоречивы, AI лишь быстрее обработает противоречия.
Если архитектурные решения принимаются без учета стратегии продукта, AI не исправит направление.
Если команда не умеет принимать решения совместно, AI не построит культуру взаимодействия.
Технология усиливает систему.
Она не заменяет ее.
Что я называю инженерной системой
Со временем я перестала воспринимать разработку как набор отдельных процессов.
Для меня инженерная система — это единый механизм, где взаимосвязаны:
- архитектура;
- процессы;
- инженерная культура;
- качество требований;
- взаимодействие бизнеса и разработки;
- инструменты автоматизации;
- AI;
- принципы принятия решений.
Если хотя бы один элемент начинает работать против остальных, страдает вся система.
Почему CTO отвечает не только за технологии
Мне кажется, роль CTO постепенно меняется.
Еще несколько лет назад главным ожиданием было:
обеспечить стабильную работу технологий.
Сегодня этого недостаточно.
CTO становится архитектором инженерной организации.
Его задача — создавать среду, в которой:
- решения принимаются быстро, но осознанно;
- архитектура помогает бизнесу развиваться, а не ограничивает его;
- процессы снижают неопределенность, а не создают бюрократию;
- AI становится инструментом повышения эффективности, а не модным экспериментом;
- команды понимают не только что делать, но и зачем.
Вместо вывода
Я все чаще ловлю себя на мысли, что главный показатель зрелости инженерной организации — это не количество используемых технологий.
И даже не скорость релизов.
А ощущение спокойствия.
Когда команда понимает цели.
Когда архитектурные решения принимаются системно.
Когда процессы работают на людей, а не наоборот.
Когда технологии перестают быть источником постоянных проблем и становятся надежной опорой для развития бизнеса.
Возможно, именно это и есть настоящая задача современного CTO — не просто выбирать технологии, а строить инженерные системы, в которых технологии, процессы и люди работают как единое целое.