Программу написали под один уровень команды. Замер показал другой

Заказчик — руководитель технологического направления. Запрос звучал так: несколько инженерных команд, ИИ каждый применяет по-своему, нужно за восемь недель довести людей до работы через агентов.

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

Поэтому перед первым занятием мы поставили замер.

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

Модули закрывали правильные зоны — но написаны они были под команду, которой в действительности не оказалось. Структура устояла, наполнение переписано почти везде, и это уложилось в согласованный объём правок.

Как это выглядит на одной развилке из шестнадцати.

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

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

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

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

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

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

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

Предстартовая диагностика — самостоятельный этап со своим результатом. Она отвечает на три вопроса: где команда сегодня, чему её учить и по чему станет понятно, что обучение сработало. Результат этапа — документ с картой уровня, планом и рабочими материалами.

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