nmk

Лекція №5 (4 години). Оцінка часу, планування розкладу та управління ресурсним забезпеченням

План лекції

Тривалість vs Трудовитрати: у чому різниця? Основні підходи до оцінки в традиційних проєктах (Аналогія, Параметрична).
Оцінка ризиків та невизначеності за методом PERT.
Оцінка в Agile: відносні величини (Story Points) та техніка Planning Poker.
Побудова мережевих графіків. Метод критичного шляху (CPM) та метод критичного ланцюга (CCM).
Розробка розкладу: створення та використання діаграми Ганта (Gantt Chart) в інструменті Jira/MS Project.
Управління ресурсами: розподіл, вирівнювання завантаження (Resource Leveling) та робота з гібридними проєктами.

Перелік умовних скорочень

PERT — Program Evaluation and Review Technique (Техніка оцінки та огляду програм);
CPM — Critical Path Method (Метод критичного шляху);
CCM — Critical Chain Method (Метод критичного ланцюга);
SP (Story Points) — умовні одиниці оцінки складності в Agile;
FTE (Full-Time Equivalent) — еквівалент повної зайнятості;
Resource Leveling — вирівнювання (згладжування) ресурсів.

Вступ

“Скільки часу це займе і коли ми зможемо запустити продукт?” — це друге найпопулярніше запитання клієнта (відразу після “Скільки це буде коштувати?”). Управління розкладом (Schedule Management) та оцінкою часу (Estimation) є одними з найскладніших дисциплін в IT. Люди за своєю природою надто оптимістичні і схильні недооцінювати складність завдань.

У цій лекції ми розберемо математичні та психологічні методи, які дозволяють Project Manager’у перевести розпливчасте “спробуємо зробити до п’ятниці” у точний графік робіт, навчимося знаходити “пляшкові горлечка” проєкту за допомогою критичного шляху та зрозуміємо, чому в Agile відмовилися від оцінок у годинах на користь абстрактнихStory Points.

1. Тривалість (Duration) vs Трудовитрати (Effort)

Перед тим як переходити до методів оцінки, важливо розділити дві ключові концепції, які новачки часто плутають:

Трудовитрати (Effort): Кількість чистих робочих годин (або днів), необхідних для виконання задачі однією людиною, якщо вона не буде ні на що відволікатися. Наприклад: “Написати цей модуль займе 40 годин чисого кодингу”.
Тривалість (Duration): Календарний час, необхідний для завершення задачі.

Приклад: Задача “Написати модуль” має трудовитрати 40 годин. Програміст має працювати 5 днів по 8 годин. Але він також ходить на мітинги, перевіряє пошту і може чекати доступи від сисадміна. Таким чином, задача з трудовитратами 40 годин може мати Тривалість (Duration) цілих 2 календарні тижні (10 робочих днів).

Традиційні методи оцінки

У каскадних методологіях (Waterfall) оцінюванням займаються керівники або техліди під час фази планування:

Оцінка за аналогією (Тоp-Down Estimation):
- Використовується на ранніх стадіях проєкту, коли про нього мало що відомо.
- Базується на історичних даних. “У 2024 році ми робили схожий інтернет-магазин, і він зайняв 6 місяців. Отже, цей інтернет-магазин ми теж зробимо приблизно за 6 місяців”.
- Плюси: Дуже швидко і дешево.
- Мінуси: Найменш точна оцінка. Кожен проєкт унікальний.
Параметрична оцінка:
- Базується на статистичних зв’язках та математичних формулах.
- _“Якщо верстка однієї веб-сторінки в середньому займає 4 години, то верстка 10 сторінок займе: 4 _ 10 = 40 годин”*.
Оцінка “Знизу-Вгору” (Bottom-Up):
- Найточніший з традиційних методів. PM бере WBS (дерево задач з минулої лекції), і команда оцінює найменші підзадачі на найнижчому рівні дерева (наприклад, по 8 годин). Потім ці оцінки просто сумуються від нижніх гілок до самого “стовбура” проєкту.

2. Оцінка ризиків та невизначеності: Метод PERT

Коли програміста питають: “За скільки ти напишеш цей мікросервіс?”, він часто помиляється через ризики (може не запрацювати стороння бібліотека, може виникнути баг). Для роботи з такими невизначеностями винайшли метод PERT (Техніка оцінки та огляду програм), який початково був розроблений для програми створення атомних підводних човнів у США.

