# Внешний или штатный CTO для AI-трансформации

> Сравниваем внешнего и штатного CTO для AI-трансформации: полномочия, месячные расходы, срок найма и четыре повода взять руководителя в штат.

Сильный руководитель разработки меняет критерии выбора CTO. Вам уже не нужен топ-менеджер, чтобы вести стендапы, добиваться закрытия задач или превращать дорожную карту в недельный план. Нужен человек, который решит, на какие технические ставки пойдет компания, установит ограничения для разработки с помощью AI и подчинит продукт, разработку, безопасность и финансы одной рабочей модели.

Для большинства компаний в такой ситуации разумнее сначала привлечь внешнего CTO. Эта роль может получить реальные полномочия, при этом компании не придется нанимать постоянного топ-менеджера до того, как станет понятен масштаб трансформации. Берите CTO в штат, когда работа превращается в постоянную задачу для руководителя, а не потому, что слова «AI-трансформация» звучат слишком серьезно для частичной занятости.

Ответ зависит от четырех вещей: какие решения принимает CTO, во что экономически обходится каждый вариант, сколько компания может ждать и понадобится ли постоянный руководитель после запуска новой рабочей модели. Если все это определено правильно, форма занятости почти не имеет значения. Если ошибиться, провалится любой вариант.

## Руководитель разработки меняет критерии найма

Сильный руководитель разработки уже отвечает за движение работы. Он превращает приоритеты в план, ежедневно устраняет препятствия, следит за выпусками и прямо говорит, когда объем задач не соответствует ресурсам. Штатный CTO над ним может помочь, но только если для него есть отдельная работа на уровне руководства компании.

Основатели часто объединяют под должностью CTO четыре работы. От одного человека ждут технической стратегии, управления людьми, управления выпуском продукта и роли главного архитектора. Внедрение AI усугубляет путаницу, потому что каждый застрявший пилот называют стратегической проблемой. На практике многие пилоты буксуют из-за слабых критериев приемки, небезопасного доступа, отсутствия данных для оценки или старого процесса проверки. Сильный руководитель разработки может исправить многое из этого, когда топ-менеджер задаст правила и разрешит противоречия между подразделениями.

Важно различать поток решений и поток работы. Руководитель разработки отвечает за поток работы: что команда берет в работу, кто это делает, что мешает и когда выйдет результат. CTO отвечает за поток решений: какие ограничения действуют, кто вправе принимать конкретные риски, когда локальный инструмент становится стандартом компании и какая техническая инвестиция важнее ближайшей функции продукта. Обеим ролям нужны полномочия, но разные.

С помощью этого разделения найдите настоящий пробел. Если основатель по-прежнему часами разбирает споры об инструментах, архитектуре, исключениях из правил безопасности, профилях найма и продуктовых компромиссах, компании не хватает технического руководителя. Если решения сосредоточены внутри программы трансформации, а затем превращаются в повторяемые правила, подойдет внешний руководитель. Если они возникают каждый день, потому что технология и есть бизнес, а выбор постоянно меняет направление компании, работа может требовать штатного CTO.

Не превращайте руководителя разработки в теневого CTO, не изменив его полномочия. Иначе он отвечает за результат, но не может на него влиять. Его обвинят в расходах на облако, рисках AI и техническом долге, хотя продуктовая и финансовая команды могут отменить любую профилактическую меру. Оставьте ответственность за выпуск там, где она работает, а CTO письменно передайте решения, которые другие руководители не смогут случайно отменить.

## Полномочия дает мандат, а не трудовой договор

У внешнего CTO может быть больше действенных полномочий, чем у штатного руководителя с размытой зоной ответственности. Полномочия исходят из мандата основателя или совета директоров, доступа к нужной информации, установленного порядка принятия решений и явной поддержки, когда решение требует времени или денег другого подразделения. Само зачисление в штат ничего этого не дает.

Составьте мандат до интервью с любым CTO. Укажите решения, ограничения, обязательные консультации и правила эскалации. Практичный вариант помещается в небольшой конфигурационный блок:

```yaml
technology_authority:
  owner: cto
  decisions:
    - ai_tool_approval
    - production_architecture
    - engineering_org_design
    - security_exception_acceptance
  delivery_lead_owns:
    - sprint_commitment
    - release_sequence
    - blocker_resolution
    - delivery_metrics
  consult:
    - founder
    - product_lead
    - security_owner
    - finance_owner
  escalation:
    trigger: decision_exceeds_approved_budget_or_risk_limit
    final_owner: ceo
  review_after_days: 90
```

