Нетехнічний спеціаліст в IT в епоху ШІ: чому PM і BA залишаються потрібними

PM: не пише код, але допомагає проєкту рухатися

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

Дизайнер чекає на вимоги. Розробник — на дизайн. Тестувальник — на готову функцію. Клієнт очікує реліз у визначену дату, але не бачить, що команда ще не отримала доступу до CRM-системи.

Проєктний менеджер допомагає зібрати всі частини в єдиний процес. Він організовує зустрічі, фіксує домовленості, слідкує за термінами, помічає ризики та прибирає блокери.

Наприклад, клієнт просить додати у поточний спринт ще одну функцію — SMS-нагадування про консультацію. PM не просто відповідає: «Так». Він уточнює, скільки часу це займе, чи є залежність від стороннього сервісу, яку задачу доведеться перенести та чи зміниться дата релізу. Після цього клієнт може прийняти усвідомлене рішення.

Тобто PM відповідає не за написання коду, а за те, щоб команда могла виконати потрібну роботу в реальних умовах.

‍

‍

• Реліз — версія продукту або набір змін, які команда передає користувачам.
• CRM (Customer Relationship Management) — система для роботи з клієнтами: контактами, заявками, продажами та історією комунікації.
• Спринт — короткий період роботи команди, зазвичай один або два тижні, у межах якого вона виконує погоджений набір задач.
• Блокер — проблема або залежність, через яку команда не може продовжувати роботу над задачею.

‍

Як ШІ допомагає проєктному менеджеру

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

Так само PM може використовувати ШІ для підготовки робочих документів:

• Project Charter — короткого опису мети, меж і учасників проєкту;
• WBS — декомпозиції великої роботи на менші частини;
• реєстру ризиків;
• плану комунікації;
• статус-звіту для клієнта;
• agenda для зустрічі або ретроспективи.

Наприклад, PM може передати ШІ очищені нотатки з початкової зустрічі та попросити структурувати їх у Project Charter. У результаті він отримає не фінальний документ, а стартову версію: цілі, scope, обмеження, стейкхолдерів і відкриті питання.

ШІ також може запропонувати типові ризики. Для платформи запису це може бути затримка інтеграції з CRM, відсутність доступів, зміна вимог клієнта або нестача часу на тестування. Але саме PM разом із командою визначає, які ризики справді актуальні та як на них реагувати.

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

‍

‍

• Project Charter — стартовий документ проєкту, у якому описано ціль, межі робіт, ключових учасників, обмеження та критерії успіху.
• WBS (Work Breakdown Structure) — ієрархічне розбиття великого обсягу роботи на менші, зрозумілі частини.
• Реєстр ризиків (Risk Register) — таблиця з ризиками, їхньою ймовірністю, впливом, планом реагування та відповідальними.
• План комунікації (Communication Plan) — документ, який визначає, хто, яку інформацію, коли і через який канал отримує.
• Status update / статус-звіт — короткий звіт про прогрес, ризики, блокери та наступні кроки.
• Agenda — порядок денний зустрічі: теми, які потрібно обговорити.
• Ретроспектива — зустріч команди після спринту або релізу, на якій обговорюють, що спрацювало добре, а що варто покращити.
• Scope — погоджений обсяг робіт: що входить у проєкт і що не входить.
• Стейкхолдери — люди або групи, які впливають на проєкт або зацікавлені у його результаті.

‍

Які навички PM залишаються важливими

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

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

Комунікація — це не просто багато дзвінків. Це вміння вчасно передати правильну інформацію правильній людині. Планування — не гарна таблиця, а розуміння послідовності задач, залежностей і дедлайнів. Управління ризиками — уміння побачити потенційну проблему до того, як вона стане кризою.

Для старту новачку корисно освоїти Trello або Jira для ведення задач, Miro для воркшопів, Google Sheets для простого планування та ChatGPT чи інший ШІ-інструмент для підготовки чернеток.

• Дедлайн — кінцевий термін, до якого задача або результат мають бути виконані.
• Trello — простий онлайн-інструмент із картками та дошками для організації задач.
• Jira — інструмент для ведення задач, backlog, спринтів і відстеження прогресу команди.
• Miro — онлайн-дошка для воркшопів, схем, карт процесів і командної співпраці.
• Google Sheets — онлайн-таблиці для планування, простих розрахунків та аналізу.

‍

А де тут бізнес-аналітик?

Якщо PM відповідає за те, щоб робота була організована і доставлена, то BA допомагає зрозуміти, що саме потрібно створити і чому це важливо для бізнесу.

Повернімося до платформи онлайн-запису. Клієнт каже: «Нам потрібен календар для бронювання». Бізнес-аналітик не поспішає записувати це як готову задачу. Він ставить питання: хто бронює консультацію? Чи потрібна реєстрація? Чи можна скасувати запис? Як уникнути подвійного бронювання? Які дані потрібно передати у CRM?

Потім BA перетворює відповіді на зрозумілі вимоги, user stories та критерії приймання. Наприклад: «Як користувач, я хочу бачити доступні слоти консультанта, щоб обрати зручний час». BA допомагає команді створити не просто календар, а функцію, яка справді вирішить проблему користувача.

ШІ може допомогти BA структурувати нотатки, підготувати список уточнювальних питань, знайти edge cases або створити чернетку user story. Але він не може самостійно вирішити, які правила потрібні конкретному бізнесу.

‍

‍

• Вимоги (requirements) — опис того, що має робити продукт або яку проблему має вирішувати.
• User story — короткий опис потреби користувача у форматі: «Як [користувач], я хочу [дію], щоб [отримати цінність]».
• Критерії приймання (acceptance criteria) — умови, за якими можна перевірити, що задача виконана правильно.
• Edge case — нестандартний, рідкісний або граничний сценарій, який усе одно потрібно передбачити. Наприклад, користувач намагається забронювати вже зайнятий час.
• Бізнес-правило — правило, за яким працює продукт відповідно до потреб компанії. Наприклад, запис можна скасувати не пізніше ніж за дві години до консультації.

‍

PM чи BA: як обрати напрям

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

BA може бути ближчим тим, хто любить розбиратися в деталях, ставити питання, аналізувати процеси та перетворювати нечіткі побажання на зрозумілий план. У бізнес-аналіз часто приходять люди з банківської сфери, HR, операційних команд або підтримки.

Щоб відчути різницю, виконайте два практичні завдання. Для PM — створіть у Trello дошку для запуску умовного онлайн-сервісу. Додайте задачі, дедлайни, ризики та статуси. Для BA — візьміть знайомий застосунок і опишіть, як користувач виконує одну дію. Наприклад, замовляє товар або записується на консультацію. Потім створіть дві user stories для покращення цього процесу.

Такі вправи допомагають зрозуміти роль не з теорії, а на практиці.

• HR (Human Resources) — напрям роботи з персоналом: найм, адаптація, розвиток і підтримка працівників.

‍

ШІ не замінює відповідальність

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

Тому PM і BA мають перевіряти кожну чернетку: чи відповідає вона реальному контексту, чи погоджена з клієнтом, чи можна її виконати ресурсами команди. Також не варто передавати у відкриті AI-сервіси персональні дані, паролі, фінансові показники чи умови контрактів.

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

‍

Висновок

Нетехнічна кар’єра в IT не зникає в епоху ШІ. Вона стає більш інструментальною. Проєктним менеджерам і бізнес-аналітикам не потрібно писати код, але потрібно розуміти процеси, людей, бізнес-потреби та вміти користуватися сучасними інструментами.

PM допомагає команді організовано дійти до результату. BA допомагає переконатися, що цей результат справді потрібен користувачу та бізнесу. А ШІ може стати сильним помічником для обох ролей, якщо використовувати його критично, відповідально й у поєднанні з власним мисленням.

‍