Меня зовут Сергей Иванов, я руковожу направлением цифровизации проектного управления.
Мой профессиональный путь начался еще в то время, когда границы между ролями были гораздо менее выражены: разработчики сами формулировали требования и тестировали свои решения, аналитики нередко одновременно управляли проектами, а ИТ во многих компаниях воспринималось скорее как поддерживающая функция, чем как один из драйверов развития бизнеса.
Я начинал карьеру не в ИТ, но постепенно оказался именно на стыке технологий и проектного управления. Со временем возглавил ИТ-проектный офис в АТОН, а затем перешел на директорскую позицию в БКС.
Все эти годы меня не отпускала одна идея: каким может быть проектный офис, если не просто автоматизировать отдельные операции, а действительно сделать его цифровым. Таким, где между событием и реакцией на него проходят не недели, а минуты; где решения принимаются на основании фактов, а не ощущений; где руководитель проекта не тратит значительную часть времени на сбор данных и подготовку очередной презентации, а занимается тем, ради чего существует его роль, – ведет проект к результату.
История Эйры для меня во многом стала историей того, как эта идея начала превращаться в реальность.
Вместо вступления
Был конец квартала, и я сидел в пустом офисе, глядя на три открытых окна на двух мониторах.
Слева — презентация с планом проекта. Диаграмма Ганта, красивые вехи, зелёные галочки. Посередине — Jira с фактическим выполнением задач. Часть задач просрочена, часть в работе дольше, чем планировалось. Справа — Confluence, где в протоколе последней встречи менеджер написал: «Обсудили риски по поставщику, нужно зарегистрировать». Я открыл реестр рисков. Риск не зарегистрирован.
Три источника. Три версии реальности. И ни одной, которой можно доверять без сверки с остальными.
Я потратил тогда примерно полтора часа, чтобы собрать цельную картину по одному проекту: сверить план с фактом, вытащить из протокола то, что не попало в формальный реестр, сопоставить даты, отметить расхождения. Полтора часа — на один проект. А их у нас больше сотни, из которых около семидесяти в активной фазе. И такие срезы нужны регулярно: квартальные, полугодовые, годовые, не считая оперативных.
Я закрыл ноутбук и подумал: дело не только в скорости. Пока сведения о проекте живут в разных системах и не связаны между собой, каждая сверка требует ручной работы, а важный сигнал может затеряться между источниками. Этот эпизод хорошо объясняет путь, который за два года привёл нас к Эйре.
Первое, что пришлось признать
Когда мы начали думать про ИИ в проектном управлении, было много соблазнов: взять готовое решение, купить коробку, запустить пилот. Мы довольно быстро отложили эту идею. Главной проблемой был не выбор модели, а разрозненные данные, на которых ей предстояло бы работать.
Планы жили в презентациях, фактическое выполнение — в Jira, договорённости — в протоколах и документации Confluence. Риски, статусы и бюджеты собирались в таблицах и отчётах. Каждый источник обновлялся в своём ритме. Модель, поставленная поверх них без связей и правил проверки, могла бы дать убедительный ответ, но не обязательно верный.
Поэтому первые практические шаги были не про ИИ. Нужно было оцифровать процессы, связать ключевые сущности — планы, статусы, риски, команды, комитеты — и определить, где брать факты. Эта часть истории менее эффектна, чем разговор с помощником, но без неё Эйре не на что было бы опереться.
Платформа, с которой всё началось
Мы создали Платформу проектного управления. Её ядром стал Microsoft Project Server: календарно-сетевое планирование, единый пул ресурсов и проектные календари. Переизобретать эту часть не было смысла. А вокруг ядра мы построили прикладные модули под процессы компании: проектные и управляющие комитеты (ПК/УК), риски, бюджет, статусы, команду, запросы на ресурсы, инициативы, поручения ПК/УК, аллокации, метрики проекта и ключевые вехи.
Каждое из этих слов заслуживает отдельного разговора. Вместе модули образуют рабочую систему, которая помогает вести проекты по принятым у нас правилам и одновременно формирует структурированную картину происходящего. Это и стало основой для аналитики, а затем — для Эйры.
Готовую систему под наши процессы мы не покупали: прикладную часть создавали внутри компании на корпоративных сервисах и инфраструктуре. Поэтому Эйра опирается не на абстрактный шаблон проектного управления, а на данные и правила, с которыми работает наша команда. В июне 2026 года она начала регулярный фоновый анализ проектов и стала помогать находить отклонения, которые трудно отслеживать вручную по всему портфелю.
Скажу честно: в одиночку такое не собирается. Проектный офис формирует процессы и проверяет сценарии на практике; ИТ-команды обеспечивают платформу, инфраструктуру и интеграции; команды ИИ — доступ к моделям и технологический контур; ИБ — требования к работе с данными. Продуктовую логику, архитектуру и значительную часть реализации Эйры я веду лично, опираясь на эту совместную основу.
Архитектура: как устроена Эйра
Если убрать технические названия, путь выглядит так: источники данных → подготовка фактуры → анализ и диалог → рекомендация или черновик → решение человека. Для разных данных этот путь устроен по-разному: строгие поля можно читать как факты, свободный текст сначала нужно разобрать.
Источники данных
Платформа даёт Эйре структурированные данные проекта: план, статусы, риски, бюджет, команду, ресурсы, метрики и другие объекты. В диалоге помощник получает нужные сведения через ограниченные инструменты чтения с проверкой доступа к проекту.
Jira дополняет картину фактическим состоянием работ. В чате, когда интеграция доступна, Эйра может обратиться к текущим полям задач Jira. Для регулярного анализа используется подготовленный снимок задач Jira и их сопоставления с планом: так проверка всего портфеля не зависит от сетевого ответа Jira по каждому проекту.
Связанные с проектом страницы Confluence и текстовые поля задач Jira дают иной тип сведений — договорённости, замечания, открытые вопросы и ранние признаки риска.
Слой интеграции
Структурированные сведения платформы читаются из её текущих данных. У диалога есть отдельный инструмент для чтения доступных Эйре задач Jira онлайн. Параллельно два конвейера примерно каждые 30 минут проверяют изменения в связанных источниках: один — в текстах задач Jira, другой — на страницах Confluence.
В результате текстовый конвейер сохраняет не копии документов для свободного поиска, а выделенные из них факты с привязкой к проекту и источнику. Отдельно сохраняется снимок состояния задач Jira и расхождений с планом. Так Эйра может сопоставлять то, что отражено в формальных объектах, с тем, что было зафиксировано в рабочем контексте.
Подготовленная фактура
Свободный текст разбирается во внутреннем ИИ-контуре. Из него выделяются конкретные утверждения: например, договорённость, зависимость, открытый вопрос или сигнал о риске. Результат получает ссылку на исходную задачу или страницу, чтобы человек мог проверить первоисточник со своими правами.
Выделенные факты сохраняются в базе данных. Там же отдельно хранится снимок структурированного состояния задач Jira. Исходный текст остаётся в своей системе; Эйра работает с подготовленной фактурой и при необходимости показывает, где проверить первоисточник.
Анализ и инструменты
В регулярном анализе Эйра собирает данные проекта, проверяет вычисляемые показатели и передаёт модели ограниченный контекст для объяснения отклонений и подготовки рекомендаций. В этом контуре агентный запуск построен на PydanticAI. Часть выводов — например, вычисляемый индикатор состояния — определяется кодом, а модель помогает сформулировать смысл и следующий шаг.
В чате путь начинается с вопроса пользователя. Эйра выбирает подходящие инструменты чтения: карточку проекта, риски, статус, план, задачи Jira или подготовленные факты из текстов. Инструменты возвращают данные в рамках доступного проекта; после этого помощник отвечает на вопрос. Он может также предложить подготовить черновик действия. Это позволяет обсуждать конкретную ситуацию, не рассчитывая на «память» модели о проекте.
Механизм черновиков
Вывод Эйры и изменение в проекте — разные шаги. Если обнаружено отклонение, помощник может подготовить предложение по конкретному объекту: например, риску, статусу, метрике или участию ресурса. Предложение хранится как черновик и показывается человеку вместе с полями, которые требуют проверки или заполнения.
Пользователь может скорректировать предложение, применить его или отклонить. Применение проходит через штатный механизм соответствующего модуля, с его правилами и правами доступа. Эйра подготавливает работу, но не принимает управленческое решение за владельца проекта.
Интерфейсы
У Эйры несколько точек встречи с пользователем: обзор портфеля, карточка проекта, рекомендации и интерактивный чат. Регулярный анализ запускается по расписанию; его результаты видны в проекте, а предложения, требующие реакции, могут попадать во входящие пользователя.
Есть и анализ по запросу: пользователь запускает проверку проекта, задача проходит через очередь и тот же аналитический контур, после чего результат появляется в интерфейсе. Чат позволяет задать уточняющий вопрос и перейти от вывода к подготовке следующего действия.
Безопасность и ИБ-контур
Для разных задач используются разные модели и контуры. Автоматический разбор свободных текстов Jira и Confluence выполняется внутренней моделью. Диалог и аналитика работают через корпоративный AI Gateway; в зависимости от сценария там могут использоваться и внешние модели.
Синхронизируемые описания задач Jira и страницы Confluence сначала разбирает внутренняя модель. В диалог и регулярный анализ из этого конвейера поступают выделенные факты, а не полные тексты источников. Доступ к проектным данным проверяется при выполнении инструментов, а применение изменений остаётся за человеком и штатными правилами Платформы. Новые источники и сценарии проходят отдельную проработку требований к данным и доступам.
Рождение диалога
10 сентября 2026 года мы запустили интерактивный чат. У Эйры появилась новая форма работы: теперь пользователь может сам задать вопрос по проекту, уточнить вывод регулярного анализа и попросить подготовить следующий шаг.
Проще всего показать это на примере. Руководитель спрашивает: «Какие риски в проекте „Омега“ могут возникнуть из-за поставщика?» Раньше ему пришлось бы открыть задачи Jira, найти протоколы встреч в Confluence, свериться с планом и реестром рисков. Теперь Эйра может собрать доступные ей данные, найти уже зафиксированный в протоколе сигнал о возможной задержке и показать, что соответствующего риска пока нет в реестре. После проверки источника руководитель решит, стоит ли регистрировать риск.
Речь не о предсказании будущего. Эйра помогает заметить то, что уже записано в рабочих материалах, но ещё не отражено в формальных процессах. Человек может пропустить такой сигнал не из-за невнимательности: у него просто нет времени перечитывать все связанные материалы по десяткам проектов.
«Черновик»: принцип, который решает больше, чем технологии
Для меня важнейший принцип Эйры — возможность довести анализ до подготовленного действия, сохранив решение за человеком.
Например, официальный статус проекта может оставаться благополучным, хотя в плане, бюджете или задачах накопились отклонения. Эйра показывает основания вывода и может подготовить проект нового статуса. Руководитель проверяет факты, редактирует поля и только затем решает, применять ли изменение.
Тот же подход работает с другими объектами: рисками, метриками, участием ресурсов. Набор поддержанных действий развивается постепенно, поэтому рекомендация не всегда сопровождается готовым черновиком. Но принцип остаётся одним: помощник собирает и сопоставляет факты, предлагает следующий шаг, а ответственность за решение несёт человек.
1500 сигналов и что за ними стоит
За первую неделю регулярной работы Эйра сформировала более 1500 сигналов и замечаний разной значимости. Я специально не начал с этой цифры: она легко читается как маркетинг. Сама по себе она ещё не говорит о качестве — среди сигналов нужно отделять существенные отклонения от информационного шума.
Но она показывает масштаб работы, которую теперь можно выполнять систематически. По всему активному портфелю проверяются данные, которые раньше приходилось сверять вручную: состояние плана, актуальность статуса, бюджет, риски, вехи, ресурсы и другие признаки. Проектный офис может начинать с исключений и противоречий, а не последовательно перечитывать каждый проект. Это другой режим работы.
Меня спрашивают, сколько часов это сэкономило. Пока мы не спешим переводить эффект в такую цифру: для неё нужно накопить статистику. Но уже сейчас мы начали регулярно делать работу, которая раньше в таком масштабе была практически недоступна. Ценность Эйры — в более предметном контроле и более коротком пути от обнаруженного вопроса к решению.
Главный KPI
Мы довольно быстро определились с тем, что главный KPI Эйры — не число диалогов и не количество сигналов. Нас интересует доля рекомендаций, которые пользователь проверил и превратил в действие. Если предложение не помогает выбрать следующий шаг, это просто дополнительный информационный шум — пусть и хорошо сформулированный.
Дальше важно измерять время от сигнала до реакции и то, как меняется качество проектных данных и решений. Эти показатели помогут понять, приносит ли Эйра пользу за пределами красивого диалога.
Чего Эйра не делает
Про ограничения обычно пишут меньше, чем про возможности, поэтому скажу о них отдельно. Эйра не заменяет руководителя проекта и не меняет проектные данные по собственному решению. Она не может достоверно рассказать о том, чего нет в доступных ей источниках, и должна обозначать нехватку данных. Если договорённость осталась только в разговоре, помощник её не увидит.
Это не оговорка мелким шрифтом, а рабочие границы системы: вывод Эйры — основание для проверки и решения, а не готовый управленческий вердикт.
Куда идём дальше
Эйра стала интеллектуальным слоем Платформы проектного управления. Следующий этап — глубже связать анализ отдельного проекта с картиной всего портфеля, улучшать работу с планом и задачами и развивать сценарии, в которых помощник сам обращает внимание на значимое изменение.
При этом проверяемость источников и человеческое решение остаются обязательными. Мы расширяем возможности постепенно, опираясь на рабочие сценарии Проектного офиса и наблюдая, какие рекомендации действительно приводят к полезному действию.
Что я считаю главным результатом
Для меня главный результат шире запуска чата или отдельной модели. За два года мы выстроили цифровую основу проектного управления и научились превращать её данные в регулярный анализ и подготовленные действия.
Внутри компании сложилась компетенция, позволяющая пройти путь от управленческой задачи до работающего решения. Продуктовую логику и основную реализацию Эйры я веду лично, а устойчивость результата обеспечивают общие процессы и команды: Проектный офис, ИТ, специалисты по ИИ и информационной безопасности. Эйра стала заметным результатом этой работы — и инструментом, который можно дальше развивать вместе с Платформой.
Автор: Leite
