# Платное тестовое задание для лидера ИИ-трансформации

> Проверьте лидера ИИ-трансформации на платном задании: одно узкое место поставки, одно решение по безопасности и одна модель затрат.

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

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

## Платное тестовое задание должно давать факты

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

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

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

До начала работы согласуйте оценочную таблицу:

```text
Trial outcome                    Weight   Evidence
Delivery bottleneck understood   25%      Baseline, queue map, rejected causes
Intervention shipped or tested   20%      Change record, result, rollback
Security judgment                20%      Decision note, controls, residual risk
Cost model                       20%      Inputs, formulas, scenarios, owner
Leadership behavior              15%      Team feedback, decisions, handoff
```

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

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

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

## Передайте кандидату одно настоящее узкое место поставки

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

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

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

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

Простая запись об эксперименте помогает честно оценить работу:

```yaml
bottleneck: release approval
baseline_window: last 15 releases
suspected_cause: routine migrations wait for expert review
change: automated checks plus risk-based review
success_signal: fewer low-risk releases waiting over one business day
guardrail: zero unreviewed destructive migrations
rollback: restore mandatory review for every migration
owner_after_trial: platform lead
```

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

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

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

## Определение готовности показывает качество руководителя

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

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

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

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

```text
Observation: 11 of 15 releases waited for the same reviewer.
Decision: test automated checks for routine migrations.
Unknown: whether the reviewer catches issues absent from current checks.
Test: replay checks and reviewer comments on the same 15 releases.
Result: [filled during trial]
Consequence: [continue, revise, or stop]
```

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

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

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

## Поставьте одно решение по безопасности с последствиями

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

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

NIST AI Risk Management Framework разделяет выявление контекста риска, его измерение и управление им, а корпоративное управление действует на всех этапах. Для этого задания разделение полезно. Список угроз выявляет риски, повторная проверка или ревизия доступа измеряет их часть, а граница полномочий и назначенный владелец управляют ими. Кандидат, который называет список угроз мерой защиты, не закончил решение.

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

```text
Use case:
Business owner:
Data the system may receive:
Tools and actions allowed:
Actions requiring human approval:
Logs retained and reviewer:
Failure and abuse cases tested:
Rollback or access revocation:
Residual risk:
Decision and accountable approver:
```

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

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

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

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

## Модель затрат должна выдержать вопросы скептичного CFO

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

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

Используйте модель с открытыми допущениями:

```text
monthly_current_cost =
  current_touch_hours * loaded_hourly_cost
  + rework_hours * loaded_hourly_cost
  + expected_failure_cost

monthly_changed_cost =
  retained_touch_hours * loaded_hourly_cost
  + review_hours * reviewer_hourly_cost
  + tool_fees
  + integration_and_maintenance
  + expected_failure_cost_after_change

monthly_net_savings = monthly_current_cost - monthly_changed_cost
payback_months = one_time_change_cost / monthly_net_savings
```

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

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

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

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

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

В oleg.is Team & AI Audit проходит за фиксированные пять рабочих дней и использует порог экономии, потому что до широкой трансформации основателю нужно ограниченное экономическое решение. Ваше платное тестовое задание может следовать той же дисциплине, даже если вы наймете другого человека: фиксированный объем, конкретные факты и результат, который финансовый руководитель способен оспорить.

## Наблюдайте за работой при сопротивлении

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

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

После передачи работы задайте команде узкие вопросы:

- Разобрался ли кандидат в работе до того, как предложил изменение?
- Можно ли было оспорить допущение, не столкнувшись с пренебрежением?
- Понятно ли вам, что изменилось и почему?
- Сможете ли вы поддерживать или отменить изменение без кандидата?
- Создала ли работа незапланированную нагрузку?

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

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

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

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

## Сохраняйте узкие полномочия при реальной работе

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

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

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

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

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

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

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

## Проверяйте цепочку решений, а не финальную демонстрацию

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

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

Проведите разбор в таком порядке:

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

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

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

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

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

## Принимайте решение о найме, пока факты свежи

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

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

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

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

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

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

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