Адаптивні рамки проєкту
(APF) і як їх впровадити?

Сьогодні в блозі Worksection ми поговоримо про адаптивні рамки проєкту.

Для багатьох сучасних проектів не підходять моделі традиційного проектного менеджменту (ТПМ). Вони не справляються з викликами, які виникають сьогодні при запуску проектів: постійні зміни, нечіткі бізнес-цілі і дії конкурентів. Встановити повні вимоги на першому етапі стало нереальним, їх доводиться коригувати протягом усього циклу. 

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

Мета методу Адаптивні рамки проекту (APF) – гармонізувати процеси і постійні зміни в проекті, бізнес-клімат та на ринках.
Він не передбачає шаблонів і списку заздалегідь підготовлених рішень.
Зміни в підході є нестандартним відповіддю на зміни в проекті
або в навколишньому середовищі 

Автор методу Роберт Висоцкі наполягає, що проектний менеджер (ПМ) повинен вести себе не як кухар, а як шеф-кухар. Не треба слідувати рецептами, коли відсутність інгредієнта призведе до затримки – потрібно придумувати їх самому, і не озиратися на наявність необхідних компонентів. За спостереженнями Висоцкі, лінійні моделі ТПМ не підходять для 70% проектів. 

Він виділяє сім незалежних факторів, які впливають на проект:

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

Принципи APF

• Сфокусованість на клієнті. Замовник несе відповідальність за вибір інструментів і підходів для проекту, але отримають підтримку з боку проектної команди (ПК).
• Залежність від клієнта. Адаптивні рамках проекту передбачають більшу залученість замовника, ніж звикли більшість проектних менеджерів. Вони повинні бути готові до ролі консультантів, які підтримують клієнта на протязі проекту. Замовник вирішує, продовжувати або завершувати проект.
• Швидка і часта демонстрація результатів. Цикли в APF є короткими. Завдяки цьому клієнт швидко дізнається про поточні результати і надійніше втягується в процеси.
• Готовність постійно задавати питання і аналізувати. Багато фази APF засновані на питаннях, на які повинні відповісти ПК і клієнт.
• Зміни – шлях до кращого рішення. Частота змін для проекту APF – хороший індикатор, як сторони йдуть до потрібного рішення. Ідеально, коли зміни трапляються часто на ранніх циклах і сповільнюються надалі. На відміну від ТПМ, Adaptive Project Framework розглядає зміни не як щось погане, а як ознаки здорового проекту.
• Не спекулювати на майбутньому. Якщо ми не знаємо майбутнього, навіщо планувати? Прогнозування майбутнього вважається процесом, який не додає вартості.

Алгоритми APF

Алгоритми APF

Adaptive Project Framework
складається з 5 фаз

1. Визначення рамок

Це початкова фаза. Встановлюються цілі проекту, які повинні чітко розуміти як ПК, так і замовник. Критерій успішності фіксується як той результат, який приніс очевидну бізнес-цінність. 

Визначення рамок виконується в 5 етапів:

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

Під час успішного пошуку умови відповідності досягаються 2 важливих результату. Формується словник – мова спілкування між ПК і клієнтом, і затверджується угода за підсумками переговорів. Воно стане відправною точкою для реалізації проекту.

Складання заяви з оглядом проекту. Угода за підсумками переговорів перетворюється в документ, в якому висвітлюються:

Визначення параметрів циклу. Встановлюються тривалість і кількість циклів. Цикли можуть не мати однакову тривалість, але в сумі повинні відповідати даті закінчення проекту.

Цикли Adaptive Project Framework зазвичай тривають від 2 до 6 тижнів. Ранні цикли повинні займати менше часу, ніж пізні, щоб заманити клієнта в проект.

Встановлення неповної ієрархічної структури робіт, або розкладу проекту. При плануванні проекту в APF відома мета, але не відомі інструменти для її виконання. Структура доповнюється під час виконання проекту, коли розкриваються важливі деталі. 

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

2. Планування циклу

Адаптивні рамках проекту припускають планування відповідно до концепції «точно в термін». Враховуються тільки ті процеси, для яких вже підібрані рішення.

Designed by katemangostar / Freepik

Планування циклу передбачає залучення клієнтів. Їм легко управляти, воно не вимагає технологічних рішень. 

Планування розбито на 4 етапи:

