Словник ІТ-термінів проєктного менеджера

В ІТ-світі, де щодня народжуються нові проєкти, а команди працюють у шаленому темпі, успіх багато в чому залежить від чіткої комунікації та взаєморозуміння. Для проєктного менеджера (PM), який є серцем будь-якого проєкту, знання професійної термінології – це не просто бажана навичка, а життєва необхідність. Це ваша "секретна мова", яка дозволяє не лише ефективно взаємодіяти з командою розробників, бізнес-аналітиками, замовниками та іншими зацікавленими сторонами, але й відчувати себе впевнено у будь-якій ситуації. Опанувавши цей словник, ви зможете швидше зануритися у світ ІТ-проєктів, розуміти контекст розмов і, зрештою, більш успішно керувати проєктами.

Розглянемо список ІТ-термінів, які допоможуть вам краще орієнтуватися при взаємодії з проєктною командою. 

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

Структура

• Документування та проєктні вимоги
• Комунікація на проєкті
• Підходи та правила взаємодії
• Проєктні ролі
• Загальна термінологія

Документування та проєктні вимоги

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

Acceptance Criteria (AC): Набір умов, які повинні бути виконані для того, щоб функція або завдання вважалися завершеними та відповідали вимогам замовника. Це чек-лист, за яким перевіряється готовність завдання. У розробці програмного забезпечення, зазвичай, кожній User story (дивися визначення далі) на початку встановлюються Acceptance Criteria, щоб уникнути конфлікту сторін при здачі/прийомі продукту (або його частини).

Backlog: Упорядкований список всіх завдань, функцій або виправлень, які необхідно виконати в рамках проєкту. Розрізняють Product Backlog (загальний список завдань по продукту) та Sprint Backlog (завдання на поточний спринт). Backlog завжди погоджується із замовником або PO (дивися визначення далі) перед стартом розробки продукту.

Baseline: Затверджений початковий план проєкту (завдання, терміни, бюджет), який слугує точкою відліку для порівняння з фактичним прогресом. Будь-які зміни відносно "базової лінії" потребують додаткового погодження із замовником та командою. Саме на цей документ спирається PM при кожному вхідному запиту від замовника стосовно змін у продукті.

DoD (Definition of Done): Чіткий набір критеріїв, які повинні бути виконані для того, щоб елемент роботи (наприклад, User Story або задача) вважався повністю завершеним і готовим до поставки. На відміну від Acceptance Criteria, які гарантують відповідність результату задачі очікуванням, DoD гарантують якість та повноту реалізації цієї задачі.

Project Scope: Сукупність всіх робіт, функцій та результатів, які необхідно виконати для успішного завершення проєкту. “Обсяг робіт” встановлює чіткі межі проєкту і є складовою Baseline (дивися визначення далі). Все, що не входить в Project Scope описується в розділі “Out of scope” і заздалегідь погоджується між проєктною командою і замовником.

Roadmap: Візуальний стратегічний план, що показує довгостроковий напрямок розвитку продукту або проєкту, його ключові етапи та завдання протягом визначеного часу. “Дорожня карта” дозволяє командам синхронізуватися та підвищити прозорість у досягненні загальних цілей.

SMART: Акронім, який позначає критерії для ефективної постановки цілей. Вона завжди має бути конкретною (S), мати можливість оцінити результати (M), реалістичною (A), відповідати загальним цілям (R) та бути обмеженою в часі виконання (T). PM активно застосовує SMART-критерії для визначення цілей проєкту та постановки окремих завдань для команди.

Spec (Specification): Документ, який описує вимоги, функціональність, технічні характеристики або дизайн продукту чи системи. Він є ключовим джерелом інформації для розробників, дизайнерів та тестувальників, забезпечуючи спільне розуміння того, що має бути створено в рамках проєкту.

SRS (Software Requirements Specification): Офіційна назва документу, який детально описує всі функціональні (що система повинна робити) та нефункціональні (як система повинна працювати, наприклад, продуктивність, безпека) вимоги до майбутньої системи. Це важливий артефакт, що використовується на фазі аналізу і він слугує основним джерелом вимог до майбутньої системи.

User Story: Неформальне пояснення функціональності, яке написане з точки зору кінцевого користувача, що має на меті пояснити цінність цієї функції. Зазвичай має формат: "Як [роль], я хочу [дія], щоб [мета/цінність]". Це допомагає команді поставити себе на місце користувача від якого походить певний запит і розуміти, навіщо вони розробляють цю функцію.

Комунікація на проєкті

Менеджер - це основна комунікаційна ланка на проєкті, тому розуміння цих термінів дозволяє покращити взаємодію в команді та синхронізувати всіх учасників процесів, щоб вони були "на одній хвилі" і на проєкті панувала атмосфера довіри.

