Меня зовут Даниил Иванов, я руководитель группы аналитики в департаменте CRM&BPM в КОРУСе. Два года назад я уже писал статью, как применяю ИИ в работе аналитика.
Тогда это были первые эксперименты — просто смотрел, чем он может быть полезен. Теперь я стал руководителем, вместо отдельных чатов работаю с корпоративным ИИ-продуктом, у которого есть единый контекст по проектам. И мои запросы к ИИ тоже изменились. Раньше я спрашивал: «Может ли он помочь мне написать протокол?» Сейчас думаю: «Как встроить его в работу команды, чтобы это стало рутиной, как работа с Excel?»
В этой статье поделюсь, как изменилось мое восприятие ИИ за два года, что получилось систематизировать, где ИИ реально экономит время, а где пока упирается в ограничения. В конце — конструктор, где собрал свой опыт работы с LLM.
Точка отсчета: а может ли ИИ мне помочь?
Развитие ИИ и моих навыков работы с ним
Три шага автоматизации
ИИ как +1 аналитик на проекте
ИИ встает на вооружение всей команды
Как масштабировать подход на компанию
Честно об ограничениях
Что дальше
Главный вывод
Точка отсчета: а может ли ИИ мне помочь?
Два года назад я работал аналитиком на проектах по внедрению CRM-систем. В мой типичный рабочий день входили регулярные встречи с заказчиком, бесконечные повестки, описание интеграций, подготовка протоколов встреч и артефактов проектного решения. Рутины было много, она отнимала время, но без нее проекты не двигались.
В тот период я стал экспериментировать с ИИ: пробовал генерировать протоколы по расшифровкам встреч, составлять черновики технических заданий, формулировать письма заказчику. Результат был, но работать так было неудобно.
Я тратил на взаимодействие с ИИ столько же времени, сколько потратил бы на задачу сам, потому что приходилось несколько раз переформулировать запрос, проверять результат, исправлять ошибки и снова давать уточнения. Но это в том числе давало мне ценный опыт самого взаимодействия с ИИ. Я учился с ним работать, углубляясь в доступный инструментарий. Да, на первых порах не получал пользы в виде экономии времени, но зато приобретал новые навыки.
Проблема была не в модели, а в отсутствии процесса вокруг нее. Я не понимал, как ставить задачу, чтобы получить предсказуемый результат. У меня не было структуры и повторяемости.
Развитие ИИ и моих навыков работы с ним
Во-первых, два года технологии не стояли на месте:
● Модели стали работать лучше.
● Многие из них получили пространства единого контекста, куда можно загружать целые проектные документы, а не пытаться впихнуть суть в три абзаца.
● Во многих моделях стал доступен RAG (Retrieval-Augmented Generation) — ИИ может работать с базой знаний, а не только с тем, что ты сейчас ему скормил.
● Многие начали работать с агентами, которые сами проходят часть процесса: находят нужные документы, анализируют их, формируют результат.
● В компаниях, в частности в КОРУСе, появились свои ИИ-контуры, которые работают внутри с корпоративными данными и стандартами.
● Появились специализированные интерфейсы — не просто чаты с моделью, а полноценные рабочие пространства.
Во-вторых, изменились мои инструменты. Два года назад я работал с публичными LLM (ChatGPT, Claude). Сейчас у нас в КОРУСе есть единая безопасная ИИ-платформа KORUS AI, где весь контекст по проектам хранится в едином контуре.
Главное — изменились ожидания. Раньше я приходил к ИИ с настроением «вау, посмотрим, что он выдаст» и воспринимал его как игрушку. Сейчас я жду стабильного, предсказуемого результата, который соответствует моим требованиям. Это рабочий инструмент, который должен давать измеримое качество.
Три шага систематизации
Шаг 1. Библиотека промптов
Я перестал каждый раз формулировать запросы с нуля, а начал собирать библиотеку промптов: шаблоны для протоколов встреч, повесток, черновиков технических заданий, писем заказчику. Одновременно этим стали заниматься и мои коллеги-аналитики. Мы объединили усилия и начали обмениваться удачными промптами и лучшими результатами.
Оказалось, что если промпт структурирован правильно, результат перестает быть лотереей.
Вот пример рабочего промпта для составления протокола встречи
<prompt>
<role>
Ты эксперт по составлению протоколов встреч с клиентами в сфере IT-проектов.
</role>
<task>
На основе предоставленных вопросов и ответов составить протокол встречи в профессиональном стиле.
</task>
<style_requirements>
<structure>
Используй нумерованные разделы с заголовками в верхнем регистре
</structure>
<tone>
Деловой, но живой – используй активные конструкции (“Обсудили”, “Определили”, “Договорились”, “Проговорили”, “Подтвердили”, “Уточнили”)
</tone>
<logic>
Группируй связанные вопросы в абзацы, избегай простого перечисления вопрос-ответ
</logic>
<formulations>
<replace from=”Заказчик ответил” to=”Определили, что…”/>
<replace from=”На вопрос о…” to=”По вопросу… договорились…”/>
<deferred_decisions>Заказчик предоставит информацию позже</deferred_decisions>
<technical_details>Установили, что…, Подтвердили необходимость…</technical_details>
</formulations>
<uncertainty_handling>
<no_answer>Заказчик предоставит информацию позже</no_answer>
<needs_clarification>Решение будет принято позже или Требует дополнительной проработки</needs_clarification>
</uncertainty_handling>
<completion>
Добавь раздел “Следующие шаги” с указанием ожидаемых действий
</completion>
</style_requirements>
<output_template>
<header># Протокол встречи с Заказчиком по проекту [НАЗВАНИЕ ПРОЕКТА]</header>
<sections>
<section>
<title>## [НОМЕР]. [НАЗВАНИЕ РАЗДЕЛА]</title>
<content>[Текст в указанном стиле – группировка вопросов, активные конструкции, логичное изложение]</content>
</section>
</sections>
<footer>
<separator>—</separator>
<next_steps>**Следующие шаги:** [Краткое описание ожидаемых действий и информации от участников]</next_steps>
</footer>
</output_template>
<quality_examples>
<bad_example>
<text>Заказчик сказал, что в системе 1000 пользователей</text>
<label>❌ Неправильно</label>
</bad_example>
<good_example>
<text>Уточнили, что в системе активно работает 1000 пользователей</text>
<label>✅ Правильно</label>
</good_example>
<bad_example>
<text>На вопрос о картах ответили, что нужна полноэкранная</text>
<label>❌ Неправильно</label>
</bad_example>
<good_example>
<text>Определили, что карта будет полноэкранной</text>
<label>✅ Правильно</label>
</good_example>
<bad_example>
<text>Заказчик не знает про API</text>
<label>❌ Неправильно</label>
</bad_example>
<good_example>
<text>Заказчик предоставит информацию по API позже</text>
<label>✅ Правильно</label>
</good_example>
</quality_examples>
<instruction>
Теперь обработай предоставленные вопросы-ответы в указанном стиле, следуя всем требованиям XML-структуры.
</instruction>
</prompt>
Такой промпт задает для ИИ роль, тон, структуру, показывает примеры плохих и хороших формулировок. Результат получается стабильным и требует минимальных правок.
Постепенно библиотека промптов переросла в библиотеку практик. Я добавил описания, чтобы даже новому сотруднику было понятно, для каких задач подходят определенные промпты и как их адаптировать под разные ситуации.
Шаг 2. ИИ получает «память» о проекте
Как я говорил выше, в KORUS AI нам легко работать с проектами, потому что он знает весь контекст: документацию, артефакты, записи встреч, управленческие документы вплоть до плана-графика и ресурсных планов.
Теперь, когда я или кто-то из команды приходит к ИИ с задачей, ему не нужно заново пересказывать, что за проект, какие процессы спроектированы, какие решения уже приняты. ИИ может проанализировать всю документацию и на ее основе подготовить, например, черновик нового артефакта или предложить решение, которое не противоречит тому, что уже спроектировано.
Недавний кейс с клиентом
К нам пришел заказчик с запросом подготовить таблицу с описанием всех уведомлений, которые пользователи получают в CRM-системе в рамках процесса, который мы спроектировали. Задача рутинная, но для ее выполнения нужно перечитать все проектное решение и выбрать из него нужную информацию. Ресурсов на это нет, в исходных артефактах подобный проектный артефакт отсутствует. Первая мысль — хочется отказать.
Вторая — у нас есть инструмент, в котором уже лежит весь контекст проекта. Я написал простой промпт, ИИ сформировал таблицу, мы с командой ее провалидировали и отдали заказчику. Вместо того, чтобы выделять на это человека на несколько часов, мы потратили 20 минут на валидацию результата.
Шаг 3. Знания перестают жить в головах
Когда у ИИ появляется память о проекте, он становится сущностью, которая знает практически все. И иногда даже чуть больше, чем любой отдельно взятый член команды.
Какой эффект это дает:
Новые аналитики быстрее включаются в контекст. Приходит человек на проект, и вместо того, чтобы несколько дней читать документацию, он может задать ИИ вопросы: «Какие процессы уже спроектированы?», «Какие интеграции предусмотрены?», «Какие решения приняты по архитектуре?» — и получить структурированный ответ.
ИИ задает неудобные вопросы. Когда проектируешь какое-то решение, ты априори считаешь его правильным. Но если попросить нейросеть проанализировать его на основе контекста проекта, она может задать вопросы, которые ты сам себе не задал: «А как это сочетается с тем решением, которое мы приняли на прошлой неделе?», «А учтены ли ограничения, которые озвучил заказчик?»
ИИ берет часть валидации на себя. Ты можешь попросить его проверить твой драфт: «Соответствует ли это техническое задание тому, что мы обсуждали на встрече?», «Не противоречит ли это архитектурным решениям?»
ИИ как +1 аналитик на проекте
ИИ экономит время до 20-25% и берет на себя рутину, пока мы можем сосредоточиться на задачах, которые действительно требуют нашего участия.
Что он реально уже умеет делать хорошо:
-
протоколы встреч и повестки — рутина, которую мы спокойно отдаем ему на откуп.
-
черновики артефактов проектного решения: задания на разработку, ЧТЗ, ТЗ, user story.
-
предварительные архитектурные решения — может предложить несколько вариантов на основе того, что уже спроектировано.
-
подготовка повесток на встречи по уточнению требований — делает на основе того, что уже обсудили и что еще непонятно.
При этом мы в команде не гонимся за новейшими моделями. Нам вполне хватает тех, что вышли год назад, потому что в нашей работе есть структура, повторяемость, четкое разделение ответственности.
ИИ встает на вооружение всей команды
Два года назад я был аналитиком, который пытался облегчить себе жизнь. Сейчас я тимлид группы аналитиков — и теперь для меня важно не то, как я сам работаю с ИИ, а как с ним работает вся команда.
Я не хочу научить всех писать «правильные» промпты. Это навык, который можно освоить за пару дней. Моя задача — встроить нейросети в процесс так, чтобы работа с ними стала рутиной, как использование Excel для расчетов или Confluence для документации.
Что я для этого сделал и продолжаю:
-
Подготовил регламент работы с ИИ: как работать с инструментом, какие промпты использовать, какие из них рабочие, как валидировать результат.
-
Сделал библиотеку практик, о которой я говорил выше, общей для всей команды. Любой аналитик может зайти, взять нужный промпт, адаптировать его под свою задачу.
-
Провожу регулярные обсуждения: что сработало, что не сработало, какие новые кейсы появились, какие подходы стоит добавить в библиотеку.
Как масштабировать подход на компанию
Недавно на ИТ-митапе меня спросили, как я «продавал руководству» идею командного использования ИИ. А мне не приходилось даже два года назад объяснять руководству, что в ИИ-инструменты нужно вкладываться.
В КОРУСе топ-менеджмент несколько лет активно каскадирует на сотрудников цели по ИИ-трансформации — у нас есть разные ИИ-инициативы помимо KORUS AI, практики активно появляются, и мы ими обмениваемся. Формально для этого проводятся встречи и сессии. Но реально чаще работает прямой нетворкинг. Я знаю, что коллега из другого департамента придумал классную фичу или способ решить какую-то задачу. Я иду к нему, он делится со мной опытом, я транслирую это на всю команду.
Кроме того, в КОРУСе есть отдельный бот с контекстом, в который загружено большое количество промптов из наработок всех корусян. Если у кого-то появился промпт, который решает конкретную задачу, он довольно быстро попадает в эту базу, и им может воспользоваться любой сотрудник.
Масштабировать опыт сильно проще, потому что не нужно каждый раз заново изобретать, как правильно сформулировать запрос. Достаточно взять рабочий промпт и адаптировать его под свою задачу.
Что делать, если руководство все-таки нужно убеждать
Если вы еще на старте и пытаетесь убедить руководство, что с ИИ нужно работать (и оплачивать токены), — у меня один совет: не приходите с красивой презентацией «нам это нужно».
Приходите с конкретным измеримым результатом: «Мы с командой два месяца использовали ИИ — вот здесь сэкономили 20% времени на подготовке протоколов. Здесь повысили качество черновиков технических заданий, здесь ускорили адаптацию новых аналитиков». К такому диалогу руководство готово всегда.
У нас так и произошло. Как я и говорил, в начале пути для меня это был эксперимент. Я тратил на взаимодействие с ИИ столько же времени, сколько тратил бы на задачу сам. Но в какой-то момент сошлись кривая моей эффективности от работы с нейросетью и кривая реального value, которое можно продать руководству. И это произошло не два года назад, не год назад, а только в этом году. И сейчас работа с ИИ уже часть стратегии развития нашего направления.
Честно об ограничениях
KORUS AI начинался с работы над проектом в едином контексте, но главная цель команды, которая его развивает, — довести платформу до такого уровня, чтобы она полноценно покрывала весь рабочий процесс.
Было бы нечестно сказать, что все работает идеально. Есть фичи, доработок которых моей команде пока не хватает в полной мере.
Подготовка тест-кейсов и инструкций пользователя-администратора. В этом процессе есть высокая зависимость от самой платформы т.к. мы работаем с отечественными CRM-системами, и они не всегда достаточно представлены в знаниях зарубежных моделей. По началу ИИ часто не мог предложить корректный тест-кейс, если не понимал, как именно работает конкретная функция системы.
Теперь на платформе появился «Навигатор систем», где есть документация от вендеров, а также агенты, которые сами изучают нужную систему. Аналитик может задавать вопросы об устройстве разных платформ и просить создавать те самые тест-кейсы. Пока это тестовый контур, навигатор технически подключен к нескольким платформам, идут проверки, насколько хорошо агенты разбираются в логике конкретных систем и что получается на реальных задачах. Жду, когда смогу полноценно встроить работу с навигатором в сложившуюся рутину команды.
Ручной перенос данных между платформами. Мы ведем проектную документацию в Confluence, а контекст для ИИ живет в KORUS AI. И между ними сначала не было автоматической интеграции. Раз в неделю команда стабильно тратила несколько минут на ручную выгрузку актуальных артефактов.
Без интеграции процесс не разваливался, потому что были разделены зоны ответственности:
Тимлид (это я) синхронизирует библиотеку промптов, следит за актуальностью практик и тем, чтобы команда знала, как работать с инструментом.
Ведущий аналитик на каждом конкретном проекте отвечает за корректность контекста по проекту, следит, чтобы в него попадали актуальные артефакты, и валидирует драфты.
Аналитик работает над финальным артефактом: берет драфт от ИИ, проверяет его, дорабатывает и выдает результат для ведущего аналитика.
Такое разделение помогало нам справляться с тем, что контекст не всегда был синхронизирован, а драфты идеальны. Совсем недавно интеграция технически появилась — ждем ее релиза на команды, чтобы протестировать на реальных задачах и снять с себя еще часть нагрузки.
Если подытожить, то несмотря на ограничения, постепенно закрываем все больше рутинных задач и освобождаем время моей (и не только) команды на анализ требований, проектирование сложных процессов, коммуникацию с заказчиками и другие задачи, где ИИ не может заменить специалиста на должном уровне.
Что дальше
Следующий уровень — научиться работать с ИИ так, чтобы он сам проходил часть процесса без участия аналитика. Речь идет и о полноценном RAG, когда нейросеть сама находит нужные документы, анализирует их и формирует результат, и про ИИ-агентов, когда ИИ выполняет последовательность действий: от изучения контекста до выдачи финального результата.
Главный вывод
Дело вообще не в модели, а в том, как ты выстраиваешь работу вокруг нее. Если ты работаешь в новейшей модели, но каждый раз формулируешь запрос с нуля и не знаешь, что получишь, — это все еще эксперимент, а не продвинутый уровень работы с ИИ.
И еще одна важная вещь: мой личный уровень задач вырос. Я давно не пишу ни протоколов, ни повесток — это делают ребята в команде с помощью ИИ. Я занимаюсь тем, что слежу за распределением ресурсов на проектах, за тем, чтобы вся команда аналитиков гармонично развивалась, получала индивидуальные планы развития и конструктивную обратную связь на Performance Review. И здесь ИИ не решает эти задачи за меня, но он является для меня хорошим источником идей и инструментом, который позволяет структурировать мои мысли.
Делюсь конструктором, где собрал опыт работы с LLM, советы и некоторые примеры промптов.
Расскажите, как у вас в командах выстроена работа с ИИ? Что получилось встроить в процессы, а что не работает? Делитесь опытом в комментариях — интересно собрать коллективную картину того, как ИИ меняет работу аналитиков, разработчиков, менеджеров.
Автор: vibaeva_says
