Дивитись усі Новини

ШІ в керуванні проєктами: де він реально працює, а де поки що просто красиво звучить

04.09.2026
ШІ в керуванні проєктами: де він реально працює, а де поки що просто красиво звучить

Ще у 2019 році Gartner опублікував прогноз, який на той момент виглядав як провокація: до 2030 року штучний інтелект забере на себе близько 80% задач проєктного менеджменту.

Минуло сім років. Ми приблизно посередині цього прогнозу — і вже можна спокійно сказати, що саме малося на увазі.иНе «менеджера замінить робот». А «80% адміністративної рутини, яку менеджер сьогодні робить руками, перестане бути роботою людини».

Різниця тут принципова. І саме її найчастіше не помічають, коли обговорюють ШІ в управлінні проєктами.

 

Спочатку розберемося, куди насправді йде час менеджера

Є одне дослідження, яке добре повертає до реальності. Asana колись порахувала, що офісні працівники витрачають близько 60% робочого часу на «роботу навколо роботи»: збір статусів, уточнення, переписування одного й того самого різними словами для різних людей.

Wellingtone у своєму щорічному звіті додає ще одну деталь: половина компаній витрачає щонайменше один повний робочий день на місяць лише на те, щоб зібрати актуальний статус по проєктах. Не проаналізувати. Просто зібрати.

Тепер уявіть проєктного менеджера, який веде п'ять активних проєктів. Скільки з його тижня — це рішення, пріоритизація, перемовини, тобто те, за що його насправді цінують?

І скільки — це «переклади»? Клієнт сказав словами бізнесу — треба перекласти мовою розробника. Розробник відписав словами технічними — треба перекласти назад. Зустріч закінчилася — треба перекласти годину розмови в п'ять пунктів домовленостей. Місяць закінчився — треба перекласти виконані задачі в акт і рахунок.

Ось тут ШІ і виявився дуже доречним. Не як «розум», а як дуже швидкий і дуже витривалий перекладач між форматами.

 

Що змінилося за останні два роки

Цікава річ: інструменти з'явилися у всіх майже одночасно, а от системного використання досі майже немає.

За даними PMI, лише близько третини організацій впровадили ШІ в проєктні процеси хоча б у помірному обсязі, і лише 12% — суттєво. У технологічних компаніях цифра вища, близько 34%, але й це далеко не «всі».

А дослідження APM показує ще красномовнішу деталь: 68% проєктних менеджерів кажуть, що їм бракує навчання роботі з цими інструментами.

Тобто картина така: доступ є в усіх, навички — у половини, спільних правил — майже ні в кого.

Це трохи схоже на компанію, яка купила всім співробітникам автомобілі, але не побудувала доріг. Хтось поїхав швидко. Хтось стоїть. Хтось поїхав у протилежний бік, і всі дізналися про це через місяць. Ми пройшли рівно цей шлях. І саме тому далі буде не про технології, а про процеси.

 

Як це виглядає у нас

Ми в Molfar впроваджуємо ШІ не як окремий «модний проєкт», а точково — там, де є повторювана робота з текстом і структурою. Наразі це шість напрямів.

 

Постановка задач розробникам. Клієнт описує проблему так, як він її бачить: «кошик поводиться дивно на мобільному». Задача для розробника має виглядати інакше — з умовами відтворення, очікуваним результатом, критеріями готовності. Раніше якість цього переходу залежала від того, наскільки менеджер сьогодні уважний і наскільки він не поспішає. Тепер чернетка формується за єдиною структурою, а менеджер її вичитує й доповнює контекстом, який знає тільки він.

Ефект тут вимірюється просто. Раніше одна нормально описана задача забирала близько години. Зараз за ту саму годину менеджер робить п'ять задач разом із вичиткою.

 

Технічна документація. Найчастіше документація не пишеться не тому, що вона нікому не потрібна, а тому, що на неї ніколи немає часу. Коли чернетка опису модуля чи інтеграції з'являється одразу після реалізації, шанс, що документ дійсно доживе до фінальної версії, різко зростає.

Окрема історія — функціональні вимоги. Раніше на опис нового блоку функціональності йшов тиждень, і це ще до того, як починалося погодження з клієнтом. Зараз цей етап скоротився приблизно втричі. І, що важливіше, погодження стало коротшим: коли клієнт бачить структурований документ, а не потік думок, у нього з'являються конкретні правки, а не загальне відчуття, що «щось тут не те».

 

Первинні документи — акти та рахунки. Наприкінці місяця треба зібрати те, що зроблено, і перетворити на зрозумілий клієнту перелік робіт. Це чиста механіка, у якій людина втомлюється і помиляється, а машина — ні.

 