Action items: Конкретні завдання або кроки, які необхідно виконати за результатами зустрічі або прийнятого рішення. Зазвичай, вони формуються фасилітатором зустрічі (наприклад, проєктним менеджером) і оформлюються у вигляді Follow Up листа (дивися визначення далі). Пункти Action items завжди мають відповідального та термін виконання.

Check-in meeting: Коротка, швидка зустріч (зазвичай до 30 хвилин) для синхронізації статусу, обміну інформацією та вирішення нагальних питань. Проводиться на регулярній основі (щоденно/щотижнево) з командою або іншими стейкхолдерами.

Demo: Демонстрація розробленого функціоналу або проміжного результату роботи зацікавленим сторонам. Зазвичай, демо проводить PM за підтримки одного або декількох учасників проєктної команди. Мета зустрічі – показати прогрес по проєкту та отримати зворотний зв'язок від стейкхолдерів.

Follow up: Лист з подальшими діями (Action Items) або нагадування, які здійснюються після проведеної зустрічі для підведення підсумків події та отримання відповіді реципієнта.

Inbox: “Вхідний ящик” для всіх повідомлень, завдань, ідей або запитів, які потребують вашої уваги та подальшої обробки. Похідна фраза “розібратися з інбоксом” означає вирішити незавершені справи перед початком нових.

One-to-One (121, 1to1): Зустріч між двома людьми (зазвичай HR або Project менеджером та співробітником) для обговорення індивідуальних питань, перевірки емоційного та психологічного стану людини або отримання коротких апдейтів. Зазвичай, зустріч відбувається раз на декілька тижнів, але не рідше ніж 1 раз на квартал.

Performance review: Зустріч між керівником та підлеглим під час якої обговорюється продуктивність працівника за попередній період (місяць, квартал). Керівник аналізує показники ефективності, встановлює план розвитку, а підлеглий висловлює свої матеріальні і нематеріальні очікування у разі підвищення ефективності за попередній період.

Підходи та правила взаємодії

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

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

Dedicated Team: Модель співпраці, за якої компанія-замовник наймає команду розробників (або інших спеціалістів), яка передається їй у підпорядкування і повністю сфокусована на проєкті замовника на довготривалій основі. Зазвичай, цю модель обирають при браку конкретних спеціалістів у власній команді.

Fixed Price: Модель співпраці, за якої вартість проєкту є фіксованою та узгоджується заздалегідь, незалежно від фактично витрачених ресурсів. Всі ризики лежать на команді-виконавцю. Вважається найдорожчою, але й найбільш безпечною моделлю для замовника. Часто її використовують при розробці проєктів за методологією Waterfall.

MVP (Minimum Viable Product): Версія продукту з базовим набором функцій, достатнім для того, щоб задовольнити ранніх користувачів та отримати зворотний зв'язок для подальшого розвитку. Це перша, найпростіша робоча версія. Більшість популярних стартапів починали свій шлях наслідуючи саме цей підхід до розробки продукту.

PLC (Project Life Cycle): Послідовність фаз або етапів, через які проходить проєкт (в стандартному визначенні, включає 5 фаз: ініціація, планування, реалізація, контроль та завершення).

Presale: Етап продажу, що передує укладанню контракту, під час якого команда розробляє комерційну пропозицію для потенційного клієнта. Саме на цьому етапі проводиться попереднє дослідження проєкту та формується рішення щодо доцільності співпраці між виконавцем і замовником.

Scrum: Один з найпопулярніших Agile-фреймворків, який базується на коротких, фіксованих ітераціях, що називаються спринтами (дивися визначення далі). Протягом кожного спринта команда створює готовий інкремент продукту для користувачів продукту, постійно отримуючи зворотний зв'язок та адаптуючись до змін.

SDLC (Software Development Life Cycle): Структурована послідовність етапів, які проходить програмний продукт від своєї початкової ідеї до виведення з експлуатації. Це загальний фреймворк, що охоплює планування, аналіз вимог, дизайн, розробку, тестування, впровадження та подальшу підтримку. PM має знати концепцію SDLC, щоб розуміти, на якій стадії перебуває розробка та ефективно планувати ресурси.

T&M (Time & Material): Модель співпраці, за якої замовник сплачує за фактично витрачений час спеціалістів та використані матеріали. Ця модель забезпечує високу гнучкість у зміні вимог та обсягу робіт, оскільки оплата відбувається за фактично виконані години, на відміну від фіксованої ціни. Команди, які працюють за цією моделлю зазвичай обирають гнучкі методології розробки (Agile).

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

Проєктні ролі

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

PMO (Project Management Office): Адміністративна структура компанії, яка надає підтримку проєктним командам, встановлює стандарти та правила, щоб забезпечити відповідність процесів команди цілям організації. У випадку ескалації ситуації на проєкті PM може звернутися за допомогою до PMO.