Это не формальность. Такой мандат предотвращает частую ошибку: CTO рекомендует одну AI-среду для программирования, менеджер продукта покупает другую, разработчики работают через личные аккаунты, а руководителю разработки приходится поддерживать все три варианта. Мандат закрепляет решение об инструментах за одним владельцем. Он также не дает CTO вмешиваться в каждый спринт только из-за высокой должности.

Ограничения не менее важны, чем решения. CTO не должен принимать юридический риск, за который отвечает CEO, решать вопросы конфиденциальности без юриста или незаметно менять обещание клиенту. В мандате нужно записать, где руководитель рекомендует, где решает сам, а где основатель выбирает после получения письменных вариантов.

В документе AI Risk Management Framework от NIST функция Govern действует поперек функций Map, Measure и Manage. Это полезная поправка к мысли, будто управление рисками сводится к финальному согласованию. При трансформации разработки правила работают через доступ к инструментам, требования к данным, оценку моделей, пороги проверки, ответственность за инциденты и доказательства, которые сохраняются после выпуска. CTO проектирует эту систему, а руководитель разработки обеспечивает ее работу в обычном процессе.

Проверяйте полномочия на интервью. Дайте кандидату конфликт: продуктовая команда хочет выпустить созданные AI миграции на этой неделе, разработчики просят еще один цикл тестирования, а договор с клиентом ограничивает использование производственных данных. Спросите, что кандидат решит, какие доказательства запросит и что передаст выше. Кандидат, который говорит лишь о согласовании интересов, не показал способности принимать решения руководителя. Кандидат, который диктует технический ответ, не прочитав договор, тоже ее не показал.

## Сравнивайте экономические расходы, а не счет и зарплату

Честное сравнение строится на месячных экономических расходах ради нужного результата. Счет внешнего CTO и зарплата штатного сотрудника измеряют разные вещи. Если поставить их рядом, за кадром останутся стоимость поиска, льготы, премия, доля в компании, время руководителей, неиспользованная загрузка и цена ожидания штатного сотрудника.

Для внешнего варианта сложите абонентскую плату, отдельные проектные платежи, внутреннее время основателя и руководителя разработки, а также внедрение вне договора. Услуга руководства AI-трансформацией на oleg.is стоит от $5 000 до $10 000 в месяц. Считайте это строкой за руководство, а не полным бюджетом трансформации. Разработчикам все равно понадобится время на изменение тестов, разрешений, конвейеров и правил работы.

Для штатного CTO подставьте параметры реального предложения. Небольшая модель не даст зарплате превратиться в обманчивое сокращение:

```text
monthly permanent CTO cost =
  annual base / 12
  + target annual bonus / 12
  + employer taxes and benefits / 12
  + annualized recruiting cost / 12
  + expected equity cost / 12
  + executive support and travel
```

Допустим, основатель вводит годовой оклад $300 000, целевую премию $60 000, расходы работодателя $45 000 и стоимость найма $60 000, распределенную на первый год. До учета доли и поддержки модель покажет $38 750 в месяц. Это пример расчета, а не рыночная ставка. Замените каждый параметр предложением поставщика или правилом вашей компании.

Теперь оцените цену пустующей позиции. Если задержка с правилами AI подвергает риску данные клиентов, архитектурные решения блокируют корпоративные продажи или во время поиска сохраняется избыточный фонд оплаты разработки, ожидание имеет месячную цену. И наоборот, если руководитель разработки безопасно выполняет текущий план, а основатель принимает несколько оставшихся решений, срочность может быть искусственной. Поиск не становится разумным только потому, что совет директоров утвердил большой бюджет.

Оцените и несоответствие роли. Штатный CTO, который большую часть недели проверяет задачи, выполняет слишком дорогую работу руководителя разработки. Внешний CTO, который приходит на ежемесячный звонок, пока команды сами придумывают правила, дает слишком дорогие советы. Сравнивайте стоимость правильно спроектированной роли, а не самый дешевый договор для каждой формы занятости.

