Павло Харіков — Head of Project Management Office в VEON Group (Kyivstar, Beeline). Він має понад 10 років досвіду проєктного та портфельного менеджменту в міжнародних компаніях. Реалізував масштабні проєкти з бюджетом до $150 млн.
У колонці для LABA Павло розповів, як ефективно управляти гнучкими проєктами.
Чим гнучкі проєкти відрізняються від консервативних
Розглянемо відмінності на прикладі чотирьох складових — бізнес-цінність, ризик, прозорість та адаптивність.
#1. Бізнес-цінність
При класичному підході до управління проєктами бізнес-цінність продукту проявляється у фіналі. І лише внаслідок величезних зусиль і значної частки везіння. А при гнучкому підході бізнес-цінність реалізується з кожною ітерацією.
Як це відбувається? У класичному проєкті ви витрачаєте багато ресурсу, але довго не отримуєте результату. Тобто замовник інвестує гроші, щоб лише наприкінці отримати вигоду. А гнучкий підхід передбачає регулярне постачання додаткової цінності. Ви одразу ж створюєте корисні для бізнесу речі.
#2. Ризик
Оскільки в класичному підході ви отримуєте результат наприкінці проєкту, то у процесі роботи ви не можете знизити невизначеність того, як користувачі приймуть ваш продукт. Це високий ризик.
У гнучкому підході всі ризики ви відпрацьовуєте під час реалізації, отримуючи зворотний зв'язок від користувача. По суті, у вас є можливість на кожній ітерації трохи змінити напрямок, щоб їх обійти. Тому ризики тут на досить низькому рівні.
Найбільший ризик при реалізації будь-якого проєкту: ваш замовник не вгадав і ви створюєте продукт, який нікому не потрібен. З гнучкими методологіями цього можна уникнути — ви з ранніх етапів проєкту показуєте бізнесу, що створюєте, і підлаштовуєтеся під фідбек.
#3. Прозорість
З перебігом проєкту прозорість зростає. На старті все, немов у тумані, — незрозумілі цілі, невідомо, з ким і для кого працюєте. Але поступово ви розбираєтеся, і прозорість збільшується.
У гнучких підходах із цим простіше — тут ви працюєте маленькими спринтами, детально пропрацьовуючи тільки найближчий горизонт.
#4. Адаптивність
При гнучкому підході протягом усього проєкту ви можете змінювати якісь моменти, адаптуючись до обставин — зовнішніх чи ринкових.
У класичному варіанті у вас є така можливість лише на початку — коли ви плануєте. Після того, коли все зафіксуєте, будете чітко рухатися за планом, боячись оступитися. Тому адаптивність тут на низькому рівні.
Ще важлива відмінність
Будь-який проєкт характеризує трикутник обмежень — бюджет, графік та зміст.
В основі класичного проєкту лежить графік і бюджет — якщо потрібно, їх можна змінювати. Наприклад, якщо вам важливіше вкластися в графік, ви збільшуєте бюджет і щосили намагаєтеся встигнути. Якщо важливіший бюджет — подовжуєте графік. Зміст проєкту тут зафіксований та не змінюється.
У гнучкому підході такий трикутник перевернутий. Тут постійними зазвичай залишаються графік та бюджет: є фінальна дата, до якої ви повинні вийти, та сума грошей, у яку потрібно вкластися.
При цьому зміст не фіксуємо — готові постійно щось змінювати, щоб отримати максимально цінний продукт.
Як планувати у гнучких проєктах
Може скластися враження, що у проєктах із гнучким підходом немає планування. Це не так — просто воно відбувається по-іншому.
У гнучких проєктах планування виконується постійно для кожної ітерації. Ви розбиваєте проєкт на дрібні етапи та продумуєте реалізацію кожного з них. Для РМ-а в такому підході більше роботи — потрібно постійно тримати руку на пульсі та вносити коригування у плани.
Головне тут — розставляти пріоритети. Насамперед створюєте найцінніше для клієнта. Далі поступово додаєте новий функціонал.
Це гарантує, що замовник отримає максимальний вихлоп за всі ресурси, які ви витратили. І відразу зможе використовувати продукт, який ви створили.
Концепція MVP
MVP — це мінімально життєздатний продукт. Він не є ідеальним, але достатнім, щоб виконати базові потреби клієнта.
Найкраще MVP ілюструє картинка:
Тут показано два підходи до створення автомобіля.
Перший — ви поступово створюєте продукт, але на кожному з етапів, окрім фінального, він не дає цінності.
Другий — на кожному етапі у вас є цінність для користувача. Спочатку це скейт, потім — самокат, велосипед, мотоцикл і нарешті автомобіль. Так, клієнт не одразу отримує те, що хотів. Але він відразу отримує продукт, який зможе покрити базові потреби.
Уявіть, що хочете відкрити ресторан. Які базові функції необхідно реалізувати? Замовлення, приготування, оплату та видачу.
Кожен із цих напрямків ви напевно продумали до дрібниць — можливість замовлення онлайн, багате меню та різні способи оплати. Але спочатку зробіть так, щоб все працювало на мінімально достатньому рівні, зберіть зворотний зв'язок від клієнтів. А потім можете поступово додавати новий функціонал і розвиватися у потрібному напрямку.
Як працювати за системою Scrum
Один із найвідоміших фреймворків в управлінні гнучкими проєктами — Scrum. Він визначає набір правил, виходячи з яких працюють ефективні команди. Три опори Scrum — це прозорість, інспекція та адаптація.
Прозорість. Важливі аспекти процесу доступні всім, хто впливає його результат. Є єдиний стандарт, який дає розуміння, як ідуть справи і хто за що відповідає. Усі мають однакове розуміння структури роботи.
Інспекція. Потрібно вивчати прогрес на шляху до цілі кожного спринту та визначати небажані відхилення. Така інспекція не повинна бути частою, щоби не заважати роботі.
Адаптація. Якщо є проблеми, які гальмують роботу, треба щось міняти. Робити це важливо якнайшвидше, щоб мінімізувати відхилення.
Головне правило Scrum — 3-5-3: є три ролі, п'ять церемоній і три артефакти.
Три ролі — це Scrum-майстер, Product Owner та команда розробки. У гнучких підходах немає PM-а, але його функції розподілені між Scrum-майстром та Product Owner-ом.
Scrum-майстер відповідає за те, щоби команда працювала за правилами Scrum. Він знає всі церемонії та забезпечує коректну роботу колективу. Контролює процеси, щоб завдання вчасно та якісно виконувались, не дає можливості стейкхолдерам порушувати встановлені правила.
Product Owner відповідає за продукт. Він вивчає ринок, розуміє, як зробити продукт затребуваним і його розвиває.
Тобто Scrum-майстер відповідає за команду, забезпечуючи ефективну роботу, а Product Owner відповідає за беклог та за його пріоритизацію — приносить завдання для команди.
Третя роль — команда розробки. Тут можуть бути різні спеціалісти — залежно від того, який ви створюєте продукт. В ідеалі це 7-9 людей.
П'ять церемоній — проведення спринтів, їх планування, щоденні стендапи, демонстрація та ретроспектива.
Product Owner приходить зі своїм списком «хотілок» до команди, і разом вони планують, як будуть їх реалізовувати. Вся робота розбивається на декілька спринтів, кожен триває від одного до чотирьох тижнів.
Після планування команда розпочинає роботу. Щоранку на чолі зі Scrum-майстром усі збираються на стендап. Дивляться на канбан-дошку та вирішують, якими завданнями займатимуться. Стендап має тривати не більше 15 хвилин.
Весь бізнес-контент у зручному форматі
Коли перший спринт закінчується, відбувається демонстрація. На неї приходять замовник та всі зацікавлені сторони. Дивляться, що команді вдалося зробити за цей час і дають зворотний зв'язок. Product Owner слухає та вносить коригування у беклог.
Важливий момент у церемоніях — ретроспектива. Це зустріч, яку проводить Scrum-майстер, щоб усі обговорили, що було хорошого та поганого за минулий спринт. Scrum-майстер фіксує недоліки, щоб зробити подальшу роботу ефективнішою.
Три артефакти Scrum — це:
- продуктовий беклог (нескінченний список того, що можна зробити)
- беклог спринту (чіткий список завдань, які вибрала команда)
- інкремент (продукт, який ви показали клієнту на демонстрації)
Як оцінювати завдання у Scrum
Завдання можна оцінювати за часом, який витрачає команда на їх виконання. Але так не заведено. Найчастіше завдання оцінюють у сторі поінтах — відносною мірою обсягу роботи, яку формує сама команда.
Можна використовувати зрозумілі всім характеристики — S, M, L — маленьке, середнє та велике завдання. Так команда розуміє, що за двотижневий спринт встигає зробити, наприклад, 20 маленьких завдань або 10 маленьких та 4 середніх.
Як вимірювати швидкість роботи команди
Можна зробити графік і за його допомогою відслідковувати, скільки сторі поінтів команда зробила за одну ітерацію (спринт). Ось приклад:
Завдання Scrum-майстра — організувати командну роботу так, аби швидкість роботи зростала або вийшла на певний рівень і не падала.
Ще ефективність роботи команди можна показувати через діаграму згоряння завдань. Наприклад, ви собі уявляли, що обсяг роботи в спринті займе 120 сторі поінтів і ви зробите його за сім днів.
Але насправді все може відбуватися по-іншому. За перший день можете спалити не 20 сторі поінтів, як планували, а 12. Потім наздоганяти та відстежувати, через що впала ефективність. Так ви бачите, як працюєте відповідно до плану.
В Agile головне, щоб форма не взяла гору над суттю. Це працює тільки у тому випадку, якщо вся організація поділяє цінності Agile Manifesto:
#1. Люди та взаємодія важливіші за процеси та інструменти.
#2. Дієвий продукт важливіший за вичерпну документацію.
#3. Співпраця з клієнтом важливіша за узгодження умов контракту.
#4. Готовність до змін важливіша за проходження початкового плану.
Бажаєте отримувати дайджест статей?
