Обмірковування попереднього проектного досвіду — найкращий спосіб постійного вдосконалення та зменшення майбутнього болю.
Якщо ви продовжуєте працювати в той самий спосіб, як і завжди, немає причин очікувати, що майбутні проекти будуть кращими, ніж попередні. Безперервне навчання та налагодження процесів є ознаками успішних організацій. Ретроспектива, як складова частина культури постійного вдосконалення, — це найефективніший спосіб озирнутися на завершену роботу.
Обмірковування завершених проектів або ітерацій розробки може дати розуміння, яке допоможе виконувати майбутню роботу набагато успішніше. Ретроспективи є невід’ємним елементом багатьох гнучких підходів до розробки програмного забезпечення, оскільки команда може негайно застосувати уроки, отримані з ранніх спринтів, щоб покращити свої майбутні спринти.
Визначення ретроспективи
Ретроспектива — це структурований спосіб збору знань, ідей, показників і артефактів із завершеного проекту, фази або ітерації розробки. Навіть у повсякденному житті витратити час на розмірковування над тим, чому щось неприємне сталося, допоможе вам уникнути повторення.
Формальна ретроспектива забезпечує завершення, фіналізацію. Це спосіб для учасників поділитися своїми спостереженнями та досвідом подалі від повсякденного тиску проекту. Навіть якщо проект був колосальним провалом, уроки, які ви з нього здобули, можуть дати щось позитивне з цього негативного досвіду.
Ретроспективи іноді називають постпроектними оглядами, дебрифінгами або некрологом (навіть якщо проект вижив!). Ретроспектива — це нейтральний термін, який пропонує споглядальне осмислення попереднього досвіду, щоб отримати практичну мудрість і покращити майбутню діяльність.
Коли проводити ретроспективу
Проводьте ретроспективу кожного разу, коли ви хочете зібрати інформацію про свій проект, оцінити, як йде робота, або зрозуміти, чому все відбувалося певним чином. Гнучкі проекти проходять серію циклів розробки; виносьте уроки після кожного такого спринту чи ітерації, щоб легше впоратися з тими, що залишилися. Розмірковувати про минулий досвід особливо варто кожного разу, коли щось вийшло особливо добре або особливо погано.
Легко забути, що сталося на початку проекту, який триває довше, ніж кілька місяців, тому проводьте коротку ретроспективу після досягнення кожної важливої віхи в довгому проекті. Цілющий вплив часу та натхнення нещодавнього успіху можуть полегшити біль, який ви зазнали дещо раніше. Однак ці болючі спогади містять насіння майбутніх покращень.
Основна директива
Батько ретроспектив Норман Л. Керт написав основоположну книгу на цю тему «Ретроспективи проекту: Посібник для командних оглядів» (Project Retrospectives: A Handbook for Team Reviews, Norman L. Kerth). Основна директива Керта стверджує: «Незалежно від того, що ми виявимо, ми повинні розуміти та справді вірити, що кожен та кожна виконували свою роботу якнайкраще, враховуючи: те, що було відомо на той час, його чи її навички та здібності, наявні ресурси та поточну ситуацію». Основна директива може допомогти вам зосередити увагу учасників ретроспективи на конструктивній оцінці та майбутньому вдосконаленні, а не на взаємних звинуваченнях та пошуках цапа-відбувайла.
Процес ретроспективи
Малюнок 1 ілюструє простий ретроспективний процес. Ключовими гравцями є менеджер-спонсор, керівник проекту, члени команди проекту та фасилітатор. Книга «Agile Ретроспектива Естери Дербі та Діани Ларсен (Agile Retrospectives», Esther Derby and Diana Larsen) описує палітру з тридцяти видів діяльності, з яких ви можете обрати, щоб створити ретроспективний досвід, який пасуватиме саме вашій команді.
Малюнок 1. Процес ретроспективи
Планування. Скрам-майстер (Карл називає його the management sponsor for the retrospective) працює з фасилітатором, щоб визначити обсяг ретроспективи (весь проект або лише його частина), заходи, які необхідно провести, і будь-які конкретні питання, які потрібно дослідити. Планувальники визначають, хто має брати участь, обирають приміщення (бажано за межами робочого простору та подалі від факторів відволікання), обирають відповідні методи фасилітації та визначають план.
Початок. Під час короткої початкової сесії з усіма учасниками скрам-майстер представляє фасилітатора та будь-яких інших незнайомих осіб. Менеджер оголошує свої цілі для ретроспективи та заздалегідь дякує учасникам за їх час і щирі думки. Керівник повинен чітко заявити про своє зобов’язання вживати конкретні дїй засновані на результатах ретроспективи. Інакше ніхто не буде сприймати подію серйозно.
Фасилітатор окреслює програму заходів. Щоб створити належне конструктивне середовище, він встановлює деякі основні правила, зокрема:
- Дозвольте кожному бути почутим.
- Поважайте досвід і точку зору іншої людини.
- Уникайте критики ідей та внесків інших учасників.
- Уникайте звинувачення людей у минулих подіях.
- Визначте першопричини, а не лише симптоми.
- Зосередьтеся на розумінні, навчанні та зосередженні на майбутньому.
Збір даних. Деякі ретроспективи збирають надійні дані та артефакти проекту, як-от ключові документи плануівання, але основною діяльністю є збір проблем, спостережень і занепокоєнь учасників. Ми досліджуємо чотири основні питання в ретроспективі:
- Що вийшло добре? (Ми хочемо повторити це в майбутньому.)
- Що могло бути краще? (Можливо, ми захочемо це змінити.)
- Що нас здивувало? (Це може вказувати на можливі ризики, якими потрібно керувати в майбутніх проектах.)
- Чого ми ще не розуміємо? (Ці питання потребують подальшого аналізу.)
Традиційний підхід фасилітації полягає в тому, що фасилітатор стоїть біля дошки перед групою та просить учасників запропонувати тези на обговорення. Він відзначає те, що пройшло добре, знаком «плюс», а менш сприятливий досвід – знаком «мінус». Варіант полягає у використанні циклічного підходу, пропонуючи кожному учаснику по черзі порушити одну проблему та опитувати групу, доки всі не висловляться. Такий підхід до створення проблеми зазвичай займає від 60 до 90 хвилин.
Після завершення формування проблеми фасилітатор записує кожну порушену проблему на окремій картці. Потім учасники групують картки у відповідні категорії та ваищначають групи проблем.
Цей традиційний підхід фасилітації має кілька недоліків.
- Послідовне генерування проблем повільне.
- Кілька активних та відвертих учасників можуть домінувати над іншими, навʼязуючи думки.
- Легко загубити фокус та застрягнути на розширеному обговоренні однієї гострої теми, замість того, щоб виявляти більшу кількість проблем.
- Деяким учасникам незручно порушувати делікатні питання публічно.
- Впливові або вольові учасники можуть призвести до того, що інші будуть соромитися говорити.
Мовчазні методи, які дозволяють учасникам паралельно створювати проблеми, можуть бути більш ефективними та комплексними. Скрам-майстер може заздалегідь визначити кілька категорій можливих проблем. Загальні категорії проектів програмного забезпечення включають спілкування, організацію, командну роботу, управління, вимоги, проектування, конструкцію, тестування та процеси.
Напишіть назву кожної категорії на окремій сторінці фліпчарту чи дошки. Потім розділіть кожну сторінку на розділи з мітками для того, що пройшло добре, що могло піти краще та які уроки ви винесли. Під час зустрічі попросіть учасників написати кожне зі своїх питань на окремому листочку (наліпці) із зазначенням відповідної категорії. Фасилітатор розміщує їх у правій частині відповідної сторінки фліпчарту. Учасники можуть ходити по кімнаті та дивитися, що написали інші люди, щоб стимулювати власні роздуми.
Учасники, які працюють паралельно таким чином, можуть створити більше проблем за певний проміжок часу. Менше шансів відволіктися на обговорення, коли питання постають майже одночасно. Люди, які, можливо, не бажають говорити, можуть зробити свій внесок мовчки та анонімно. Фасилітатору потрібно буде прочитати вголос усі наліпки на фліпчартах, переконатися, що кожне питання чітко сформульовано та належним чином класифіковано, а також згрупувати споріднені або повторювані питання.
Щоб завершити частину ретроспективи, присвячену збору даних, поставте кожному учаснику два наступні запитання:
- Який аспект цього проекту ви хотіли б залишити таким самим у майбутньому проекті?
- Який аспект цього проекту ви хотіли б змінити в майбутньому проекті?
Пріоритезація проблем. Успішна ретроспектива породить більше проблем, ніж команда може реалістично вирішити, тому необхідно визначити пріоритети та зосередитися на найважливішому. Голосування за принципом Парето є класичною технікою визначення пріоритетів. Кожен учасник отримує обмежену кількість голосів, близько 20 відсотків від загальної кількості пріоритетних питань. Кольорові клейкі точки добре підходять для такого голосування.
Учасники ходять по кімнаті, вивчають фліпчарти та розставляють крапки на питаннях, які, на їхню думку, є найважливішими для вирішення. Ті питання, які збирають найбільше крапок, найбільше дозріли для ранніх дій. Однак, побачивши крапки на липких нотатках, люди можуть засумніватися та не захотіти «марнувати» голоси на питання, які явно не є популярними. Ви можете попросити учасників поставити свої крапки на зворотах листків, щоб виборці не бачили їх.
Зверніть увагу: 7 кроків, як бізнес-аналітику піднятися на вищий рівень
Аналіз. Якщо у вас є час протягом ретроспективної зустрічі, приділіть, близько 15 хвилин обговоренню кожного з найпріоритетніших пунктів. В іншому випадку, зберіть невелику групу для вивчення цих тем після зустрічі. Для пунктів, які були відзначені як особливо успішні, визначте, чому вони досягли успіху та які переваги вони надали. Знайдіть способи гарантувати, що кожен із цих аспектів проекту знову буде успішним у майбутньому. Для питань найвищого пріоритету з розділу «можна було б краще» дізнайтеся причини, визначте наслідки та обміркуйте рекомендації, як покращити процес наступного разу.
Фактори успіху ретроспективи
Ретроспектива може бути успішною лише в нейтральному середовищі без звинувачень, це не полювання на відьом. Важливо чесне та відкрите спілкування. Фасилітатор повинен спрямувати будь-який викид емоцій у конструктивне русло та стежити, щоб він не став особистим. Зробіть наголос на тому, щоб навчатися без почуття провини на основі спільного досвіду проекту. Давайте розглянемо деякі важливі фактори успіху для ретроспектив.
Визначте свої цілі. Менеджер-спонсор повинен визначити свої цілі для ретроспективи. Виберіть конкретні аспекти проекту для перегляду та визначення потенційних бенефіціарів діяльності. Хто вийде вперед, якщо зібрана інформація стане підставою для важливих змін? Хто може виглядати погано, якщо будуть виявлені основні причини проблем? Ви не шукаєте хлопчиків для биття, але вам потрібно зрозуміти, що сталося і чому.
Використовуйте неупередженого фасилітатора. Залучіть досвідченого, нейтрального фасилітатора, який може зробити ретроспективу успішною, висвітлюючи критичні проблеми в конструктивному навчальному середовищі. Керівник проекту об’єктивно не може сприяти ретроспективі. Можливо, у нього є особисті інтереси або він хоче захистити власну репутацію. Керівництво може змусити інших учасників замовчувати важливі питання.
До теми – ВІГЕРСОПЕДІЯ – Шістдесят перлин мудрості для розробки програмного забезпечення.
Залучайте потрібних учасників. Запросіть до участі всіх членів команди проекту разом із будь-якими менеджерами, які фактично були членами команди. Узагальніть ключові проблеми та засвоєні уроки для вищого керівництва та інших осіб, які можуть отримати користь.
Якщо в проекті бере участь кілька груп, які звинувачують одна одну в проблемах або відмовляються сісти разом, щоб дослідити спільні проблеми, ви можете почати з обговорення точок напруги між групами. Ретроспектива може розглянути те, що потрібно змінити, щоб наступного разу ці групи могли співпрацювати ефективніше.
Підготуйте учасників. Якщо учасники не знайомі з ретроспективами, подія може викликати страх, збентеження або опір, особливо якщо проект мав великі проблеми. Інформуйте та заспокоюйте учасників за допомогою запрошувальних матеріалів і під час «продажу цієї активності» ключовим учасниками. Сформуйте конструктивне мислення, наголошуючи, що це діяльність, орієнтована на майбутнє, а не на пошук винуватців.
Зосередьтеся на фактах. Ретроспектива повинна стосуватися процесів і результатів проекту, а не особистості учасників або помилок. Збір об’єктивних даних, таких як запланована продуктивність і дані про якість продукції, є корисною.
Визначте відповідального за план дій. Відповідальний за план дій повинен призначити кожну дію особі, яка виконуватиме її та звітуватиме про прогрес. Він повинен мати достатню вагу в організації, щоб заохотити цих осіб до виконання завдань.
Якщо думаєте про сертифікацію, то Сертифікації від IIBA: які бувають і як підготуватися до CBAP, CCBA
Планування необхідних дій
Не намагайтеся негайно вирішити всі проблеми, які випливають на ретроспективі. Їх може бути забагато. Спочатку виберіть до трьох питань зі списку першочергових; решта залишиться для майбутнього допрацювання. Напишіть простий план дій, який описує ваші цілі вдосконалення, визначає кроки для їх досягнення, визначає, хто братиме на себе відповідальність за кожну активність, і визначає очікувані результати. Під час наступної ретроспективи перевірте, чи призвели ці дії до бажаних результатів.
Одного разу я організовував ретроспективи для однієї команди з різницею в два роки. Деякі проблеми, які виникли під час другої зустрічі, були такими самими, як ті, що були виявлені під час першої! Якщо ви не вчитеся на минулих помилках, ви гарантовано повторюватимете їх. Ніщо не вбиває ретроспективну програму організації швидше, ніж рекомендації, які ні до чого не призводять.
Організація, що навчається
Команда проекту є найкращим джерелом інформації про те, як насправді пройшов нещодавно завершений проект або ітерація розробки. Використовуйте ретроспективу, щоб допомогти команді скласти цілісну картину проекту, щоб допомогти створити більш ефективне середовище наступного разу. Пам’ятайте, що організаційні зміни потребують часу, терпіння та відданості всіх зацікавлених сторін. Якщо люди не хочуть змінюватися, вони не будуть. Але якщо хочуть, то ретроспектива — потужна початкова точка.
Оригінальна стаття – Project Retrospectives: Looking Back to Look Ahead, переклад – Олеся Попова, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне фото від Aritra Roy з сайту Unsplash.