Метод PERT вимагає від розробника не однієї, а відразу трьох різних оцінок для однієї задачі:

Оптимістична (O - Optimistic): 20 годин. (Все піде ідеально, ніхто не буде відволікати).
Песимістична (P - Pessimistic): 80 годин. (Все зламається, доведеться переписувати з нуля).
Найбільш ймовірна (M - Most Likely): 40 годин. (Рішення, яке приймається у звичайних умовах).

Формула очікуваного часу (Expected Time, ET):

TE = (O + 4M + P) / 6

Рахуємо для нашого прикладу: TE = (20 + 4*40 + 80) / 6 = (20 + 160 + 80) / 6 = 260 / 6 = 43.3 години.

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

3. Оцінка в Agile: Story Points та Planning Poker

В Agile-фреймворках (як-от Scrum) відмовилися від оцінки задач в годинах. Чому? Тому що поняття “години” дуже суб’єктивне. Senior-розробник Вася напише функцію за 2 години. Junior-розробник Петя писатиме її 12 годин. Якщо ми оцінили задачу в “2 години”, а виконуватиме її Петя — ми гарантовано зірвемо всі строки.

Для вирішення цієї проблеми вигадали Story Points (SP). Story Points — це умовна одиниця вимірювання, яка відображає не час (не години), а загальні зусилля, складність і ризик виконання задачі в співвідношенні з іншими задачами.

SP — це відносні величини.
Зазвичай використовують послідовність Фібоначчі: 1, 2, 3, 5, 8, 13, 21.
Приклад: Якщо найпростіша задача на проєкті “Змінити логотип” приймається за 1 SP, то задача, яка здається в три рази складнішою або об’ємнішою, отримує оцінку 3 SP. І не важливо, скільки годин це займе у Senior’a чи Junior’a — ця задача для всіх у три рази більша за найменшу.

Planning Poker (Покер планування)

Це техніка обговорення оцінок в Agile-команді (найвищий прояв самоорганізації).

У кожного учасника команди є колода карт із числами Фібоначчі.
Продакт Оунер описує задачу (User Story). Команда задає питання.
Кожен мовчки, ні з ким не радячись, вибирає карту з оцінкою (SP) і кладе її долілиць.
На рахунок три всі одночасно розкривають карти.
Якщо всі оцінки однакові (наприклад, всі показали 5 SP) — задача приймається.
Якщо є радикальні відмінності (один показав 2 SP, інший — 13 SP), ці дві людини отримують слово. Той, хто показав 13, можливо, бачить якийсь прихований ризик у архітектурі бази даних, якого не знає той, хто показав 2.
Після обговорення голосування повторюється, доки не досягається консенсус.

4. Мережеві графіки та Метод критичного шляху (CPM)

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

Логічні залежності між задачами:

ФД (Фініш-Старт): Найпопулярніша. Задачу Б не можна розпочати, поки не завершиться задача А (Неможливо тестувати застосунок, поки він не написаний).
СС (Старт-Старт): Задачу Б можна почати, тільки якщо почалася задача А.
ФФ (Фініш-Фініш): Задачу Б не можна завершити, поки не завершена задача А.

Метод критичного шляху (Critical Path Method - CPM)

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

Головне правило Менеджера: Будь-яка затримка виконання хоча б однієї задачі, яка лежить на критичному шляху, автоматично зсуває фінальну дату релізу всього проєкту.

Управлінський висновок: Якщо у вас є програміст-“зірка” (найдосвідченіший член команди), ви повинні ставити його працювати ТІЛЬКИ над задачами на критичному шляху, адже саме вони формують дедлайн.

5. Діаграма Ганта (Gantt Chart)

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

Винайдена ще на початку XX століття Генрі Гантом, це гістограма (стовпчиковий графік), яка використовується для ілюстрації розкладу проєкту.

Ліворуч: Список завдань (з WBS).
Зверху: Шкала часу (Дні/Тижні/Місяці).
У центрі: Горизонтальні смуги, де довжина смуги відображає тривалість (Duration) задачі. Стрілки між смугами показують залежності.

