Традиційне планування не працює

Традиційна й загальновживана практика планування — низхідне планування. Спрощено його можна уявити так:

• Керівник вирішує, що потрібно зробити;
• Інструкції про те, що та як потрібно зробити, спускаються зверху вниз по всій організації.
• Планувальники малюють діаграми Ганта з колірним кодуванням, що показують, хто, що й коли буде робити.

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

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

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

Чому? Соратник гуру менеджменту Фредеріка Тейлора Генрі Гант придумав такі діаграми ще 1910 року. Вони набули широкого поширення в Першій світовій війні. Але організація в цій війні була вкрай слабкою. Проте принципи планування, розроблені Гантом, використовуються досі. У сучасних умовах ця схема недоречна і схожа на модель Політбюро ЦК КПРС, яке напередодні краху Радянського Союзу «вірило» звітам, які не відображали реальний стан справ, про те, що все добре.

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

Scrum передбачає гнучку альтернативу традиційному плануванню

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

Scrum — це частина так званої гнучкої (agile) методології, яка з’явилася в 1990-х рр. у відповідь на проблеми традиційного планування у сфері програмного забезпечення. Основи нового підходу були закладені в agile-маніфесті, у якому перераховувалися такі цінності:

• Люди важливіші за процеси;

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

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