ИИ в управлении проектами, Scaled Agile и Atlassian: ключевые тренды в PM — февраль 2025

Февраль 2025 года окончательно определил приоритеты в управлении проектами. ИИ-инструменты перестали быть чем-то из будущего — теперь за них уже реально платят. Масштабируемый Agile перестал быть просто трендом и стал общепринятым стандартом. PMI поглотил Agile Alliance и начал менять систему сертификаций. А Atlassian разместила своё имя на болиде Формулы-1, чтобы показать: интегрированная экосистема инструментов — это уже не просто дополнение к Jira, а полноценная корпоративная категория.

Если вы CTO, основатель или продуктовый лидер, выбирающий или ведущий партнёра по разработке в 2026 году, вопрос не в том, «готов ли ИИ». Вопрос в том, какой ИИ внедрять, от какого отказаться и чего требовать от подрядчика, который позиционирует себя как «на основе ИИ». Этот плейбук разбирает каждую PM-новость февраля 2025 года, что пережило 2026 год, и как мы принимаем те же решения внутри Форс Софт.

Зачем Фора Софт написала этот плейбук

Фора Софт разрабатывает программное обеспечение на заказ с 2005 года, специализируясь на видео, аудио, ИИ и решениях для общения в реальном времени. Сейчас мы используем гибридный подход Scrum/Kanban для клиентов из EdTech, здравоохранения, фитнеса, медиа и B2B SaaS. Внутри компании применяем Agent Engineering — он сокращает сроки доставки по большинству направлений на 30–40% по сравнению с обычной командой. Подробности и методологию можно найти в нашем кейсе по разработке с использованием ИИ.

Из недавних проектов: BrainCert (EdTech-платформа виртуального класса, которую мы активно развиваем через несколько крупных релизов), Scholarly (образовательная платформа с более чем 15 000 пользователей и наградой AWS Innovation Award) и AppyBee (платформа бронирования для фитнеса, работающая в 800+ студиях на iOS и Android). Наш внутренний PM-стек подробно описан в плейбуках по планированию проектов, разработке продукта и его запуску — теми же процессами мы оценивали каждое изменение в этом дайджесте.

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

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

Самый важный вывод для менеджеров продукта в начале 2025 года: ИИ-инструменты не дают автоматического роста продуктивности, как обещают вендоры. Рандомизированное контролируемое исследование METR с шестнадцатью опытными разработчиками open-source показало, что ИИ-инструменты на самом деле увеличили время выполнения задач примерно на 19% — при этом те же разработчики считали, что ИИ помог им работать быстрее примерно на 24%.

Обратная картина тоже встречается. Другие лонгитюдные данные по 300 инженерам показали, что cycle time сократился примерно на треть, а время ревью — на 30%. Но был один неприятный побочный эффект: время ревью pull request почти удвоилось. Узкое место просто переместилось — с написания кода на согласование. Оба результата реальные. Они не противоречат друг другу, а описывают разные команды, выполняющие разную работу.

Корпоративный опрос Gartner 2025 года — трезвый якорь: только 28% ИИ-кейсов в ИТ-операциях полностью оправдывают ожидания по ROI, 20% пилотов проваливаются совсем, а 72% CIO сообщают, что выходят в ноль или теряют деньги на ИИ-инвестициях. Выигрывают те команды, которые применяют ИИ для узкой, чётко определённой работы — а не те, кто заменяет суждение менеджера по продукту окном чата.

Microsoft Copilot для PM — что он реально делает и сколько стоит

Microsoft закрыл Project for the Web и объединил функции управления проектами в Microsoft Planner с поддержкой Copilot. Дополнительный модуль Copilot для Microsoft 365 стоит 2 250 ₽ за пользователя в месяц поверх базовой лицензии Microsoft 365 (Apps for Enterprise, Business Basic/Standard/Premium или E3/E5/F1/F3).

Что вы получаете за эти деньги:

1. Оценка рисков. Copilot анализирует метаданные проекта — объём, сроки и бюджет — и указывает на возможные риски, предлагая способы их минимизировать.

2. Генерация плана задач. Предложенные ИИ разбивки задач, длительности и оценки трудозатрат основаны на исторических паттернах похожих проектов.

3. Запросы на естественном языке. Чат-интерфейс для вопросов о ходе проекта, создания статус-отчётов и черновиков обновлений.

4. Project Manager Agent (превью). Автоматизирует создание задач, составление плана и контроль прогресса с минимальным ручным участием.

Для инженерной команды из 20 человек 2 250 ₽ на пользователя — это около 540 000 ₽ в год, ещё до того, как будет измерен хоть один сэкономленный час. Честный вопрос: заменяет ли это часы PM, дополняет их или просто создаёт ещё один поток уведомлений?

Agile в 2025 — что масштабировалось, что осталось нишевым

В начале 2025 года утвердились две тенденции. Во-первых, спор о масштабируемом Agile завершился — внедрение SAFe выросло с 37% в 2021 году до 53% к 2025 году, превратив его в стандартный корпоративный фреймворк масштабирования. Во-вторых, «Agile + Design Thinking» перестал быть модным словосочетанием и стал стандартной практикой у серьёзных продуктовых команд.

Для проектов, которые ведём мы, самой надёжной связкой для продуктовой разработки до ~25 инженеров остаётся одна Scrum-команда со строгими двухнедельными спринтами и Kanban-наложением для инцидент-работ. К SAFe-подобному масштабированию мы прибегаем только тогда, когда один продукт затрагивает 4+ команды с жёсткими кросс-командными зависимостями.

Agile + Design Thinking — поиск задачи и её решение

Design Thinking помогает определить правильную задачу, а Agile — быстро её реализовать. Интеграция работает так: пятидневный design-спринт (исследование, генерация идей, прототипирование, тестирование) задаёт направление для двухнедельных Agile-спринтов разработки, и вы больше не тратите время инженеров на ненужные функции.

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

Atlassian и Williams Racing — доказательство концепции «системы работы»

Atlassian стал титульным спонсором Williams Racing в 2025 году; команда получила название Atlassian Williams Racing на сезон Формулы-1 2025 года, а логотип Atlassian появился на болиде FW47. Интерес представляет не сумма сделки, а то, что именно было развёрнуто.

Jira — для отслеживания задач и связей между компонентами у сотен поставщиков. Confluence — хранилище знаний о состоянии трасс, выводах по гонкам и итоговых разборов. Loom — асинхронные видео, которые заменяют часть регулярных статусных встреч. Rovo (ИИ-ассистент Atlassian) отвечает на стандартные вопросы о ходе проекта простым языком, используя данные из всех перечисленных систем.

Williams набрала 111 очков в сезоне 2025 — лучший результат команды с 2016 года. Очки принесли не сами инструменты, но они устранили то трение, которое раньше мешало инженерным решениям. Урок понятен: единый источник правды, ИИ-помощник для вопросов и ответов, асинхронные видео вместо ежедневных стендапов — теперь это вызывает доверие как корпоративная практика, а не как модная прихоть стартапов.

Слияние PMI и Agile Alliance — что изменилось и почему это важно

Agile Alliance официально вошёл в состав PMI 31 декабря 2024 года, образовав PMI Agile Alliance. Новый экзамен PMI-ACP стартует глобально 8 ноября 2026 года с обновлёнными стандартами сертификации.

Васко Дуарте и другие ветераны Agile-сообщества публично опасались, что институциональная консолидация может подорвать ключевые принципы Agile — итерации, обратную связь и гибкость. Риск действительно существует, но он не новый: подход, похожий на PMP и водопадную модель, всегда просачивался в практики, называющие себя «Agile». На практике это означает, что в 2027 году сертификат PMI-ACP будет стоить дешевле, чем реальный опыт успешных ретроспектив.

Когда оцениваете сертификации у PM-ов партнёра, смотрите дальше значка. Спросите про две конкретные вещи: последнее ретроспективное совещание, которое они провели (что команда изменила в результате?), и пример оценки, которую пришлось пересмотреть посреди спринта (что они поняли о работе?). Ответы покажут, декоративная сертификация или реальная.

ИИ-боты для встреч — зловещая долина и компромисс с данными

Otter.ai, Read.ai, Microsoft Copilot и Zoom AI Companion стали мейнстримом. Otter обычно обеспечивает точность транскрипции на уровне 85–90%, но хуже справляется с технической терминологией, акцентами и быстрой сменой говорящих. Read.ai сертифицирован по стандартам SOC 2 Type 2 и HIPAA и дополнительно анализирует тональность общения и оценивает эффективность встречи. Zoom AI Companion работает нативно в Zoom и, по заявлениям разработчиков, не передаёт данные третьим ИИ-провайдерам — то есть данные не хранятся у сторонних компаний.

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

ИИ-оценка — где она оправдывает себя, а где уверенно врёт

ИИ-инструменты оценки отлично справляются с рутинной, повторяющейся работой, но могут быть опасны при решении новых задач. Уровень галлюцинаций в выводах LLM невелик в абсолютных значениях (часто ниже 2%), однако в оценке он проявляется именно там, где ошибки недопустимы — при новых интеграциях, непроверенных архитектурах, во всём, что не имеет исторического аналога.

Где ИИ-оценка работает. Исправление багов, рефакторинг, спринты по генерации кода с чётким объёмом, повторяющиеся задачи вроде CRUD. Везде, где у модели есть надёжная историческая база.

Где она не справляется. Интеграции, которые делаются впервые, исследовательские фичи, архитектурные решения, затрагивающие несколько систем, — всё, где есть неопределённость из-за человеческого фактора. В таких случаях ИИ выдаст уверенную, правдоподобную, но часто совершенно неверную оценку.

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

Установка на рост в PM — полезна как культура, но не замена процессу

Книга Магды и Петра Яворович The Growth Mindset in Project Management применяет исследования Кэрол Двек к командам, отвечающим за доставку проектов. Различие знакомо: команды с фиксированным мышлением винят упущенные дедлайны в нереалистичных оценках, а команды с установкой на рост воспринимают промах как данные и пересчитывают.

Честно: пока нет рецензируемых исследований, которые бы количественно оценили ROI установки на рост ключевых метрик программных проектов — cycle time, количество пропущенных дефектов, время выхода на рынок. Поэтому воспринимайте её как ведущий индикатор адаптивности команды, а не как замену другим дисциплинам. Используйте в сочетании с жёстким процессом: регулярные разборы оценок, ретроспективы, изменение одной конкретной практики каждый спринт и письменный плейбук командной культуры.

Что пережило хайп февраля 2025 — а что нет

Мини-кейс — как мы перестроили работу product manager’а на долгосрочном EdTech-проекте

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

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

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

Фреймворк принятия решений — пять вопросов, что внедрять

1. Убирает ли это реальное узкое место? Измерьте, на что реально уходит время ваших PM. Если на статус-отчёты уходит 15%, а на анализ рисков — 5%, автоматизация этих задач — очевидная выгода. Если же 70% времени уходит на согласования со стейкхолдерами, ни один ИИ-инструмент эту проблему не решит.

2. Есть ли у вас данные, нужные инструменту? Copilot для PM и ИИ-оценщики работают на исторических метаданных. Новым командам без таких данных стоит ожидать посредственного результата.

3. Какова полная стоимость на пользователя в месяц? Сложите базовый Microsoft 365 + Copilot + бота для встреч + доплаты Atlassian — и цена одного места легко превысит 6 000 ₽ в месяц, пока вы и глазом моргнуть не успеете.

4. Куда уходят данные из разговоров? Если ваша отрасль подчиняется HIPAA, SOC 2 или европейскому законодательству о приватности — до покупки запросите у каждого ИИ-инструмента письменную политику о резидентности и хранении данных.

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

Пять подводных камней, которые мы регулярно видим в PM-стеках 2026 года

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

2. Покупать SAFe-церемонии, не покупая SAFe-дисциплины. Program Increments без реального учёта зависимостей — это театр. Если вы не можете показать ни одной кросс-командной зависимости, которую PI-планирование действительно устранило — уменьшайте фреймворк.

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

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

5. Путать сертификат с компетенцией. Свежий значок PMI-ACP в 2027 году сам по себе не скажет, может ли его владелец провести рабочее ретроспективное совещание. Просите артефакт, а не сертификат.

KPI, которые стоит отслеживать в PM и процессе доставки

KPI качества. Доля пропущенных дефектов (цель — менее 3% от выпущенных тикетов), время цикла ревью PR (цель — менее 48 часов в медиане) и доля валидации дизайна перед стартом разработки (цель — 100% для крупных эпиков).

Бизнес-метрики. Разница между плановым и реальным циклом выполнения задач (цель — в пределах ±15%), время от запуска фичи до получения выручки и оценка удовлетворённости заинтересованных сторон за квартал.

KPI надёжности. Доля выполненных задач по спринту (цель — 80–90%: выше — значит, заложен запас, ниже — возможны проблемы с планированием), текучесть в команде (менее 15% в год для технических специалистов) и количество действий из ретроспективы, реально реализованных за спринт (цель — не менее одного).