У сучасному IT діаграми Ганта рідко малюють вручну. У каскадних проєктах їх будуть у програмі MS Project або Smartsheet, а в Agile-командах (де застосовуються елементи гібриду) їх автоматично генерує Jira (там цей інструмент називається Jira Roadmaps).

6. Управління ресурсним забезпеченням

Мати ідеальний розклад на папері — це лише половина справи. Друга половина — чи є у нас люди, здатні та вільні виконати ці задачі?

Ресурсний календар: показує доступність кожного фахівця. Тут враховуються національні свята, період відпусток та зайнятість на інших проєктах (FTE).
Перевантаження (Over-allocation): Ситуація (яка часто виникає під час складання діаграми Ганта), коли один і той же програміст має робити дві задачі одночасно (наприклад, 16 годин роботи в один робочий день).

Методи вирівнювання ресурсів (Resource Leveling)

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

Увага! Якщо задача, яку ми відклали через нестачу ресурсу, лежить на Критичному Шляху, то метод вирівнювання (Resource Leveling) невідворотно збільшить загальну тривалість всього проєкту і зірве дедлайни.

Гібридні проєкти

У сучасному IT-світі рідко використовують “чистий” Scrum або “чистий” Waterfall. Частіше управління ресурсами та бюджетом відбувається на “верхньому” (менеджерському) рівні за каскадною моделлю (Складання діаграми Ганта на рік вперед), але безпосереднє виконання робіт програмістами відбувається “на нижньому” рівні через Agile-спринти (2 тижні) та дошки Jira. Команда може оцінювати свої задачі у Story Points, а PM за допомогою Jira Portfolio переводить ці поінти (швидкість команди) у місяці календарного плану для топ-менеджменту.

Висновки

PM повинен чітко розділяти поняття Трудовитрат (чистий час кодування, наприклад, 10 годин) та Тривалості задачі (календарний час виконання з урахуванням перерв, наприклад, 3 дні).
Традиційні методи оцінки зазвичай вимірюють час у годинах. Найпопулярнішим для роботи з ризикованими задачами є метод PERT, який математично вираховує зважене середнє між оптимістичним та песимістичним прогнозами.
В Agile задачі оцінюються не в годинах, а в абстрактних одиницях складності — Story Points (SP). Це вирішує проблему різного рівня досвіду розробників (Junior vs Senior).
Planning Poker є найкращим інструментом командної (самоорганізованої) оцінки вимог, адже “спосіб прихованого голосування” нівелює психологічний тиск техліда на інших учасників команди.
Критичний шлях (CPM) проєкту — це найдовший ланцюжок залежних завдань. Затримка будь-якої задачі на критичному шляху дорівнює затримці самого проєкту. Увага PM має бути прикута саме до цих задач.
Діаграми Ганта та Jira Roadmaps є найважливішими інструментами для візуалізації розкладу та відстеження “вузьких місць” у завантаженні команди (Resource Over-allocation).

Джерела

Інститут управління проєктами (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Розділи: Schedule Management, Resource Management.
McConnell, Steve. Software Estimation: Demystifying the Black Art. (Головна книга для розуміння проблеми оцінки проєктів).
Cohn, Mike. Agile Estimating and Planning. (Для глибокого розуміння Story Points та Planning Poker).

Запитання для самоперевірки

Поясніть різницю між “Трудовитратами” (Effort) та “Тривалістю” (Duration) на конкретному прикладі роботи сисадміна над налаштуванням серверу.
Програміст дає такі оцінки написанню мікросервісу: оптимістична — 10 год, найімовірніша — 15 год, песимістична (у разі падіння бази даних) — 40 год. Скориставшись формулою PERT, розрахуйте очікуваний час виконання (TE).
Чому оцінка в “Story Points” вважається більш універсальною для різношерстої команди, ніж оцінка в годинах?
Якої мети досягає команда в грі “Planning Poker”, коли змушує всіх розкривати свої карти одночасно? Що б сталося, якби розробники називали свої оцінки по черзі вголос?
Знайдіть визначення: Що таке “Резерв часу” (Float або Slack) у методі розрахунку критичного шляху?
Ви — Project Manager. У вас є задача A (лежить на критичному шляху) і задача B (має резерв 5 днів). Обидві задачі вимагають уваги єдиного у компанії DevOps-інженера. Як ви повинні розподілити/вирівняти його навантаження?