GreenCore 
Тендеры и лиды
Информация
Разговор про то, как CTO принимает технические решения, почти всегда скатывается в крайности. Либо это образ «архитектора сверху», который утверждает всё — от базы данных до фреймворка, либо противоположность: полная децентрализация, где команды делают всё сами. В реальности ни одна из этих моделей не работает на дистанции, особенно в российском IT, где компании растут быстрее, чем успевают выстроить управленческие практики.
Если упростить до сути, современная инженерная архитектура — это уже не столько про систему, сколько про набор принятых решений и причин, почему они были приняты. Это прямо фиксируется в исследованиях по software architecture: сама архитектура всё чаще определяется не как схема, а как совокупность решений и их обоснований . И вот здесь появляется ключевая роль CTO — не «решать всё», а выстраивать систему, в которой решения принимаются правильно.
Проблема в том, что в большинстве компаний такой системы просто нет. Решения принимаются ситуативно, через авторитет, опыт или давление сроков. Иногда через «самый громкий голос в комнате». Иногда — через то, что «мы уже так делали». И это нормально на ранней стадии, но критично ломает компанию на этапе роста.
На российском рынке это особенно заметно. Очень много CTO выросли из сильных разработчиков, но не из архитекторов систем принятия решений. В итоге возникает перекос: техническая экспертиза есть, а управленческой модели — нет. Решения принимаются, но не масштабируются.
То, как это должно работать, на самом деле давно описано, но редко применяется в чистом виде. В нормальной системе CTO сначала определяет не «что выбрать», а кто принимает решения, какие решения централизованы, а какие — нет.
Это звучит очевидно, но именно здесь чаще всего происходит сбой.
Исследования и практика показывают, что ключевая ошибка — либо всё замыкается на CTO (и он становится bottleneck), либо всё отдаётся командам (и начинается хаос) . Баланс достигается только через чёткое разделение типов решений.
Крупные, необратимые решения — архитектура, выбор платформы, стандарты — остаются в зоне архитектурного контроля. Локальные и обратимые — делегируются командам. И это не про демократию. Это про экономику.
Потому что цена ошибки в архитектуре несоизмерима с ценой ошибки в локальной реализации, но даже если разделить зоны ответственности, это ещё не система. Это просто договорённость.
Настоящая система появляется тогда, когда решения начинают фиксироваться и переиспользоваться.
Здесь в игру вступают такие вещи, как Architecture Decision Records, RFC-процессы, архитектурные ревью. И это не бюрократия ради бюрократии. Это способ не принимать одни и те же решения по десять раз.
В индустрии это давно воспринимается как база. Например, в инженерной практике подчёркивается, что архитектурные решения должны регулярно документироваться и пересматриваться, потому что сами условия постоянно меняются .
Без этого компания начинает жить в режиме «постоянного изобретения велосипеда». Теперь важный момент, который почти никто не проговаривает напрямую. Система принятия решений — это не про технологии. Это про власть и ответственность. Кто может сказать «нет». Кто несёт последствия. Кто имеет право менять стандарты.
Если это не определено, возникает то, что называют «shadow architecture» — когда решения принимаются неформально, мимо процессов . И это одна из самых дорогих проблем в IT-компаниях. Потому что формально система есть, а фактически её обходят.
В практике GreenCore это выглядит чуть менее академично, но гораздо ближе к реальности.
CTO в компании GreenCore не строит систему вокруг себя. Он строит её вокруг контекста решений.
Каждое решение рассматривается через три слоя:
Это звучит просто, но именно это убирает 80% лишних обсуждений, потому что большинство технических споров в командах — это не про технологии. Это про разные представления о том, что важно. Когда контекст зафиксирован, решения принимаются быстрее и чище.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13492 тендера
проведено за восемь лет работы нашего сайта.
Вторая важная вещь, которую внедряет IT-компания GreenCore — это отказ от иллюзии «идеального решения».
В классической инженерной культуре часто ищут лучший вариант. На практике CTO работает с другим критерием: достаточно хороший в текущем контексте. Это критично в условиях российского рынка, где:
Попытка найти «идеальное» решение почти всегда означает потерю времени.
Третий слой — это архитектурная коммуникация. Одна из самых недооценённых проблем — люди просто по-разному понимают систему.
И здесь помогают формальные подходы вроде TOGAF или ArchiMate, но не как «стандарты ради стандартов», а как общий язык. Они позволяют сократить количество споров, которые возникают просто из-за разного понимания архитектуры .
В GreenCore это решается прагматично: фиксируется минимальный набор артефактов, который обязателен для всех. Не больше. Но и не меньше. Есть ещё один момент, который становится особенно важным на масштабе.
Сильный CTO перестаёт быть источником решений. Он становится дизайнером системы, в которой решения принимаются без него. И это, пожалуй, главный маркер зрелости. Потому что если каждое важное решение требует участия CTO, компания уже упёрлась в потолок.
Если CTO полностью устраняется, возникает хаос. Задача — создать систему, где его участие нужно только в критических точках.
Интересно, что даже на уровне практиков это подтверждается. В обсуждениях инженеров часто подчёркивается, что реальные архитектурные решения принимаются командами, а роль CTO — задать рамки и обеспечить согласованность, а не контролировать каждую деталь . И это хорошо совпадает с тем, как это работает в зрелых компаниях.
Если собрать всё вместе, становится очевидно, что система принятия технических решений — это не про инструменты и не про фреймворки.
Это про три вещи:
С точки зрения GreenCore, ключевая ошибка большинства CTO в том, что они пытаются принимать правильные решения. Вместо того чтобы выстроить систему, в которой неправильные решения становятся маловероятными. Это принципиально разные подходы.
Первый масштабируется плохо. Второй — становится конкурентным преимуществом.
Потому что в современном IT скорость и качество решений — это уже не технический вопрос. Это вопрос того, насколько хорошо у вас устроена сама система мышления внутри компании.
И это принципиально разные подходы.
