Практичний досвід використання в ІТ звіту А3 для пошуку першопричин проблем

В продовження теми пошуку першопричин проблем (Root Cause), яку описав автор статті Problem Solving: методики хочу поділитись однією цікавою та корисною практикою яка прийшла в ІТ індустрію з Lean Manufacturing — використання звітів А3.

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

Тож менеджеру, який прочитав цей звіт було значно легше прийняти зважене та запропоноване командою системне рішення проблеми. І це був чудовий приклад Win-Win-Win рішення: менеджер отримував більше вільного часу на стратегічні задачі, команда ставала більш зрілою та самостійною, а бізнес отримував більш якісні рішення, які запобігають повторенню проблем, та відповідну економію ресурсів.

Класичний формат звіту А3 для машинобудування можна побачити тут.

Цей підхід давав дуже гарні результати у минулому, тож на одному проєктів в одній з ІТ компаній, назву та ім’я яких я не можу назвати через підписаний NDA, я вирішив спробувати адаптувати формат звіту А3 та скомбінувати його з проведенням ретроспективи щодо проблеми перевитрат часу на вирішення задач артової скрам команди.

Проблема, з якою зіштовхнулась команда, була доволі класичною — фахівцям треба було значно більше (на 30-40 %) часу, ніж оцінили на старті проєкту, в який я підключився не з самого його початку.

Дуже часто цю проблему хибно намагаються вирішити двома шляхами:

А) Знайти «винуватих», публічно наказати або звільнити повільно працюючих фахівців та найняти нових. До таких рішень схильні менеджери з директивним стилем управління, а також ті, хто не чув про Модель Такмана і додаткові витрати часу на те, щоб пройти етапи Forming, Storming та дійти хоча б до етапу Norming, не розуміють що управління людьми в ІТ сильно відрізняється від управління людьми на заводі, та не розуміють, що таке скрам і канбан, а також в чому їх краса і сила.

Б) Додати в наступні оцінки нових проєктів +(30-40) % часу. Це не тільки не вирішує проблему на поточному проєкті, а й зменшує шанси на підписання нових контрактів та призведе до подальших перевитрат часу, які будуть додаватись вже до базової оцінки 130-140 %.

Більшість ІТ використовують в якості бази знань Confluence або інші аналоги. Через це зараз вже немає сенсу вести документацію на аркушах формату А3. Модифікований для ІТ звіт А3 буде виглядати наступним чином.

Приклад модифікованого для ІТ звіту А3:

1. Background: Продакт оунер з техлідами зробили оцінку нового проєкту так, як це робили завжди в цій аутсорс компанії, побудували таймлайн і визначили, що тривалість проєкту — 1 рік. Оцінку тривалості задач та проєкту робили без залучення фахівців, які цей проєкт будуть робити і без проєктного менеджера/скрам майстра. Техніка оцінки тривалості задач — «по відчуттям техлідів» та з урахуванням «думок сейлз менеджерів» щодо бюджету, який замовник готовий витратити на проєкт. Важливо зауважити, що при оцінці додавали невелику кількість часу на покриття ризиків, але не враховували історичні дані тривалості аналогічних робіт на минулих проєктах, через відсутність статистики. Часу на аудит проєкту та використаних підходів для оцінювання проєкту у нового проєктного менеджера не було. Тип контракту — fixed price, модель роботи команди проєкту — стандартний для аутсорс компанії Time&material.

2. Current conditions: За результатами двох спринтів фактичні дані щодо часу, інвестованого в розроблення 2Д- та 3Д-моделей персонажей, локацій і UX/UI на 30-40% перевищують базові оцінки, що може призвести до суттєвої перевитрати бюджету та/або до перенесення дедлайну та/або зниження рівня якості ассетів, на що замовник категорично не згоден.

3. Goal/Target: Оцінка тривалості задач та усього проєкту зроблена занадто оптимістично і треба знайти комплекс швидких та дієвих рішень, які:

• забезпечать пришвидшення темпу виконання робіт та повернення до базового плану;
• забезпечить мінімізацію відхилення термінів виконання задач від базового плану до рівня не більше ніж +5 % від базових оцінок;
• допоможуть вирішити аналогічні проблеми на наступних проєктах.

4. Analysis: В якості методу аналізу використовували модифіковану діаграму Ісікави (або Fishbone Diagram)

5. Priorities of the suggested countermeasures: В якості техніки пріоритезації використовували Effort-Impact матрицю і формували відповідний план дій. Заблюрений приклад виглядає так:

6. Action plan: Замість двох стандартних і хибних варіантів команда проєкту нагенерила більше 10 гіпотез, впровадження яких потенційно може дозволити досягти мети. Під кожну гіпотезу завели задачу в Jira. Для прозорості цей план дій був відображений у цьому розділі у вигляді таблиці:

7. Monitoring and control: Моніторинг впровадження запланованих заходів, а також точність фактично інвестованого часу у порівнянні до планових естімейтів задач по всім напрям розробки домовились здійснювати кожні 2 тижня на Sprint Review.

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