О доле в компании нужно говорить прямо. Иногда основатели считают ее бесплатной, потому что в текущем месяце деньги не уходят со счета. Доля покупает долгосрочную приверженность и разделяет будущую выгоду. Это разумно для штатного руководителя, который годами увеличивает ценность компании. Но это плохая оплата за ограниченную трансформацию, которая должна за несколько месяцев создать рабочую модель. Учитывайте долю при выборе, даже если бухгалтерия отражает ее иначе.

Правильная единица сравнения: стоимость устраненного ограничения на уровне руководства. Выпишите решения, которые застряли у основателя, риски без владельца и организационные изменения, которые руководитель разработки не вправе одобрить. Затем спросите, сколько стоит каждый вариант до устранения этих ограничений. Маленький платеж не означает экономию, если мандат исключает самые трудные решения. Большой пакет штатного CTO будет лишним, если после трансформации его работа почти исчезнет.

## Срок найма входит в технический план

У внешнего CTO обычно короче путь к полезной работе: компания проверяет доступность, согласует объем, проводит проверку и подписывает договор услуг. В штатном поиске добавляются описание роли, поиск кандидатов, несколько этапов интервью, рекомендации, переговоры о предложении, срок увольнения с прежнего места и более долгое знакомство с организацией. Планируйте по этим этапам, а не по общей оценке, сколько месяцев якобы занимает поиск руководителя.

Отсчет начинается, когда компания обнаружила пробел в решениях, и заканчивается, когда CTO может принять значимое решение с достаточным контекстом. Подписанный договор еще не финиш. Если обязательства перед клиентами, схемы систем, данные о расходах, история команды и текущие инциденты разбросаны, любой CTO потратит первые недели на восстановление картины компании.

Сведите сравнение на одну страницу. Для каждого варианта назначьте владельца и ожидаемую дату рядом с событиями: мандат утвержден, кандидат доступен, проверка завершена, доступ выдан, интервью с командой проведены, первое решение принято, первое изменение процесса запущено. Для дат используйте данные рекрутера и доступность конкретного кандидата. Не вставляйте придуманные средние значения рынка в план для совета директоров.

Цена задержки должна определять порядок действий, а не толкать к поспешному найму в штат. Разумная схема: привлечь внешнего CTO для трансформации и отдельно решить, открывать ли постоянную вакансию. Внешний руководитель уточнит роль, покажет реальную нагрузку решений и оставит материалы для поиска. Схема становится опасной лишь тогда, когда временному руководителю выгодно доказать ненужность штатной позиции или подготовить ее под себя. Зафиксируйте этот конфликт в договоре, а окончательное решение о найме оставьте основателю или совету директоров.

Следите и за противоположной задержкой. Некоторые основатели продлевают внешний контракт, потому что постоянный поиск кажется неудобным. Назначьте дату пересмотра при выдаче мандата. В этот день изучите частоту решений, требования к скорости ответа, зависимость команды и стратегию компании на следующие два квартала. Если роль стала непрерывной и внутренней, начинайте поиск, даже когда внешний формат работает хорошо.

Сильный руководитель разработки ускоряет ввод в работу обоих вариантов. Он предоставит историю выпуска, текущие обязательства, повторяющиеся сбои и карту неформальных полномочий. Преимущество исчезнет, если руководитель почувствует, что его проверяют или заменяют. До первого интервью с CTO объясните ему, что остается в его роли, что переходит к CTO и по каким критериям оценят результат.

## Внешний CTO должен оставить рабочую систему

Внешний проект должен дать решения и научить компанию принимать их дальше. Если прогресс навсегда зависит от присутствия CTO на каждой встрече, проект создал зависимость вместо системы управления.

Первый результат: реестр решений. Запишите повторяющийся выбор AI-инструментов, доступ к данным, выбор модели, проверку человеком, архитектуру, поставщиков, найм и риск выпуска. Для каждого пункта укажите владельца, нужные доказательства, время ответа и точку эскалации. Руководитель разработки должен направлять вопрос по правильному пути, не гадая, какой топ-менеджер сейчас в сети.

Второй результат: небольшой набор рабочих ограничений. Сюда могут входить разрешенные типы аккаунтов, запрещенные классы данных, требования к оценке созданных изменений, правила проверки по уровню риска и действия при утечке или повреждении информации AI-инструментом. Точные ограничения зависят от компании. Политика крупного банка не сработает в небольшом программном бизнесе, если ее некому выполнять.