Фіксація домовленостей на зустрічах. Найдорожчі непорозуміння в проєктах народжуються не з конфліктів, а з фрази «ми ж про це домовлялися». Розшифровка й структурування зустрічі в короткий перелік рішень та наступних кроків закриває це питання майже повністю. Клієнт отримує підсумок того ж дня і може одразу сказати: ні, ось тут я мав на увазі інше. Це набагато дешевше, ніж дізнатися про це через три спринти.

 

Письмова звітність клієнту. Звіт має бути не переліком тікетів, а відповіддю на питання «що змінилося для мого бізнесу за цей період». Це різні тексти. І другий раніше писався цілий робочий день — тому й з'являлася спокуса відкласти його «на потім» або надіслати те, що швидше. Зараз чернетка формується автоматично, менеджеру лишається година на перевірку й доповнення. Звіт перестав бути подвигом, тому просто почав виходити вчасно.

 

Робота зі статусами задач. Найбуденніше — і, як не дивно, найкорисніше. Актуальний статус у трекері перестає бути результатом того, що менеджер у п'ятницю ввечері обійшов усіх з питанням «ну як там?».

 

Найскладніше почалося не з технологій

Коли шість напрямів запрацювали, ми зіткнулися з проблемою, якої не очікували. Кожен менеджер робив це по-своєму.

Один описував задачі детально, інший — стисло. У одного акт виглядав так, у іншого — інакше. Один фіксував домовленості одразу, інший — коли встигне. Формально всі використовували ШІ. Фактично ми отримали чотири різні школи роботи всередині однієї компанії.

І тут виникає неприємне запитання: а що бачить клієнт?

Клієнт бачить, що якість комунікації залежить не від компанії, а від конкретної людини. Це рівно те, від чого агенція має захищати клієнта.

Тому зараз ми будуємо єдину схему — майстер-шаблон, у якому зафіксовано, як виглядає задача, як виглядає звіт, як виглядає підсумок зустрічі, які дані звідки беруться і хто за що відповідає. Логіка проста. Інструмент дає швидкість. Шаблон дає передбачуваність. Без другого перше просто прискорює хаос.

 

Де ми свідомо не використовуємо ШІ

Це, мабуть, найважливіша частина.

  • Оцінка термінів і бюджету. ШІ прекрасно генерує правдоподібні цифри. Проблема в тому, що правдоподібна оцінка і реалістична оцінка — це не одне й те саме. Оцінку в нас дає людина, яка потім за неї відповідає.
  • Складні розмови з клієнтом. Зрив терміну, перевитрата, помилка на продакшені. Тут потрібен не ідеальний текст, а людина, яка бере відповідальність. Ідеально відшліфований лист у такій ситуації тільки дратує.
  • Фінальне рішення про пріоритети. Машина не знає, що цей клієнт наступного тижня має презентацію інвесторам, а той щойно пережив складний реліз.
  • Конфіденційні дані. Доступи, персональні дані, комерційні умови — за межами будь-яких зовнішніх сервісів. Тут правила простіші за будь-яку методологію: не впевнений — не відправляй.

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

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

Автоматизувати можна підготовку. Відповідальність — ні.

 

Що з цього отримує клієнт

Якщо коротко — не «магію», а речі, які легко перевірити. Задача, яку розробник розуміє з першого разу, а не з третього уточнення. Опис функціональності за два дні замість тижня. Підсумок зустрічі того самого дня. Звіт, написаний людською мовою, а не мовою трекера. Акт, у якому видно, за що саме сплачено.

І менеджер, у якого лишається час на те, заради чого його наймали: думати про проєкт, а не переписувати текст із формату у формат.

Зауважимо чесно: зекономлений час не зникає з проєкту і не перетворюється на знижку. Він переходить у те, на що раніше його просто не вистачало — уважніше вичитування, більше уточнень до старту, швидшу реакцію на зміну пріоритетів. Саме там і ховається різниця між «зроблено за ТЗ» і «зроблено так, як треба бізнесу».

 

Висновок

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

Штучний інтелект не робить проєктне управління розумнішим. Він робить його дисциплінованішим — але тільки тоді, коли дисципліна вже є в самій компанії.

Якщо процеси хаотичні, ШІ прискорить хаос. Якщо процеси описані, він зніме з людей рутину і поверне їм час на рішення.

Тому питання «чи використовуєте ви ШІ» насправді нічого не говорить про агенцію.

Значно цікавіше інше: де саме ви його використовуєте, де свідомо не використовуєте — і хто в підсумку відповідає за результат.

 

Molfar Insight

Ми не віримо, що штучний інтелект замінить проєктного менеджера.

Ми віримо, що він забере в менеджера ту частину роботи, за яку клієнт ніколи не хотів платити — і залишить ту, заради якої менеджера наймають.

 

Потрібен розробник?

Заповніть форму і ми зв`яжемося з вами якомога швидше
LinkedIn
FaceBook
Telegram
Whatsapp