От хаоса к системе: насколько реально построить AI-first-команду за полгода
В июне 2025 года перед ИТ-блоком Cloud.ru поставили амбициозную задачу: не ограничиться отдельными экспериментами с нейросетями, а сформировать полноценную AI-first-команду. Речь шла о коллективе численностью более 300 человек, который отвечает за создание инфраструктуры для облачных сервисов.
Цель заключалась не в том, чтобы каждый сотрудник время от времени открывал чат с ИИ. Нужно было встроить искусственный интеллект в повседневные процессы: разработку, аналитику, подготовку документации, управление проектами, поддержку и принятие решений. Одновременно требовалось понять исходный уровень команды, убрать барьеры, вовлечь занятых специалистов и научиться измерять результат.
Сразу стало ясно: сильная техническая экспертиза сама по себе не превращает подразделение в AI-first-команду. У сотрудников были знания и опыт, но отсутствовала единая система применения ИИ.
С какими проблемами пришлось работать
Основных препятствий оказалось два.
Первое - недостаток ориентиров. Коллеги не всегда понимали, какие инструменты действительно полезны, какие сценарии уже готовы к применению, а какие пока остаются экспериментальными. Кроме того, было неясно, куда рациональнее направлять ограниченное время: изучать новые модели, автоматизировать рутинную операцию или запускать полноценный проект.
Второй барьер - нехватка времени. Информации об ИИ слишком много, она быстро устаревает и постоянно обновляется. Даже мотивированный специалист легко оказывается в ситуации, когда вместо практического внедрения тратит часы на чтение новостей, обзоров и сравнений сервисов.
Поэтому трансформацию решили строить на четырех принципах.
Измеримость. Нужно было регулярно отслеживать уровень зрелости, частоту использования ИИ, типовые ограничения и запросы на обучение.
Прозрачность. Каждую идею следовало оценивать по понятным критериям: бизнес-эффекту, технической реализуемости, затратам, рискам и потенциальному масштабу.
Обучение на реальных задачах. Вместо абстрактных лекций команда должна была разбирать собственные процессы и постепенно выращивать внутренних практиков.
Безопасная культура экспериментов. Сотрудникам важно было дать пространство, где можно тестировать гипотезы, обсуждать неудачи и делиться рабочими приемами без страха получить негативную оценку.
Ключевым управленческим решением стало право менять первоначальный план. Опросы корректировали программу обучения, интервью с авторами идей влияли на порядок запуска инициатив, а результаты пилотов могли вернуть проект на этап уточнения данных, архитектуры или критериев качества.
Инструмент № 1. Диагностика, которая меняет стратегию
Первым шагом стал опрос. Для повышения отклика к нему подключили руководителей: директор блока неоднократно напоминал сотрудникам о необходимости участия. В результате анкету содержательно заполнили около 80% команды.
Исследование проводили дважды - в июне, на старте программы, и через полгода, в декабре. Вопросы охватывали несколько направлений:
- самооценку знаний об искусственном интеллекте по пятибалльной шкале;
- регулярность использования ИИ в работе;
- основные барьеры: нехватку знаний, времени, вопросы безопасности и недоверие к качеству;
- предпочтительные форматы обучения;
- примеры неудачного применения нейросетей;
- субъективное влияние ИИ на продуктивность.
Особую ценность представляли не высокие оценки, а конкретные негативные комментарии. Жалоба на медленные ответы указывала на инфраструктурную проблему. Недовольство неточностью - на качество исходных данных, настройку промптов или отсутствие проверки результата. Фраза "у меня нет времени" говорила уже не об обучении, а об организации процесса.
Такой подход позволил не гадать о потребностях команды, а связывать каждый сигнал с возможным решением.
Инструмент № 2. Скоринг вместо бесконечного списка идей
После диагностики начался сбор инициатив. В крупных командах быстро возникает обратная проблема: предложений становится слишком много, а ресурсов на реализацию недостаточно. Поэтому все идеи объединили в единый портфель и стали оценивать по общей системе.
В скоринг включили несколько параметров:
- ожидаемую пользу для бизнеса или внутренних процессов;
- количество потенциальных пользователей;
- сложность внедрения;
- доступность и качество данных;
- требования к безопасности;
- возможность масштабирования;
- прогнозируемую экономию времени;
- наличие владельца инициативы.
Важным принципом стала фиксация не только победителей, но и причин отказа от конкретного проекта. Это снижает ощущение субъективности и помогает возвращаться к отложенным идеям, если изменились технологии, данные или приоритеты.
При этом высокий балл еще не гарантирует быстрый запуск. Инициатива может выглядеть перспективно, но упираться в закрытые данные, сложную интеграцию или отсутствие ответственного эксперта. Поэтому скоринг использовали как инструмент принятия решений, а не как автоматическую очередь на разработку.
От идеи к рабочему решению
Переход от красивой концепции к продакшену часто оказывается самым сложным этапом. На презентации нейросеть может выглядеть впечатляюще, но в реальном процессе проявляются задержки, ошибки, нестабильные ответы и неудобный интерфейс.
Отдельная проблема - качество входных данных. Ошибка модели нередко начинается задолго до обращения к языковой модели: в устаревшей документации, противоречивых регламентах, неполной базе знаний или неправильной структуре хранилища.
Поэтому перед запуском пилотов важно проверять не только модель, но и весь контур:
1. кто и в каком формате готовит данные;
2. насколько часто они обновляются;
3. какие источники считаются достоверными;
4. как будет проверяться ответ;
5. что произойдет при ошибке;
6. где фиксируются результаты и обратная связь.
Для критичных процессов необходим режим "человек в контуре". ИИ может подготовить черновик, классифицировать запрос, предложить варианты или найти нужные сведения, но финальное решение должен принимать сотрудник, если ошибка способна привести к финансовым, юридическим или операционным последствиям.
Инструмент № 3. Фабрика внутренних экспертов
Однократный обучающий вебинар редко меняет поведение. После него сотрудники получают общее представление о возможностях технологий, но не всегда понимают, как применить их к собственной работе.
Поэтому эффективнее строить обучение вокруг реальных задач. Участник приносит конкретный сценарий - например, подготовку технического описания, разбор инцидентов, обработку обращений или составление отчетов. Затем команда вместе уточняет процесс, выбирает подходящий инструмент, формулирует критерии качества и проверяет результат.
Так постепенно появляются внутренние эксперты, которые знают не только возможности конкретного сервиса, но и ограничения, требования безопасности и особенности процессов компании. Их роль особенно важна при масштабировании: коллеги охотнее перенимают практику у специалиста, который понимает их контекст.
Полезно также создавать библиотеку шаблонов: проверенные промпты, инструкции по верификации, примеры типовых ошибок, правила работы с конфиденциальными данными и готовые сценарии автоматизации.
Инструмент № 4. Информационное поле вместо потока новостей
Сотрудникам не нужен еще один бесконечный канал с ежедневными новостями о выходе новых моделей. Гораздо полезнее компактное и структурированное информационное поле.
Оно может включать:
- подборки инструментов под конкретные рабочие задачи;
- краткие разборы успешных и неудачных экспериментов;
- ответы на частые вопросы;
- правила безопасного использования ИИ;
- каталог реализованных решений;
- календарь практических занятий;
- рекомендации по выбору модели или сервиса.
Особенно полезен формат "одна задача - один разбор". Например: как сократить время подготовки документа, как найти противоречия в техническом тексте, как превратить набор заметок в структурированный отчет. Такой материал проще применить сразу, чем общий обзор тенденций.
Инструмент № 5. Ошибки, которые пришлось проверить на практике
Одна из самых распространенных ошибок - пытаться внедрить слишком много инструментов одновременно. В результате сотрудники теряются, а команда не понимает, какой сервис считать стандартным.
Вторая ошибка - измерять успех только количеством зарегистрированных пользователей или числом проведенных обучений. Эти показатели отражают активность, но не доказывают полезность. Важнее отслеживать сокращение времени на операцию, снижение числа ошибок, рост качества документации и долю процессов, где ИИ действительно используется регулярно.
Третья проблема - запускать решения без владельца. Если после пилота никто не отвечает за поддержку, обновление данных и сбор обратной связи, даже удачный прототип быстро перестает быть актуальным.
Наконец, не стоит скрывать неудачные эксперименты. Публичный разбор того, почему не сработал определенный подход, экономит коллегам время и формирует реалистичные ожидания.
Как понять, что команда стала AI-first
AI-first - это не ситуация, в которой каждый сотрудник постоянно использует нейросеть. Скорее, это способ проектировать работу: команда автоматически рассматривает ИИ как один из возможных инструментов при решении новой задачи.
Для оценки зрелости можно использовать несколько уровней:
1. Осведомленность: сотрудники знают основные возможности и ограничения ИИ.
2. Личное применение: нейросети используются для отдельных операций.
3. Повторяемые сценарии: появляются шаблоны и устойчивые рабочие практики.
4. Командные процессы: ИИ встроен в регламенты, продукты и внутренние сервисы.
5. Системное развитие: эффективность решений измеряется, а подходы регулярно пересматриваются.
За полгода реально заметно продвинуться по этой шкале, если не пытаться изменить все процессы одновременно. Реалистичная цель - создать работающую систему диагностики, приоритизации, обучения и масштабирования. Именно она позволяет перейти от разрозненных экспериментов к управляемой трансформации.
Что можно повторить в любой команде
Начинать стоит не с закупки большого числа сервисов, а с честной диагностики. Затем необходимо выбрать несколько задач с понятным эффектом и ограниченным риском, назначить владельцев и заранее определить критерии успеха.
Важно регулярно возвращаться к обратной связи. Если сотрудники не используют решение, это не всегда означает сопротивление. Возможно, инструмент неудобен, требует слишком много ручной работы или не решает реальную проблему.
И наконец, AI-трансформация должна оставаться гибкой. Технологии меняются быстро, поэтому план, составленный на полгода вперед, неизбежно будет корректироваться. Сильная команда - не та, которая заранее угадала все инструменты, а та, которая умеет быстро проверять гипотезы, извлекать выводы и перестраивать систему на основе фактов.
