День з життя проєктного менеджера

Ранок. О 08:55 Марина робить каву, відкриває ноутбук і швидко переглядає Slack та Jira: що змінилося за ніч, які нові повідомлення з'явилися, чи виникли критичні задачі. О 09:30 — щоденний стендап-мітинг на 15 хвилин.  Розробники кажуть, що зробили, над чим працюють і які блокери. QА-тестувальник розповідає про те, які баги він виявив, та ставить питання, що і як має працювати. Бізнес-аналітик (BA) розповідає про свої апдейти, а якщо наразі розповісти нема про що — слухає команду, щоб бути в контексті. Один із розробників натякає, що потрібен доступ до API (див. кінець абзацу), яка є у клієнта, без якого розробка функції застрягає. Марина одразу записує це у свій список задач. А QA запитує, яка має бути поведінка таблиці клієнтів, якщо інтеграція видає помилку. Оскільки на проєкті є бізнес-аналітик, то відповість він, бо саме він займається документацією, у якій прописує поведінку системи в різних ситуаціях.

Блокер — певний фактор, що блокує прогрес задачі.

API — посередник, що дозволяє різним програмам обмінюватися даними між собою.

Фіча — англіцизм або сленговий термін, перекладається як “функція”.

Після стендапу — перші дзвінки. Клієнт телефонує з проханням додати ще одну фічу у поточний спринт. Тут починається важлива частина роботи ПМ — управління очікуваннями. Марина пояснює, що додавання вимоги означає два варіанти: або прибрати іншу задачу з поточного спринту, або продовжити терміни. Вона фіксує домовленість у Confluence і просить бізнес‑аналітика підготувати оцінку впливу та, за можливості, чернетки вимог. Це — типовий приклад компромісу. ПМ не каже “ні” автоматично, але конвертує прохання в конкретні наслідки й рішення.

Спринт — певний проміжок часу, за який розробляється функціонал системи

Опівдні — планування з аналітичним акцентом. Разом з BA і трьома розробниками Марина запускає воркшоп у Miro. Вони збирають користувацький шлях, виділяють ключові сценарії і позначають залежності між фічами. На дошці зʼявляються sticky notes із user stories та потоками даних. Марина веде сесію: ставить питання, щоб виявити невизначеності, і просить BA конкретизувати acceptance criteria безпосередньо на дошці. Після узгодження вони переносять підсумкові user stories до Trello — створюють картки, призначають відповідальних, додають чеклісти й орієнтовні оцінки. Для аналітики Марина швидко робить просту оцінку capacity у Google Sheets: скільки story points команда може взяти на спринт, які буфери на ризики. Вона експортує ключові таски з Trello у Jira (або залишає у Trello для менш формальних команд), щоб синхронізувати трекінг.

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

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

User stories — короткий опис функції з точки зору користувача.

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

Capacity — максимальний обсяг роботи, який команда може виконати за період часу.

Story point — відносна оцінка обсягу та складності задачі.

Таска — англіцизм або сленговий термін, перекладається як “задача”.

Друга половина дня інколи непередбачувана. Сьогодні у середовищі системи після інтеграції зʼявився критичний баг — реліз функціоналу можуть відтермінувати. Марина швиденько збирає зустріч: розробники, тестувальник і ВА. Вони швидко діагностують проблему — помилка у зовнішньому API. Марина разом із командою виносять рішення тимчасово відкатитися на попередню стабільну версію системи, повідомити про це клієнта та оновити плани. Також — оцінити з розробниками скільки часу піде на вирішення цього багу. Роль ПМ тут — це не кодити проблему, а зібрати команду, проаналізувати проблему, обговорити її з командою, винести рішення та оновити оцінки.

Реліз — процес випуску нової версії програмного забезпечення.

Під кінець дня Марина переглядає метрики: скільки задач у прогресі, скільки блокерів вирішено, на скільки стрічка виконання відповідає roadmap. Перед тим, як вимкнути ноут, записує собі пріоритети на завтра.

‍

Що це означає для початківця?

‍

• ПМ — це про координацію, комунікацію і прийняття рішень. Необовʼязково знати код, але треба розуміти процеси і вміти говорити із технарями.
• Навички, які допомагають найшвидше: чітка комунікація, організація зустрічей, пріоритизація, уміння працювати з ризиками.
• Інструменти: Trello/Jira для задач, Confluence/Docs для документації, Slack для комунікації, Miro для воркшопів, Google Meet/Zoom для зустрічей.
• Роль часто потребує швидкої реакції на невизначеність, тому важлива стійкість і вміння структурувати інформацію.