Привет, Хабр! Я — Даша, отвечаю за обучение руководителей в MTC Web Services, проектирую образовательные продукты для наших лидеров: от коротких программ до длинных траекторий развития.

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

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

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

Как я работала с моделями раньше

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

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

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

Переход на продуктовый подход в работе с ИИ

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

Постепенно мы с коллегами из T&D начали разбираться, чем ИИ может быть полезен нашей функции: читали материалы, изучали внутренние практики, пробовали разные сценарии, делились друг с другом удачными находками. В какой-то момент я присоединилась к внутреннему ИИ-челленджу — выполняла простые, но ежедневные задания, где каждый день предлагался новый способ использовать модель в работе. Регулярность оказалась полезнее самих заданий: появилась привычка искать пользу от ИИ в своих задачах и проектах.

Тогда я и задумалась: если моя работа строится по продуктовому подходу, почему в работе с ИИ я подключаю его только тогда, когда продукт уже фактически спроектирован?

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

Новый проект обучения для руководителей

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

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

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

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

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

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

Ниже привожу рабочую версию промпта, который можно адаптировать под свой проект:

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

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

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

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

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

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

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

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

Уже позже я обнаружила, что похожий подход описывает Anthropic в документации про Extended Thinking. В ней я нашла несколько мыслей, созвучных моему опыту. Во-первых, при сложных задачах полезно дать модели больше времени и ресурсов на рассуждение, прежде чем переходить к финальному ответу. Во-вторых, в многошаговой работе с данными модель может продолжать рассуждение по мере получения новой информации, а не останавливаться на первом ответе. Эти принципы довольно органично вписались в мой рабочий процесс: я стала использовать ИИ не только для генерации решений, но и для последовательной проверки гипотез и пересмотра своих выводов. 

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

Контекст важнее промпта

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

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

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

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

Как я теперь использую ИИ в работе 

С чем еще мне теперь помогает ИИ? Неожиданно, но с проверкой самого запроса.

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

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

Хороший пример появился в одном из текущих проектов. По результатам внутренних интервью сотрудники регулярно указывали на нехватку обратной связи и качественных 1-1. При этом сами руководители почти никогда не приходили с запросом научиться проводить такие встречи и в большинстве случаев вообще не считали это зоной своего развития.

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

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

Самая сложная часть проектирования — не придумать решение, а правильно сформулировать проблему, которую оно должно решить.

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

Схема моей работы сейчас

Если собрать все эти изменения в один процесс, становится видно, что ИИ сдвинулся в моей работе из конца цепочки в ее начало. 

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

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

Многим не нравится выражение thinking partner — звучит так, будто ИИ думает вместо человека. По моему опыту, происходит обратное: он заставляет думать больше и глубже.

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

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

Что все это значит для T&D

Если посмотреть шире, мне кажется, что меняется не только рабочий процесс.

Долгое время значительная часть работы T&D-специалиста была связана с созданием образовательного контента. Сейчас многие задачи этого уровня ИИ действительно выполняет быстро и достаточно качественно.

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

Роль T&D не становится проще или сложнее — меняется ее фокус. Меньше времени уходит на производство контента, больше — на исследование, проектирование, проверку гипотез и формирование работающего продукта.

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

Значение приобретают вещи, которые ИИ пока не заменяет: практика, обратная связь, обсуждение с коллегами, работа с экспертами, разбор реальных кейсов, возможность попробовать новый подход и получить фидбэк. T&D постепенно смещается в сторону peer-to-peer.