Третий результат: изменившаяся экономика. Зафиксируйте исходные показатели до сокращения команды или обещания ускорить выпуск: фонд оплаты по функциям, выполненную работу, дефекты после выпуска, нагрузку от инцидентов, время проверки, расходы на облако и модели, а также часы, которые основатель тратит на технические споры. Выберите показатели, которые показывают и скорость, и ущерб. Количество созданного кода или лицензий на инструменты вознаграждает активность, а не результат компании.

Четвертый результат: передача управления. Руководителю разработки нужен понятный ритм работы, доступ к решениям и право отклонять задачи, нарушающие утвержденное ограничение. Основателю нужен короткий отчет о расходах, рисках, спорных решениях и вопросах, где еще требуется мнение топ-менеджера. Будущим сотрудникам нужно объяснение, почему модель работает, а не папка с шаблонами без контекста.

Сделайте передачу знаний наблюдаемой. Попросите руководителя разработки провести встречу по решениям, пока CTO наблюдает. Попросите разработчика пройти порядок действий при инциденте без личной подсказки. Дайте основателю предложение нового поставщика и проверьте, приведут ли правила согласования к ясному ответу. Документ не закончен, если никто не может применить его без автора.

Внешний CTO также может рекомендовать постоянного преемника. Рекомендация весит больше, когда проект измерил настоящую работу: сколько возникает решений уровня руководства, как быстро нужны ответы, какие отношения требуют постоянства и каких знаний не хватает внутри. Она весит меньше, когда основана на стандартном описании вакансии с добавленными модными словами про AI.

## Четыре условия оправдывают штатного CTO

Штатный CTO нужен, когда после запуска рабочей модели компании все равно требуется постоянное присутствие технического руководителя. Такой найм оправдывают четыре условия. Одного сильного условия может хватить. Несколько слабых сигналов не образуют аргумент только потому, что их много.

### Технологические решения еженедельно меняют стратегию компании

Нанимайте в штат, если технические решения снова и снова меняют продукт, рынок, план финансирования или риск компании. Примеры: основной продукт зависит от собственного поведения модели, платформа решает, какие возможности станут публичными обязательствами, или экономика инфраструктуры определяет валовую маржу бизнеса. Это не периодические проверки архитектуры, а решения компании с техническим содержанием.

Руководитель разработки не должен поглощать эту работу. Если попросить его одновременно выпускать дорожную карту и постоянно переопределять техническую позицию компании, предсказуемая поставка будет конфликтовать со сменой стратегии. Внешний CTO закроет интенсивный период, но календарь покажет несоответствие, если основателю почти каждый рабочий день нужно мнение руководителя.

Используйте журнал решений как доказательство. В течение шести-восьми недель записывайте решения, которые требовали участия основателя или совета, меняли коммерческое обязательство, переносили существенный бюджет или принимали риск компании. Уберите обычные вопросы архитектуры и выпуска. Если оставшийся список частый, срочный и определяет направление компании, нужна постоянная роль.

### Названный руководитель должен постоянно отвечать перед внешними сторонами

Нанимайте в штат, когда клиентам, регуляторам, страховщикам, инвесторам или партнерам нужен технический руководитель, который глубоко знает системы и постоянно отвечает за ограничения и инциденты. Определяющее слово: постоянно. Внешний руководитель может подготовить аудит, исправить управление и участвовать в важных проверках. Этого может не хватить бизнесу, где ответственность топ-менеджера участвует в каждой крупной продаже или регулируемой операции.

Не выводите это условие из тревоги. Прочитайте договор, нормативное требование, условие страховки или запрос проверки. Определите, что именно нужно подтвердить, кто вправе это сделать, как быстро он должен отвечать и подходит ли внешний руководитель. Юрист должен разъяснить правовую сторону. CTO должен спроектировать технические доказательства и обеспечить их получение.

Одна должность не выполняет условие. Если нанять штатного CTO без контроля над бюджетом безопасности, архитектурой, реагированием на инциденты и обязательствами перед поставщиками, клиенты получат представителя вместо ответственного руководителя. Расширьте мандат или оставьте ответственность у человека, у которого уже есть власть.

### Руководителям нужна ежедневная поддержка топ-менеджера

