ВІГЕРСОПЕДІЯ: Критичний шлях без затримок: не будь блокером для команди

ВІГЕРСОПЕДІЯ: Критичний шлях без затримок: не будь блокером для команди

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

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

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

Визначення критичного шляху

При плануванні проекту іноді створюють мережеву діаграму операцій (також відому як PERT-діаграму), щоб відобразити часові залежності між завданнями. На рисунку 1 показано мережеву діаграму операцій для проєкту з лише шістьма завданнями, позначеними літерами A–F. Для кожного завдання наведено його орієнтовну тривалість. (Насправді мережеві діаграми операцій містять значно більше інформації, наприклад, найраніші та найпізніші можливі дати початку й завершення кожного завдання).

Для спрощення припустімо, що жодне завдання не може початися, доки не будуть виконані всі попередні завдання. Тобто Завдання F не може розпочатися, доки не будуть завершені Завдання A, D та E.

Рисунок 1. Критичний шлях (позначений товстими стрілками) — це найдовша послідовність залежних завдань від початку до завершення проєкту.

Якщо підсумувати орієнтовну тривалість завдань у різних шляхах, що ведуть від початку до завершення проєкту, можна побачити, що шлях E–F є найдовшим: 5 + 4 = 9 днів (позначений товстими стрілками). Ця послідовність завдань і є критичним шляхом. Вона визначає найкоротшу орієнтовну тривалість, необхідну для завершення проєкту. Якщо будь-яке завдання на критичному шляху виходить за межі запланованих термінів, загальний термін завершення проєкту зсувається на тривалість цієї затримки. Нові завдання, що додаються до критичного шляху, так само відтерміновуватимуть завершення проєкту.

Завдання, які не лежать на критичному шляху, мають певний запас часу, який також називають «плаваючим». Вони можуть виконуватися довше, не затримуючи загальний термін проєкту – але лише до певної межі. Наприклад, Завдання А та D разом мають один день запасу: 2 + 2 = 4 дні, що на один день менше, ніж Завдання E, яке входить до критичного шляху.

Однак критичний шлях може змінитися. Припустімо, що завдання А насправді займає чотири дні, що вдвічі перевищує початкову оцінку. У такому випадку критичним шляхом стане послідовність A–D–F із тривалістю 10 днів (4 + 2 + 4), що призведе до перевищення термінів проєкту на один день у порівнянні з запланованим спочатку дев’ятиденним шляхом E‑F.

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

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

Критичний шлях та Agile методології

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

Припустімо, ви запланували сьогодні працювати над Завданням X за умови, що Сара вчасно завершить свій UX-дизайн. Але Сара трохи затримується. Це впливає на ваше планування роботи та здатність виконати власні зобов’язання, що потенційно може завадити своєчасному завершенню ітерації. Незалежно від того, чи ви проводите формальний аналіз критичного шляху, чи просто тримаєте в голові послідовність завдань, залежності та можливі резерви часу, критичний шлях завжди існує.

Тримаючись осторонь

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

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

Більшу частину роботи можна виконувати паралельно або в довільній послідовності. Однак іноді один учасник повинен завершити певну дію, перш ніж хтось інший зможе перейти до наступного кроку.

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

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

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

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

 

Оригінальна стаття – Stay Off the Critical Path від Карла Вігерса, переклад –  Марʼяна Закорчевна, ревью – Галина Остапенко. Оригінальне фото з статті.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Повідомити про помилку

Текст, який буде надіслано нашим редакторам: