Оригінальна стаття – Don’t Keep Making the Same Mistakes: Learn from Experience, переклад – Олексій Хмельницький, ревʼю – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне фото від freepik — www.freepik.com
Досвід — чудовий вчитель, але тільки якщо ви оцінюєте та записуєте уроки, отримані з досвіду кожного проекту, та вивчаєте їх.
Проекти можуть “піти не по плану” за різних обставин. Ви можете уникнути багатьох класичних помилок, якщо вивчатимете доступну літературу як з управління проектами, так і з технічної роботи у вашій галузі, а також уроки, які ваші власні команди засвоїли на попередніх проектах. Звичайно, коли ви запускаєте новий проект, усі дуже зайняті, і витрачати час на вивчення наявних масивів знань не здається справжньою роботою. Проте вивчення уроків з минулого – це інвестиція у власне майбутнє.
Надмірно самовпевнений керівник проекту, навпаки, покладатиметься виключно на особистий досвід, спогади та інтелект і досвід членів команди, щоб подолати будь-яку кризу та впоратися з будь-яким викликом. Зарозумілість не є міцною технічною основою для успіху проекту.
Найкращі практики
Візьмемо, наприклад, проекти програмного забезпечення. Люди створюють програмне забезпечення вже більше шістдесяти років. За цей проміжок часу з’явилися різноманітні методи розробки та управління, які значною мірою сприяли успіху проекту. Їх ще називають “best practice” . Усім керівникам проектів, бізнес-аналітикам та іншим професіоналам необхідно ознайомитися з найкращими практиками у своїй галузі. Вибіркове застосування відповідних галузевих і місцевих кращих практик — це шлях до отримання користі з уроків, засвоєних у тисячах попередніх проектів.
Деяким людям не подобається цей термін “найкращі практики”. Вони протестують проти цього, бо це передбачає глобальний або абсолютний стандарт досконалості. Звісно, що ці практики залежать від контексту. Декілька методів або технік можна назвати кращими або навіть доречними в будь-якій ситуації. Проте насправді я зазвичай кажу “хороші практики” замість “найкращі практики”. Менш з тим, справді існують моделі практик і технік, які незмінно дають кращі результати, ніж інші, якщо продумано застосовувати їх у відповідних ситуаціях.
Стережіться пастки бездумного дотримання підходу, який хтось назвав “найкращою практикою”, не беручи до уваги, чи він стосується культури, технології, розміру та характеру вашого проекту й організації. Проте з іншого боку, якщо йти цим шляхом, то ви проігноруєте зібрану мудрість тих, хто пішов цим шляхом на свій страх і ризик раніше за вас. Не варто припускати, що ваш проект (або команда, або продукт, або організація) настільки відрізняється, що жоден досвід попередніх проектів не може бути застосований. Звісно, всі проекти мають свої унікальні аспекти. Але є достатньо спільного, що дозволить вам заощадити багато часу — і страждань — застосовуючи уроки чи досвід, накопичені іншими.
Окрім опублікованих звітів про найкращі практики, ми всі маємо власні добірки уроків, засвоєних із нашого особистого досвіду чи досвіду наших колег. Скасовані проекти та проекти з якими виникали труднощі, можуть дати багато уроків, які можуть врятувати вашу команду від страждань п ід час наступного проекту — якщо ви знайдете час, щоб зібрати їх і застосувати.
Найефективніший спосіб зібрати цей “врожай знань” — це ретроспектива, як описано в моїй статті “Project Retrospectives: Looking Back to Look Ahead.” Ретроспектива — це структурована діяльність, під час якої учасники проекту розмірковують над досвідом попереднього проекту, фази або повторення.
Успішні проекти можуть виявити ефективні рішення загальних проблем і дії, які ви повинні прагнути повторити в майбутньому. Двома чудовими ресурсами про те, як проводити ретроспективи, є класична книга Нормана Л. Керта «Project Retrospectives» та «Agile Retrospectives» Естер Дербі та Діани Ларсен.
Не очікуйте, що всі менеджери проектів і члени команди читатимуть повний звіт із кожної ретроспективи та зроблять власні висновки. Щоб отримати максимальну організаційну ефективність, накопичуйте та діліться уроками, отриманими з ваших ретроспектив, оцінок процесів і вашого досвіду управління ризиками проекту. Організуйте сховище отриманих уроків, щоб майбутнім менеджерам проектів і практикам було легко знайти те, що вони шукають. Час, який ви витрачаєте на накопичення уроків і вивчення цієї колекції, буде належним чином використано в кожному проекті, який знаходить ефективні короткі шляхи та уникає повторення минулих проблем.
Таким чином, неочевидно, чи ми змогли вивчити їх, тому що зробили щось геніальне, чи зробили дурну помилку. Самі знання важливіші за те, як ми їх здобули. Важливий момент: не використовуйте аналіз роботи над помилками (або ретроспективи), щоб спробувати звинуватити когось у тому, чому проект пішов коту під хвіст. Ви можете бути впевнені, що в майбутньому ніхто добровільно не братиме участь у цій “феєрії звинувачень”.
Номер | Дата | Проект | Опис | Діяльність | Контакт | Рекомендаціі |
Малюнок 1. Шаблон на вивчені уроки
Шаблон на Малюнок 1 надає просту структуру для збору уроків із кількох проектів у вашій організації. Таблиця 1 описує деяку інформацію, яка може входити до кожного запису про отримані уроки. Накопичення інформації з кількох проектів у подібній структурі (або, навіть краще, у базі даних із можливістю пошуку) полегшує обмін цими уроками між усіма проектами та командами.
Колонка | Опис |
Номер | Унікальний ідентифікатор для кожного уроку. Це може бути простий порядковий номер, але краще використовувати більш змістовну мітку або навіть тег. |
Дата | Дата внесення уроку в сховище (репозиторій). |
Проект | Назва проекту, який сприяв цьому уроку. |
Опис | Опис засвоєного уроку, включаючи ризики його ігнорування. |
Діяльність | Життєвий цикл проекту, робочий продукт або інша тематична категорія, до якої відноситься цей урок. Деякі можливі варіанти: концепція пропозиції, вимоги, архітектура, прототипування, апаратне забезпечення, дизайн, конструкція, модульне тестування, інтеграція, системне тестування, тестування прийнятності користувача, сертифікація, встановлення, технічне обслуговування, процес, планування, оцінка, відстеження, менеджмент. |
Контакти | Ім’я особи, до якої читач може звернутися, щоб дізнатися більше про цей урок. |
Рекомендації | Пропозиції щодо реалізації уроку в майбутньому проекті або щодо вживання дій з вдосконалення процесу на основі даного уроку. |
Створення колекції здобутих уроків не є безкоштовним. Однак для запису знань потрібно набагато менше часу, ніж для отримання цих самих знань. Ви завжди можете додати до репозиторію більше інформації, наприклад ключові слова для пошуку, але інформація в Таблиці 1 допоможе вам розпочати цей процес.
Нижче наведено лише кілька простих прикладів уроків, які ви можете отримати під час проекту:
- Новим членам команди може знадобитися вдвічі більше часу, ніж ви думаєте, щоб стати повністю продуктивними.
- Вимоги, виконання яких передано стороннім підрядникам, мають бути детальнішими та чіткішими, ніж ті, що виконуватимуться на місці, оскільки у вас буде менше можливостей для неформальної взаємодії для прояснення незрозумілих моментів і надання деталей.
- Рецензенти повинні пройти навчання, перш ніж ви зможете очікувати від них високоефективного пошуку дефектів і конструктивної участі в позитивному досвіді рецензування.
- Заплануйте більше часу, ніж зазвичай, для циклів перевірки, коли учасники перевірки географічно розділені.
Ймовірно, ви могли прийти до тих самих висновків, розмірковуючи над проектним досвідом вашої організації. Тому саме уроки, які ви отримуєте з кожного проекту, менш важливі, ніж той факт, що ви розвиваєте “культурний імператив” в організації безперервного вдосконалення на основі безперервної рефлексії і навчання. Ця звичка окупиться як вам особисто, так і вашій команді назавжди.
Розширте свій власний список уроків і передайте цю мудрість усім, кому може бути корисний ваш власний досвід. І не забудьте освіжити власну пам’ять, коли зануритесь у наступний проект. У вас немає часу, щоб заново вивчати ці уроки на кожному проекті.