Нанимайте в штат, когда нескольким руководителям разработки и технического продукта постоянно нужны наставничество, решения об эффективности, подготовка преемников и изменение организации. Внешний CTO может оценить структуру и обучать руководителей, но некоторым командам нужно ежедневное наблюдение, чтобы отличить разовый срыв выпуска от системной управленческой проблемы.

Это условие часто появляется после роста, слияния, крупного расширения продукта или повторных смен старших сотрудников. Само число людей ничего не доказывает. Ищите решения между командами, руководителей с конфликтующими целями, неясные правила повышения, неразделенную ответственность продукта и разработки, а также технических лидеров, которые не получают внимания основателя, когда компромиссы становятся политическими.

Не превращайте штатного CTO в начальника каждого разработчика. Он должен выстроить слой руководителей, которые несут локальную ответственность. Если через год все решения по-прежнему поднимаются к CTO, компания сосредоточила власть, но не развила организацию.

### Компании нужен долгосрочный технический партнер CEO

Нанимайте в штат, когда CEO нужен равный руководитель, который несколько лет будет формировать компанию, разделит ответственность перед советом, наймет старших лидеров, представит технологию при финансировании или крупных продажах и будет жить с последствиями прежних решений. Это условие отношений и горизонта времени, а не расчет загрузки.

Доля в компании уместна в таком случае, потому что руководитель создает ценность после трансформации. Глубокое знание компании тоже накапливается: CTO понимает, почему покупают клиенты, какие технические компромиссы допустимы, где у команды болезненный опыт и когда на первый взгляд разумная перепись системы уничтожит темп.

Основатели иногда говорят, что хотят такого партнера, но ограничивают мандат выпуском разработки. Такая позиция привлечет операционного руководителя или старшего менеджера разработки с более громким названием. Если CEO оставляет себе продуктовую стратегию, право отменять архитектурные решения, найм старших сотрудников и общение с советом, компания не предлагает работу CTO. Исправьте полномочия до оплаты постоянства.

## CTO и руководителю разработки нужна жесткая граница

Самая дорогая ошибка: пересекающиеся полномочия. Она начинается вежливо. CTO приходит на планирование, чтобы разобраться, предлагает другую последовательность и просит у разработчиков оценки. Руководитель разработки подстраивается. Затем продуктовая команда приносит идеи прямо к CTO, потому что так ответ приходит быстрее. Через несколько недель у команды две очереди, а каждый сорванный срок можно списать на другого руководителя.

Я видел тот же сценарий с AI-инструментами. CTO просит одного разработчика проверить агента на настоящем репозитории. Руководитель разработки не знает, что эксперимент увеличил нагрузку на проверку. Созданные изменения попадают в выпуск, проверяющие отстают, плановая работа сдвигается. Инструмент может быть полезен. Ошибка появилась потому, что технический эксперимент провели вне доступных ресурсов и порядка выпуска.

Проведите границу по решениям, а не встречам. CTO может определить, к каким репозиториям получает доступ агент, какие доказательства нужны для созданного изменения и какой риск требует дополнительной проверки. Руководитель разработки решает, когда эксперимент войдет в план, у кого есть время и какой выпуск выдержит нагрузку. Если продуктовая команда хочет приблизить дату, руководитель разработки отвечает за новый прогноз, а CTO сохраняет предел риска.

Ведите один общий журнал решений. В каждой записи должны быть решение, владелец, дата, доказательства, затронутая работа, дата пересмотра и условие отмены. Архитектурные эссе храните отдельно. Журнал нужен, чтобы менеджер мог ответить: «Почему мы это делаем и кто может изменить решение?», не пересматривая шесть встреч.

Основатель должен защищать границу. Если он обходит руководителя разработки ради любимой функции или просит CTO согласовать обычные изменения спринта, обе роли скопируют это поведение. Исправляйте маршрут публично, а эффективность обсуждайте лично. Люди верят рабочей модели, которую видят под давлением.

Конфликт полезен, когда путь эскалации понятен. Руководитель разработки должен оспаривать ограничение, из-за которого выпуск становится непрактичным. CTO должен оспаривать план, который скрывает риск ради даты. Они приносят основателю письменный выбор только тогда, когда решение выходит за пределы их мандатов, а не при каждом разногласии.

## Проверьте роль за 90 дней до постоянного найма

