Andrii Skoromnyi: Чому не працює методика "5 Чому?" – і яка є альтернатива? (UA)
- 1. Чому не працює «5 Чому?» і яка є альтернатива? Andrii Skoromnyi, PhD, PMP Head of PMO at Gamzix Lecturer at Hillel IT school
- 2. ● Досвід: 20+ років як Project Manager 10 місяців як лектор в Hillel IT school ● Домени: ○ IT (iGaming, GameDev, Web, ERP) (3+) ○ машинобудування і суднобудування (4+) ○ інжиніринг у металургії та енергетиці (13+) ● Методології і фреймворки: Kanban, Scrum, Scrum@Scale, Waterfall ● Типи компаній: Product, Outsource, Outstaff companies
- 3. «5 Чому?» - розповсюджений метод пошуку першопричини проблеми шляхом задавання питання чому
- 4. Проблема Можливі, на думку студентів, першопричини Реліз продукту був затриманий на два тижня 1. Був брак досвіду в управлінні проектами та недооцінка складності завдання щодо формування плану 2. Відсутність систематичного процесу оцінки ризиків та визначення вимог на етапі планування проекту 3. Команда не мала можливості ефективно працювати через постійну нестачу ассетів 4. При плануванні проекту не було враховано всіх етапів, включаючи підготовчий аналіз 5. Метушня під час ініціації проекту 6. Не було ефективних механізмів комунікації та обміну інформацією всередині команди 7. Не була налаштована взаємодія між командою розробки та командою інтеграції 8. Помилка PM на перших кроках спілкування з Замовником 9. Бракувало людських ресурсів для виконання всіх вимог 10. Відсутність досвіду в аналізі вимог та виконанні подібних проектів 11. Затримка пов'язана з нестачею ресурсів, включаючи бюджет, персонал та інфраструктуру 12. Проект не мав спеціальної команди і процесу управління змінами 13. Розклад не було виправлено через кінцевий термін, встановлений замовником (клієнта повідомили, що це може зайняти більше часу, тоді це було спочатку погоджено, оскільки це може призвести до додаткових змін в інших частинах коду (інтерфейс, бекенд) 14. Відсутність детального аналізу геймплея та участі розробників у плануванні 15. Не було налагоджених процесів прийняття рішень та вирішення конфліктів між командами 16. Недостатньо кваліфікована оцінка повного скопу задач
- 5. «5 Чому?» не працює, тому що: ● при індивідуальному використанні у кожної людини свій набір психологічних, емоційних та фізичних параметрів, свій рівень впевненості у собі та своїх здібностях, свій життєвий досвід, тому обирається лише одна гіпотеза ● при командному використанні - може бути продавлений той логічний ланцюжок, в якому впевнений неформальний лідер - команда може погодитись на будь-що, в чому буде розбиратись хтось інший
- 8. Модифікований звіт А3 для ІТ проєкту 1. Background: Продакт оунер з техлідами зробили оцінку нового проєкту так, як це робили завжди в цій аутсорс компанії, побудували таймлайн і визначили, що тривалість проєкту – 1 рік. Оцінку тривалості задач та проєкту робили без залучення фахівців, які цей проєкт будуть робити і без проєктного менеджера/скрам майстра. Техніка оцінки тривалості задач – «по відчуттям техлідів» та з урахуванням «думок сейлз менеджерів» щодо бюджету, який замовник готовий витратити на проєкт. Важливо зауважити, що при оцінці додавали невелику кількість часу на покриття ризиків, але не враховували історичні дані тривалості аналогічних робіт на минулих проєктах, через відсутність статистики. Часу на аудит проєкту та використаних підходів оцінювання проєкту у нового проєктного менеджера не було. Тип контракту – fixed price, модель роботи команди проєкту – стандартний для аутсорс компанії Time&material. 2. Current conditions: За результатами двох спринтів фактичні дані щодо часу, інвестованого в розроблення 2Д-, 3Д-моделей персонажей, локацій і UX/UI на 30-40% перевищують базові оцінки, що може призвести до суттєвої перевитрати бюджету та/або до перенесення дедлайну та/або зниження рівня якості ассетів, на що замовник категорично не згоден.
- 9. Модифікований звіт А3 для ІТ проєкту 3. Goal/Target: Оцінка тривалості задач та усього проєкту зроблена занадто оптимістично і треба знайти комплекс швидких та дієвих рішень, які: ● забезпечать пришвидшення темпу виконання робіт та повернення до базового плану; ● забезпечать мінімізацію відхилення термінів виконання задач від базового плану до рівня не більше ніж +5 % від базових оцінок; ● допоможуть вирішити аналогічні проблеми на наступних проєктах.
- 10. 4. Analysis: В якості методу аналізу використовували модифіковану діаграму Ісікави (або Fishbone Diagram)
- 11. Модифікований звіт А3 для ІТ проєкту 5. Priorities of the suggested countermeasures: В якості техніки пріоритезації використовували Effort-Impact матрицю і формували відповідний план дій. Заблюрений приклад виглядає так:
- 12. Модифікований звіт А3 для ІТ проєкту 6. Action plan: Замість двох стандартних і хибних варіантів команда проєкту нагенерила більше 10 гіпотез, впровадження яких потенційно може дозволити досягти мети. Під кожну гіпотезу завели задачу в Jira. Для прозорості цей план дій був відображений у цьому розділі у вигляді таблиці: 7. Monitoring and control: Моніторинг впровадження запланованих заходів, а також точність фактично інвестованого часу у порівнянні до планових естімейтів задач по всім напрям розробки домовились здійснювати кожні 2 тижня на Sprint Review. Summary: завдяки описаному вище підходу команді проєкту вдалось істотно покращити темпи виконання поточного проєкту та закласти гарний фундамент більш якісної оцінки наступних проєктів. Наразі зараз цей проєкт продовжується і ще зарано говорити про те, що поставлена на ретроспективі мета повністю виконана. # Action Jira link and status Responsible Deadline Comment
- 13. Дякую за увагу!