PO (Product Owner): Ключова роль у фреймворку Scrum, яка відповідає за максимізацію цінності продукту, керуючи Product Backlog (дивися визначення далі) та представляючи інтереси зацікавлених сторін. Саме бачення цієї людини формує обриси майбутнього продукту.

SME (Subject Matter Expert): Спеціаліст, який володіє глибокими знаннями та досвідом у певній предметній області, яка важлива для проєкту. Залучення такого спеціаліста на проєкт дозволяє “пролити світло на сірі плями” та мінімізувати можливі ризики, а також краще розібратися зі сферою, в якій розробляється програмний продукт.

Team Lead: Лідер команди розробки (або іншої технічної команди, наприклад, тестувальників). Він відповідає за технічні рішення, якість коду, архітектуру та координацію роботи своєї частини команди. PM тісно співпрацює з ТімЛідом для забезпечення технічної реалізації проєкту та комунікації з іншими учасниками проєкту.

Загальна термінологія

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

Approve: Офіційне підтвердження або схвалення чогось (наприклад, документа, етапу роботи або прийнятого рішення). Без "аппруву" рух далі може бути заблокований (зазвичай зі сторони замовника).

Deadline: Кінцевий, жорстко встановлений термін виконання завдання, етапу або всього проєкту. Пропуск дедлайну може мати негативні наслідки.

Estimate: Приблизна оцінка часу, зусиль або вартості, необхідних для виконання певного завдання або проєкту. "Естімейт" завжди є припущенням і може змінюватись. Оцінка на початку проєкту може мати погрішність в точності в 2-3 рази (а іноді й більше) у порівняння з фактичними результатами вже по завершенню проєкту. 

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

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

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

Overtime: Понаднормова робота працівників поверх робочих годин, яка оплачується додатково (зазвичай, з підвищеною ставкою за годину). “Овертайм” слугує хорошим інструментом для короткострокового підвищення ефективності працівників, але може спричинити “вигорання” людей в довгостроковій перспективі.

Release: Офіційний випуск нової версії програмного забезпечення або продукту для використання користувачами. Дата релізу погоджується заздалегідь і її порушення вважається поганим знаком для команди розробки.

Reject: Офіційне відхилення чогось (наприклад, документа, етапу роботи або прийнятого рішення). Гарним тоном є опис причини “реджекту”, щоб проєктна команда змогла усунути їх і поставити результати роботи якісно.

Scope Creep: Неконтрольоване та поступове збільшення обсягу проєкту, яке виходить за межі початково узгоджених рамок (Project Scope). Зазвичай “розростання обсягу робіт” призводить до перевищення бюджету та термінів, дезорієнтації та розфокусу команди і загальної демотивації її учасників. PM зобов’язаний зафіксувати затверджений обсяг робіт перед стартом проєкту, щоб не допустити Scope Creep.

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

Story Points: Відносна, абстрактна одиниця вимірювання складності або обсягу роботи, для виконання User Story або іншого завдання в Agile-методологіях (особливо в Scrum). На відміну від годин, сторі поінти відображають не абсолютний час, а відносну "вагу" завдання в порівнянні з іншими. Вони допомагають команді оцінювати завдання більш реалістично, враховуючи не тільки час, але й ризики та невизначеність.

Task: Конкретна, чітко визначена одиниця роботи (задача), яку необхідно виконати в рамках проєкту. Кожна “таска” має свій опис, відповідального та термін виконання. Гарним тоном є опис таких задач по SMART. PM розподіляє “таски”, відстежує їхній прогрес та керує залежностями між ними.

UAT (User Acceptance Testing): Фінальний етап тестування, коли кінцеві користувачі (або замовник) перевіряють систему, щоб переконатися, що вона відповідає їхнім бізнес-вимогам і готова до впровадження. Зазвичай, цей тип тестування проводиться перед релізом майбутньої версії продукту.

Velocity: Метрика в Agile, що вимірює обсяг роботи (зазвичай в "story points"), який команда успішно завершила протягом одного спринту. PM використовує "велосіті" для прогнозування того, скільки роботи команда зможе виконати в майбутніх спринтах, для оцінки загального прогресу проєкту і здоров’я команди в динаміці.

Workflow: Послідовність кроків або етапів, через які проходить завдання, документ або процес від свого початку до завершення. PM визначає та оптимізує робочі потоки, щоб забезпечити ефективність та прозорість виконання робіт для всієї проєктної команди.

‍

‍

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

Опанувавши цю "мову", ви не лише почуватиметеся впевненіше, але й значно підвищите свою ефективність як PM. Але не зупиняйтеся на досягнутому, адже світ ІТ постійно розвивається, і разом з ним і його термінологія. Успіхів вам!