Мандат внешнего CTO на 90 дней дает время обнаружить повторяющиеся решения, установить базовые ограничения и проверить, сможет ли руководитель разработки поддерживать получившуюся модель. Это не испытательный срок, если обе стороны прямо о нем не договорились. Это обратимый способ узнать, какая роль топ-менеджера действительно нужна компании.

1. В первые две недели составьте реестр решений и зафиксируйте исходные показатели. Поговорите с основателем, руководителем разработки, владельцем продукта, разработчиками, ответственными за безопасность и финансы. Запишите, где работа ждет решения, какие AI-инструменты и аккаунты используются, к каким данным у них есть доступ, как проверяется созданная работа и что показывают текущие показатели выпуска и инцидентов.

2. В течение следующего месяца выдайте мандат и измените рабочую систему. Одобрите или отклоните инструменты, задайте ограничения для данных и проверки, назначьте ответственность за инциденты и перенесите права на решения из разговоров с основателем в общий журнал. Пусть руководитель разработки планирует внедрение и сообщает, когда ограничения требуют больше ресурсов, чем ожидалось.

3. В следующем месяце проверьте модель под нагрузкой. Используйте настоящий выпуск, выбор поставщика, производственный инцидент или запрос клиента. Наблюдайте за временем ответа, качеством доказательств, числом эскалаций и тем, идут ли люди по установленному пути без личных напоминаний. Исправьте систему там, где обычная работа побеждает письменный порядок.

4. В последние недели передайте работу и примите решение о роли. Руководитель разработки ведет рабочий ритм. Основатель разбирает эскалации по мандату. CTO записывает незакрытую стратегическую работу, постоянные внешние обязанности, пробелы в руководстве и решения, ожидаемые в следующие два квартала.

Согласуйте критерии выхода в начале. Хороший выход внешнего CTO означает, что у повторяющихся решений есть владельцы, ограничения работают без CTO на каждой встрече, руководитель разработки защищает и поток, и правила, а основатель получает короткий отчет об исключениях. Хорошая рекомендация нанять в штат означает, что доказательства совпадают хотя бы с одним из четырех условий выше, а предлагаемый мандат содержит настоящие полномочия топ-менеджера.

Не оценивайте проверку по объему созданной AI работы. Смотрите на выпущенную бизнес-функциональность, дефекты и инциденты, продолжительность цикла и проверки, общие расходы на разработку и модели, выполненные требования клиентов и нагрузку решений на основателя. Некоторые показатели изменятся медленно. Компания должна уметь объяснить изменения, не выбирая только приятные цифры.

Team & AI Audit может закрыть первый диагностический этап: пять рабочих дней за фиксированные $5 000, с гарантией найти не менее $50 000 годовой экономии, иначе аудит бесплатен. Предложение подходит компании, которой нужны доказательства до 90-дневного мандата, но основателю все равно придется открыть неудобные данные о расходах и процессе.

На 90-й день выберите один из трех честных результатов. Завершите проект, потому что рабочая модель действует. Продлите ограниченный внешний мандат, потому что осталась конкретная работа по трансформации. Откройте поиск штатного CTO, потому что у компании появилась постоянная работа топ-менеджера. Автоматическое продление договора не считается решением.

## Выбирайте роль по обратимости

Внешний CTO подходит по умолчанию, когда сильный руководитель разработки способен поддерживать рабочую систему, а недостающие решения топ-менеджера можно описать мандатом трансформации. Такой вариант дешевле проверить, он запускается через более короткий путь заключения договора и позволяет спроектировать штатную роль по фактам. Эти преимущества исчезают, если внешнему руководителю не хватает полномочий или доступности в момент решения.

Штатный CTO оправдан, когда техническая стратегия постоянно меняет направление компании, внешняя ответственность требует постоянного руководителя, слою лидеров нужна ежедневная поддержка топ-менеджера или CEO ищет долгосрочного технического партнера. Постоянство покупает непрерывность и накопленный контекст. Оно не должно покупать громкую должность для работы, которую уже делает руководитель разработки.

Составьте матрицу полномочий сейчас, до выбора человека. Оцените обе роли по одной экономической модели. Поставьте каждое событие срока найма в календарь и назначьте владельца. Затем соберите решения за 90 дней. Их рисунок покажет, нужен ли компании руководитель трансформации на определенный срок или CTO, у которого останется полная работа топ-менеджера после того, как новая система станет обычной.