1. Визначення цілей циклу. Обговорюється спільно з клієнтом з урахуванням відведеного для циклу, часу і наявних ресурсів.
2. Розподіл завдань для встановлення. Це перший крок до формування розкладу проекту із зазначенням виконавців. Процеси, які мають залежності, розбиваються на групи, які вже будуть менш залежні один від одного. Учасників ПК розподіляють по подкомандам, які займуться плануванням і виконанням завдань.
3. Складання розкладу для процесів з залежностями. Підкоманди формують перші списки завдань для кожного процесу. Все, що потрібно для даного етапу – стікери, маркери і дошка. Тобто застосовується практика канбана.
4. Робота підкоманд. Складається підсумковий розклад для кожної підкоманди. Його можна виконати у вигляді матриці, в рядках якої зазначені учасники підкоманди, а в стовпцях – кількість днів у циклі. На клітині матриці розташовується стікер з описом завдання. Коли в ході проекту відбуваються зміни, досить прибрати стікери з непотрібними завданнями. При цьому не будуть порушені залежності між процесами, а учасники однієї підкоманди не будуть перекинуті в іншу.

3. Побудова циклу

На відміну від ТПМ, в APF час виконання циклу ніколи не змінюється. Воно залишається таким, яким було встановлено в ході першої фази «Визначення меж». Ще одна важлива особливість – зміни не проводяться в ході циклу. Впровадження нових підходів відбувається між циклами.

Щоб побудувати цикл, використовуються такі інструменти:

• Розклад для мікрорівнів. Учасники підкоманд складають робочий план для підзадач, з яких складається завдання в їх розкладі. 
• Робочі пакети. Описують, як виконавець має намір виконати підзадачі. Якщо з ним що-небудь трапиться, то його може замінити інший учасник підкоманди. Він буде керуватися робочим пакетом вибулого виконавця. Щоб не створювати роботу з нульовою цінністю, ПМ не повинен запитувати робочі пакети для звичайних завдань. До важливих завдань відносять такі, які мають високий ризик або вимагають виконавців, яких важко підмінити.
• Сховище для запитів на зміни. Пропозиції, що виникають під час виконання циклу, розглядаються після його завершення. Вони вносяться в спеціальне місце на канбан-дошці.
• Інформація про проблеми. Ще одне місце на канбан-дошці відводиться для опису проблем, ризиків і ситуацій, які потрібно прояснити. 
• Збори ПК. Проводиться щоденно до початку робочого дня і триває менше півгодини. Відповідальний за виконання завдання звітує, чи встигає він за розкладом, і повідомляє, чи є у нього план змін. Також він розповідає, що виконала його команда вчора і що готова зробити сьогодні.

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

Designed by katemangostar / Freepik

Звіти про роботу. Регульовані рамки проектів не припускають письмових звітів, доповіді відбуваються в усній формі. Під час робочого зборів ПМ коротко прояснить команді, як вирішуються проблеми, що впливають на проект.

4. Узгодження з клієнтом

Унікальна фаза, якої немає в ТПМ. ПК і клієнт приступають до вирішальних переговорів, в ході яких вони аналізують проект:

Після проведеного аналізу клієнту і ПК належить відповісти на 4 питання:

Відповідають загальні показники проекту очікуванням?

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

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

Designed by Jcomp / Freepik

Друга характеристика – взаємодія. Якщо співпраця ПК з клієнтом складалося плідно, то обидві сторони зможуть спільно вирішити, які інструменти та підходи залишилося застосувати надалі. Це буде знаком, що проект є здоровим і повинен продовжуватися.

чи Повинен проект перейти до наступного циклу?

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

Які інструменти та підходи отримають пріоритет?

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

Що ми повинні побудувати в наступному циклі?

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

5. Огляд проекту

Як і в ході попередньої фази, вам належить відповісти на питання:

Знайшла команда прийнятне рішення?

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

Відповідальність за успішне виконання проекту несуть як ПК, так і клієнт. 

Підійшли чи алгоритми APF для проекту?

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

Наскільки добре команда використовувала алгоритми APF?

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

Впровадження APF

Як згадувалося на початку, APF як метод зародився в ході двох проектів. Один з них замовив рітейлер Snacks Fifth Avenue, який торгував елітними снеків з усього світу в 10 магазинах в Нью-Йорку. Другий – компанія Kamikazi Softwarre Systems, розробляла програми для Інтернету та локальних мереж.

Розглянемо один з цих проектів під мікроскопом. У 2008 році мережа Snacks Fifth Avenue наближалася до 50-річного ювілею. Приводів для радості було небагато: показники продажів падали разом з потоком клієнтів. 

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

Ось так виглядала заява з оглядом проекту для Snacks Fifth Avenue: