Инженерный перфекционизм — штука дорогая. Иногда ценой в бизнес. Технический директор может месяцами шлифовать архитектуру, спорить о паттернах и строить инфраструктуру, которой восхитятся коллеги на конференциях. А в это время компания принимает решения, которые он не понимает и на которые не влияет. Код безупречен. Коммерческий результат — чужая головная боль.
Сооснователь и CTO международной IT-компании с 3500 сотрудников однажды сказал: «Образование не спасает проекты. Спасает методология. Но методология без разносторонних знаний — просто шаблон». У него два диплома — системного инженера и экономиста предприятия. В начале нулевых это выглядело странно: инженеры пишут код, экономисты считают деньги. Следующие двадцать лет он доказывал, что разделение было искусственным с самого начала.
Почему технический гений не спасает бизнес
Большинство инженерных организаций воспринимают структуру как упражнение с оргсхемой: квадратики, линии, кто кому подчиняется. Опытный CTO смотрит на это как на распределённую систему: точки отказа, избыточность, задержки, пропускная способность. Когда у него в прямом подчинении оказалось двадцать разработчиков, система сломалась. Не потому, что люди были плохи. Архитектура не выдержала.
Решение оказалось структурным. Он выстроил управленческую архитектуру с многоуровневой ответственностью: project-менеджеры, delivery-менеджеры, их руководители. Каждый уровень — с чётко определёнными полномочиями и протоколами взаимодействия. Параллельно создал слой мотивации: цели, привязанные к измеримым результатам, индивидуальные матрицы развития для каждой инженерной роли, систему управления ресурсами, способную выдержать десятки одновременных клиентских проектов.
Разница между такой системой и привычной оргсхемой — как между монолитом и микросервисами. Когда что-то ломается в одном месте, всё остальное продолжает работать. Уходит delivery-менеджер — проект не теряет накопленные знания, потому что знания хранит система, а не память одного человека. «Любая организация — это люди, — говорит он. — А где люди, там человеческий фактор. Что можно сделать — построить систему, которая снижает ущерб и поднимает нижнюю планку».
Именно этот подход часто становится темой для стратегических сессий в российских компаниях: как перейти от героического менеджмента к воспроизводимой управленческой модели.
Фиксированная цена как инженерная дисциплина
Одно из самых важных решений в разработке на заказ реже всего обсуждается в инженерных кругах: как вы оцениваете работу. Контракты time-and-materials перекладывают риски расписания и содержания на клиента. Fixed-price переносит их на исполнителя. Большинство компаний считают это вопросом продаж и юристов. Наш герой рассматривает его как инженерную задачу.
Он построил внутренний центр компетенций по fixed-price-проектам — по сути, систему оценки рисков. Отправной точкой стал анализ провалов: каждый проект, вышедший за бюджет, каждый спор об объёме работ, каждая оценка, рухнувшая из-за незадокументированных условий. Он искал не причину конкретного сбоя, а организационное условие, которое делало этот класс ошибок повторяющимся.
Пробел нашёлся один и тот же: не было формального механизма перевода ожиданий клиента в инженерные обязательства на уровне, который обе стороны могли бы считать обязывающим. Оценки держались на допущениях, которые никто не записывал. Объём определялся на уровне продажи, а не на уровне реализации. Когда условия менялись по ходу проекта, не существовало процедуры оценки того, что именно изменилось и как это влияет на исходные договорённости.
Двойное образование — системная инженерия плюс экономика предприятия — дало необычную оптику. Большинство технических руководителей видели проблему доставки. Он увидел проблему ценообразования. Каждая оценка — это ставка. Вопрос в том, знает ли организация, на что она ставит, и правильно ли оценила неопределённость.
Центр компетенций заработал на четырёх механизмах:
- формализованное определение объёма на уровне реализации;
- задокументированные допущения оценки;
- структурированное разрешение споров по объёму в середине проекта;
- сертификация контрольных точек, дающая клиенту и команде общую картину прогресса на каждом этапе.
Система стабилизировалась годами. Её пересматривали после каждого крупного проекта, который устраивал ей стресс-тест. До внедрения «фиксированная цена» означала талантливых инженеров, работающих против дедлайна с индивидуально согласованными допущениями. После — появился повторяемый процесс: единые модели оценки, общие протоколы определения объёма, прописанные пути эскалации. Географическая распределённость команд перестала быть переменной качества.
Коммерческие последствия оказались не менее важны, чем операционные. Когда команда оценивает на основе задокументированных допущений и определяет объём на уровне реализации, цена отражает реальность. Результат: компания перестала выигрывать тендеры, на которых потом теряла деньги; клиенты получали обязательства, за которые команда могла отвечать. Характер отношений менялся с первой контрольной точки.
Какие услуги продавать: тест на ликвидность
Экономическое мышление CTO ярче всего проявляется в том, как он решает, какие услуги компания будет предлагать. Вопрос не «Можем ли мы это построить?» — с 3500 инженеров ответ почти всегда «да». Вопрос в том, заплатит ли рынок с такой маржой, которая оправдает инвестиции в людей, инфраструктуру и накопление экспертизы.
Он называет такие услуги «ликвидными» — термин из финансовых рынков. У ликвидных услуг стабильный спрос, защищённое ценообразование и возможность стандартизировать delivery в разных командах и регионах. В портфеле компании это разница между устойчивым ростом и дорогой компетенцией, которая выигрывает несколько впечатляющих контрактов, но так и не масштабируется.
Этот фильтр определил техническую экспансию за последние четыре года. AI-консалтинг прошёл тест, потому что спрос предприятий на экспертизу внедрения обогнал предложение компаний, способных делать это с процессной дисциплиной. Управляемые сервисы с элементами ИИ — тоже. Формальное пентестирование — сегмент безопасности, где американские предприятия выделяли серьёзные бюджеты, а у компании были техническая глубина и комплаенс-аккредитация.
«Я хочу, чтобы клиент зарабатывал деньги, используя наши услуги, — говорит он. — Даже когда на проекте трудный участок — а такие участки бывают — эта цель не меняется». На практике это фильтр для каждого нового направления: не что компания может построить, а что рынок требует прямо сейчас и что она способна делать достаточно надёжно, чтобы ставить на кон репутацию.
Кого нанимать: честность против приукрашивания
В философии найма он избегает стандартных разговоров о culture fit. Тест проще: «Я не люблю фальшивых людей. Кто-то может преувеличить свои способности, но не больше чем на десять процентов». В пиковые периоды он проводил одну-две технические беседы в день. Сейчас — примерно раз в неделю. Общее число его не интересует. «Мне важны человек и специализация, — поясняет он. — Воронка — задача рекрутинга».
В разговоре он ценит тех, кто способен распознать собственное незнание. «Главная проблема непрерывного образования — понять, что ты ничего не знаешь», — говорит он и применяет этот стандарт к себе с той же последовательностью, что и к собеседнику. Обучение он описывает как масштабирование системы: «На первом шаге дотягиваешься руками. На втором нужна лестница. На третьем — сложные решения и оборудование». Он до сих пор пользуется лестницей и не видит в этом ничего зазорного.
Люди, которых он не наймёт, — те, кто маскирует пробелы, а не называет их. В организации, которая одновременно ведёт десятки проектов на нескольких континентах, такая привычка имеет цену, и она совсем не абстрактная. Поэтому при построении моделей компетенций честность и способность к самооценке часто выходят на первый план.
Распределённые команды: что меняет система
Управлять инженерными операциями в двадцати локациях — значит столкнуться с конкретной проблемой: разрывом между тем, что людям говорят делать, и тем, что они могут сделать, когда руководитель в семи часовых поясах. Ответ — строить системы, а не надеяться на дисциплину. «Горизонтальные и вертикальные структуры управления. Project-менеджеры, delivery-менеджеры, их руководители. Цели, бонусы, матрицы развития, управление ресурсами», — перечисляет он, как старший инженер перечисляет компоненты надёжной архитектуры. Каждый элемент несущий. Декоративных нет.
Та же логика управляет внутренним внедрением ИИ. Вместо того чтобы директивно спустить единый набор инструментов на всю компанию, он создал специальное подразделение, которое оценивает, какие AI-инструменты полезны для конкретного проектного контекста, и разрабатывает собственные решения там, где коммерческие продукты не дотягивают. «Мы адаптируем правильные инструменты под каждый проект, — говорит он. — AI-агенты уже стали стандартом. Вопрос в том, как быстро вы сделаете их полезными». Ответом снова стала система, а не приказ.
Практические рекомендации
Как применить этот подход в своей компании — не обязательно IT, а любой, где есть сложные проекты и распределённая ответственность:
- Проведите аудит управленческой архитектуры. Посмотрите на структуру как на систему: где единые точки отказа, где накапливаются задержки, кто держит критически важные знания только в голове. Спроектируйте многоуровневую ответственность с чёткими протоколами передачи.
- Задокументируйте допущения в оценках. В любом проекте — будь то разработка, обучение или запуск продукта — фиксируйте, на каких предположениях строится план. Когда условия изменятся, вы сможете предметно обсуждать, что именно поменялось и как это влияет на сроки и бюджет.
- Введите «тест на ликвидность» для новых услуг. Прежде чем инвестировать в новое направление, спросите не «Можем ли мы это сделать?», а «Будет ли рынок платить с достаточной маржой и можно ли стандартизировать delivery?». Отсекайте дорогие компетенции, которые не масштабируются.
- Наймите за честность, а не за безупречное резюме. На собеседованиях ищите людей, которые точно называют свои пробелы. Преувеличение на 10% — ещё терпимо. Систематическое приукрашивание в распределённой команде рано или поздно ударит по проекту.
- Стройте системы, а не героический менеджмент. Когда что-то идёт не так, не ищите крайнего — ищите организационное условие, которое делает ошибку повторяемой. И исправляйте его процессно. Это снижает зависимость от конкретных людей и поднимает нижнюю планку результатов.
- Смотрите с трёх сторон одновременно. При любом решении — продукт, процесс, наём — примеряйте оптику клиента, пользователя и исполнителя. Это тот же навык, что удерживать в уме несколько состояний системы при отладке, только в масштабе всей организации.
Заключение
Лучшие технические лидеры не выбирают между кодом и P&L. Они думают на обоих языках одновременно. Инженерная дисциплина без коммерческого чутья рождает безупречные системы, которые никому не нужны. Бизнес-хватка без инженерной глубины — красивые презентации, за которыми нечего ставить. Секрет в том, чтобы видеть организацию как систему, где каждый элемент — от оценки проекта до найма — работает на измеримый результат. И строить эту систему осознанно, а не по наитию.
Часто задаваемые вопросы
Почему техническому директору важно понимать бизнес-показатели?
Без этого он оптимизирует инженерное совершенство, а не коммерческий результат. Компания может производить отличный код, но проигрывать рынок, потому что решения принимаются в отрыве от экономики продукта.
Что такое «ликвидные услуги» в контексте IT-компании?
Это услуги со стабильным рыночным спросом, возможностью стандартизировать delivery и защищённой маржинальностью. Они масштабируются без потери качества и не зависят от уникальных компетенций одного-двух человек.
Как перейти от героического менеджмента к системному управлению?
Начните с документирования процессов и распределения ответственности по уровням. Создайте протоколы взаимодействия, матрицы развития и систему управления знаниями, чтобы уход одного сотрудника не обрушивал проект.
Какие качества важнее всего при найме в распределённую команду?
Честность в оценке собственных знаний и умение называть пробелы. В распределённой среде недостоверная самооценка быстро приводит к срыву сроков и конфликтам, которые сложно разрулить на расстоянии.
Можно ли применять эти принципы в нетехнических компаниях?
Да. Системный подход к управленческой структуре, документирование допущений в проектах, тест на ликвидность новых продуктов и найм на основе честности работают в любом бизнесе, где есть сложные процессы и распределённая ответственность.
С чего начать внедрение таких изменений?
С аудита текущей управленческой архитектуры и пилотного проекта, в котором вы формализуете оценку, зафиксируете допущения и введёте контрольные точки. Затем масштабируйте успешные практики.
