Аналіз причинно-наслідкових зв’язків є ключовим елементом успішного управління проєктами в різних сферах, зокрема в розробці програмного забезпечення. Сучасні інструменти для такого аналізу дозволяють ефективно визначати та усувати проблеми, адаптуючи їх під специфіку конкретної галузі чи компанії. Діаграма Ішікави — один із найпопулярніших методів, що сприяє структурованому пошуку кореневих причин і допомагає командами розробляти оптимальні рішення. У цій статті ми дослідимо особливості застосування цього інструменту для підвищення ефективності управління проєктами.
1. Про інструмент
Діаграма Ішікави, або «риб’яча кістка» (fishbone chart), є візуально-графічним інструментом для аналізу причинно-наслідкових зв’язків, розробленим японським інженером якості Каору Ішікавою в 1952 році. Вона отримала свою назву через схожість з риб’ячим скелетом, де «голова» представляє проблему, а «кістки» — можливі причини. Інструмент широко використовується в проджект-менеджменті для вирішення проблем шляхом виявлення основних причин у різних категоріях, таких як процеси, люди, ресурси, та технології.
2. Як використовувати
З часом модель використання цього інструменту зазнала певних змін, що призвело до численних дискусій щодо найкращого способу розподілу причин по гілках. Не існує одного незмінного правила його застосування — важливими є зручність використання та практична користь.
Для побудови діаграми Ішікави слід виконати наступні кроки:
- Визначення проблеми: Спершу формулюється проблема (голова риби). Це може бути, наприклад, затримка розробки проєкту, низька якість продукту тощо. Під час мозкового штурму команда аналізує та визначає причини проблеми, яку необхідно вирішити. Усі ідеї записуються, групуючи їх за відповідними гілками.
- Вибір основних категорій: Виділяються основні категорії причин. Для виробництва це можуть бути: методи, матеріали, люди, техніка, середовище та вимірювання. У проджект-менеджменті часто додають такі категорії як: планування, комунікація, технології. На цьому етапі команда обговорює значущість кожної категорії для вирішення проблеми.
- Аналіз можливих причин: Під кожною категорією додаються підпричини, які деталізують можливі фактори впливу на проблему. Результати фіксуються у вигляді «кісток» риби, щоб візуально викреслити кожну причину.
- Обговорення та визначення головних причин: В результаті аналізу причинно-наслідкових зв’язків виділяються найважливіші причини, які впливають на проблему, та розробляється послідовний план дій для їх усунення.
3. Рекомендації з використання
- Командна робота: Важливо залучати всі зацікавлені сторони, включаючи членів команди, клієнтів і менеджерів. Спільний аналіз допоможе знайти приховані проблеми.
- Адаптація категорій: Використовуйте стандартні категорії, але не бійтеся змінювати їх під конкретний проєкт або галузь.
- Регулярний перегляд: Застосовуйте діаграму Ісікави не лише під час виникнення проблеми, але й на етапі планування та моніторингу, щоб передбачити потенційні ризики.
4. Приклади застосування
Приклад 1: Проблема затримки в розробці програмного забезпечення
Команда проєкту зіштовхнулася із затримками в процесі розробки програмного забезпечення. В рамках аналізу було вирішено використати діаграму Ішікави для виявлення причин. Відповідні категорії включали: планування, людські ресурси, технології, комунікація, зовнішні фактори.
В результаті обговорення були зафіксовані такі причини по категоріях:
- Планування: Недостатньо часу на деталізацію вимог замовника.
- Людські ресурси: Відсутність кваліфікованих спеціалістів для вирішення технічних проблем.
- Технології: Нестабільна інфраструктура серверів для розгортання.
- Комунікація: Відсутність ефективного обміну інформацією між командами.
- Зовнішні фактори: Часті зміни в вимогах від замовника.
Для кращого розуміння, ось візуалізація діаграми Ішікави для прикладу проблеми з програмним забезпеченням:
В результаті спільних обговорень командою були оцінені першопричини та найбільші «кістки». Було виявлено, що основними причинами проблеми були недостатньо чіткі вимоги замовника та проблеми з комунікацією між відділами.
Далі завдяки методу мозкового штурму був складений план дій задля збільшення ефективності обробки вимог замовника і покращенню комунікаційних каналів між командами.
Приклад 2: Незадоволеність результатами фази проєкту
Для виявлення причин незадоволеності результатами фази проєкту зацікавленими сторонами, можна застосувати діаграму Ішікави. Команда збирається на мозковий штурм і визначає основні категорії, які можуть впливати на цю проблему. Ось можливі категорії та приклади причин для кожної:
1. Люди (команда проєкту)
- Недостатня кваліфікація членів команди.
- Непорозуміння між командою та зацікавленими сторонами.
- Невчасне залучення ключових спеціалістів.
2. Процеси
- Нечіткі вимоги до результатів фази.
- Відсутність узгоджених стандартів для оцінки виконаної роботи.
- Недостатня увага до проміжних перевірок якості.
3. Технології
- Використання застарілих інструментів або програмного забезпечення.
- Проблеми з інтеграцією різних систем.
- Недостатнє тестування рішень на етапі впровадження.
4. Комунікації
- Неправильна або нерегулярна передача інформації між командами.
- Відсутність регулярних звітів про хід проєкту для зацікавлених сторін.
- Нечіткі або суперечливі повідомлення.
5. Зовнішні фактори
- Зміна пріоритетів у компанії.
- Нестача ресурсів або підтримки від інших департаментів.
- Вплив ринкових або регуляторних змін.
Зібравши ці причини, команда може побачити повну картину і визначити, які фактори найбільше впливають на незадоволеність зацікавлених сторін. Це дозволить розробити заходи для виправлення ситуації.
5. Висновки
Діаграма Ішікави — ефективний інструмент для аналізу причинно-наслідкових зв’язків у будь-яких проєктах. Вона допомагає не тільки виявити можливі причини проблем, але й сприяє командній дискусії та розробці рішень. Цей метод широко використовується в управлінні проєктами, зокрема в PMO, для вдосконалення процесів та адаптації їх до потреб компанії.
На курсі PMO Studio ми розглянемо, як застосовувати діаграму Ішікави та інші інструменти для впровадження ефективних рішень у вашу систему управління проєктами.
Автор статті: Олена Карліна