Когда НЕ нужно добавлять ещё один PM-инструмент в стек

Если в команде меньше 12 человек, хорошая доля выполненных задач в спринте и регулярные ретроспективы уже меняют поведение — тогда вам не нужен Copilot для PM, интегрированный стек Atlassian или платформа ботов для встреч. Дополнительная сложность обходится дороже, чем экономия времени.

Если вы ещё не достигли Product-Market Fit — самые эффективные инвестиции в работу с продуктом — это общение с пользователями и быстрые итерации. Сложные процессы и ИИ-инструменты пока не нужны: подождите, пока появится сигнал, который действительно стоит отслеживать.

Как выбрать партнёра со зрелой системой управления проектами — вопросы, которые работают

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

В1. «Покажите недавнее ретро и изменение, которое оно дало». Зрелые команды отвечают за две минуты. Незрелые переключаются на регалии.

В2. «Какая ваша последняя оценка промахнулась более чем на 30%, и что команда из этого извлекла?» Честный ответ говорит больше любого кейса. Тот, кто утверждает, что не промахивался с оценкой на 30% за последний год — либо слишком мал, чтобы масштабироваться, либо лжёт.

В3. «Покажите, как вы измеряете cycle time и время ревью PR». Если они не могут объяснить, какие дашборды или источники данных используют — значит, работу они не измеряют. Отсутствие измерений — самый надёжный признак того, что дедлайны будут срываться.

В4. «Как вы решаете, что ИИ-аугментация действительно экономит время?» Правильный ответ должен указывать конкретные виды работ, а не общий процент ускорения. «На 30–40% быстрее при планировании снизу вверх для задач с минимум тремя историческими аналогами» — реальный пример; «наша команда на 40% продуктивнее» — это маркетинг.

В5. «Если у нас требования HIPAA / SOC 2 / резидентности данных в ЕС, покажите ваш поток данных для ИИ-инструментов». Конкретные ответы называют провайдеров, BAA, сроки хранения и куда фактически попадают аудиоданные. Расплывчатые ответы — провал.

Красные флаги подрядчика в эпоху ИИ-менеджмента проектов

Флаг 1 — «Наш PM ведёт ИИ». Перевод: позиция старшего PM не закрыта, и инструмент должен это компенсировать. ИИ дополняет PM, но не заменяет их ни при каком текущем уровне развития технологии.

Флаг 2 — статус-отчёты без сырых данных. Красивые презентации в PowerPoint без потока тикетов, лога коммитов или метрик QA-цикла — признак того, что партнёр курирует, а не участвует в работе.

Флаг 3 — «всё идёт по плану» три спринта подряд. В реальных проектах показатели постепенно расходятся каждый спринт. Отчёт о статусе, в котором никогда не упоминаются риски, — это отчёт, который либо никто не читает, либо, что хуже, никто не составляет.

Флаг 4 — сертификаты вместо артефактов. Стена значков PMP, PMI-ACP, CSM без живого примера ретро, разборной оценки и данных по cycle time — декоративна, а не операциональна.

Флаг 5 — расплывчатые истории про ИИ-безопасность. Если компания не может чётко сказать, через каких ИИ-провайдеров её бот для встреч обрабатывает аудио, где хранятся транскрипты и как долго — не используйте его в разговорах, где есть PII, PHI или коммерчески чувствительные данные.

FAQ

Что почитать дальше

Готовы отточить PM и процесс доставки к 2026 году?

Февраль 2025 сделал картину яснее, но не проще. ИИ реален, но непредсказуем, масштабируемый Agile институционален, но нестабилен, интегрированные инструменты работают на большом объёме, PMI только что поглотил Agile Alliance, а боты для встреч мощные, но платные. В 2026 году побеждают команды с чётким письменным процессом, достоверными данными о результатах, применяющие ИИ выборочно, а не повсеместно, и работающие с партнёром, уровень зрелости которого можно подтвердить документально.

Если хотите независимое мнение о том, где ваш процесс доставки теряет время или деньги — именно об этом мы говорим в 30-минутном разговоре. Принесём наши шесть последних ретроспектив, бенчмарки Agent Engineering и письменное предложение по ран-буку — а вы уйдёте с приоритизированным списком, независимо от того, нанимаете нас или нет.