# Нужен ли вам консультант по внедрению ИИ или fractional CTO?

> Разберитесь, когда достаточно консультанта по внедрению ИИ, а когда fractional CTO должен отвечать за процессы, риски поставки и принятие командой.

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

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

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

## Советы заканчиваются на границе решения

Консультации помогают принимать решения, но не дают компании дополнительного управленческого ресурса. Хороший консультант помогает основателю решить, что пробовать, что отложить, как измерять результат и какие риски требуют внимания. Он может оспорить план, проверить доказательства и заметить, что команда автоматизирует симптом вместо исправления процесса.

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

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

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

Простая проверка контракта убирает расплывчатость. До покупки услуги закончите предложение: «Этот человек отвечает за ___ к сроку ___ и может напрямую изменить ___». Если в пропусках стоят решения и рекомендации, вы покупаете консультации. Если там внедрение, показатели процесса и изменения рабочих ограничений, вы покупаете руководство. Не платите цену руководителя за объем консультаций и не рассчитывайте, что консультант незаметно превратится во временного директора.

## Управленческий ресурс можно измерить

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

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

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

Проверка может выглядеть так:

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

Последний пункт самый неприятный. Если везде написано «ничего», план предполагает наличие свободного времени руководителя, которого, скорее всего, нет. Одна работа всегда вытесняет другую. Убедительное консультационное взаимодействие требует, чтобы компания прямо назвала эту замену.

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

## Риск для поставки определяет близость руководителя

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

Оцените риск по четырем направлениям:

- Обратимость: может ли команда отменить процесс или результат без вреда клиентам?
- Воздействие: могут ли конфиденциальный код, данные, учетные данные или клиентские материалы попасть не в ту систему?
- Связанность: сколько команд и средств контроля продакшена должны измениться одновременно?
- Давление срока: что произойдет, если поставка замедлится во время обучения команды?

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

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

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

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

## Внутренний владелец должен быть назван

В каждом успешном консультационном проекте есть внутренний владелец, чье имя стоит рядом с результатами, а не только во встречах. Формулировка «за это отвечает разработка» не определяет владельца. Отдел не может выбрать между датой релиза и неделей обучения, а комитет не отвечает за остановившееся внедрение.

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

До первого пилота составьте договор о владении. Это небольшой рабочий артефакт, а не руководство по политикам:

```yaml
rollout:
  business_outcome: "Reduce lead time for small customer fixes"
  accountable_owner: "CTO"
  workflow_owner: "Engineering manager"
  decision_deadline_hours: 24
  pilot_boundary:
    repositories: ["customer-portal"]
    data: "synthetic and approved test data only"
    production_deploys: "human approved"
  evidence:
    - "lead time from accepted task to production"
    - "change failure and rollback notes"
    - "review rework caused by generated output"
  stop_conditions:
    - "unapproved data enters an AI tool"
    - "two releases bypass required review"
  review_date: "YYYY-MM-DD"
```

Имена и границы предотвращают знакомый сбой: инициативу поддерживают все, но никто не может вовремя сказать «да», «нет» или «стоп». Бизнес-результат не дает команде подменить поставку количеством запросов к модели или сгенерированных строк. Условия остановки позволяют владельцу процесса прекратить пилот без предварительного политического спора.

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

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

## Успешный пилот не гарантирует успешное внедрение

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

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

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

Затем приходит срочный запрос клиента. Руководитель разработки отменяет обучение и просит команду «использовать ИИ там, где он помогает». Запросы доступа ждут, потому что служба безопасности не согласовала границы данных. Один инженер работает в одобренном чате, но вставляет туда журнал с данными клиента. Другой перестает пользоваться инструментом после первого слабого результата. Еженедельный отчет по-прежнему показывает активное использование, потому что первые добровольцы продолжают работу.

Эта последовательность не доказывает провал инструмента. Руководство не превратило условия пилота в рабочий процесс. Компании требовался человек, который перестроит прием задач, исправит узкое место в тестах, определит доступ, обучит ревьюеров, разделит внедрение по типам работы и отличит принятие инструмента от бизнес-результата. Консультации выявили несколько таких потребностей, но за общую систему поставки никто не отвечал.

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

## Первый процесс важнее первого инструмента

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

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

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

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

Инструмент выбирают после определения границ процесса. Claude Code, Codex и многоагентные конвейеры подходят для разных видов работы, но список инструментов не заменяет рабочий план. Компании по-прежнему нужны права на репозитории, границы задач, критерии оценки, ответственность за ревью и порядок исключений. Увлечение инструментами часто скрывает отсутствие этих решений.

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

## Консультациям нужен готовый рабочий ритм

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

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

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

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

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

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

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

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

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

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

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

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

Мой Team & AI Audit на oleg.is длится пять рабочих дней и должен найти не менее $50 000 экономии в год, иначе услуга бесплатна. Такой ограниченный формат помогает определить, что покупать дальше: консультации или практическое руководство трансформацией. Аудит не отменяет потребность во внутреннем владельце, а рекомендация должна прямо сказать, когда компании нужен fractional CTO.

## Выбирайте минимальный мандат, который покрывает риск

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

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

Перед подписанием используйте такую запись решения:

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

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

Бюджет должен соответствовать ответственности. Консультации от $3 000 в месяц разумны, если внутреннее руководство может выполнить работу. Fractional CTO за $5 000-10 000 в месяц предполагает другой уровень участия в операционной деятельности. Сравните эти расходы с ценой задержанных релизов, отвлечения руководителей, небезопасного доступа и внедрения, которое не изменило поставку. Не сравнивайте их как два объема одной услуги.

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