Kyiv Project Management Day 2016 Дмитро Лозовицький: Критичні ризики роботи ІТ – команд Сайт конференції: http://pmday.org/ Спільнота в мережі Linkedin: http://bit.ly/PMDayLin Спільнота в мережі facebook: http://bit.ly/PMDayKyivFB Twitter конференції: https://twitter.com/LvivPMDay

1. A.Ph.D ©
Критичні ризики
роботи ІТ – команд
24 вересня 2016 / Київ
Kyiv Project Management Day
Лозовицький Дмитро ©
https://www.linkedin.com/in/dmytriy-lozovytskiy
+ 38 067 370 39 70; + 38 095 602 38 91.
lozovdmt@gmail.com
aphdukraine@gmail.com

2. «Ніщо не буває таким простим, як здається з початку!»
Закон Мерфі
Категорія «ризик» – це завжди
динамічне поняття!
A.Ph.D ©

3. A.Ph.D ©
Основним джерелом
виникнення ризиків
роботи ІТ команди є
сам процес
девелопменту

4. ISO 31000:2009
Ризик Менеджмент –
Принципи і керівництво до дій
A.Ph.D ©
«Організації усіх типів і розмірів мають справу із
внутрішніми і зовнішніми факторами впливу, завдяки
яким стає неможливо визначити, яким чином і коли
вони досягнуть своїх цілей.
Вплив невизначеності на цілі організації
визначається як “ризик”!»

5. A.Ph.D ©
Ризики роботи ІТ команд
класифікують і поділяють:
1. За областю (сферою) походження:
- зовнішні;
- внутріші;
- змішані.
2. За характером:
- структурні (рольові, ієрархічні);
- особистісні (ризики персоналу);
- організаційні (процесні, комунікаційні);
- технічні.

6. A.Ph.D ©
Ризики роботи ІТ команд
класифікують і поділяють:
3. За часом дії:
- постійні (перманентні);
- тимчасові (разові).
4. За ступенем впливу:
- критичні (загроза зриву проекту);
- важливі (значний вплив);
- мало важливі (вплив не суттєвий);
- незначні (впливом можемо нехтувати).

7. A.Ph.D ©
Ризики роботи ІТ команд
класифікують і поділяють:
5. За ймовірністю настання (реалізації):
- високо імовірні (більше 90%);
- середньо імовірні (від 60% до 90%);
- мало імовірні (від 20% до 60%);
- нереальні (від 0% до 20%).
6. За релевантністю впливу на ризик:
- релевантні (вплив можливий);
- не релевантні (вплив не можливий).

8. A.Ph.D ©
Ризики управління
(обслуговування)
Ризики процесу
девелопменту
1 2

9. A.Ph.D ©
Області – джерела походження ризиків,
наприклад у ітеративній моделі розробки
продукту (Scrum Framework):
1. Коректний підбір ролей у команді, формування самої
команди (team building, team structure);
2. Формування мапи проекту, загальної стратегії руху
(Road map of the project, project scope);
3. Формування архітектури продукту девелопменту
(product structure);
4. Планування спрінтів (sprint planning);
5. Проведення спрінтів, скрам-мітинги (doing sprint, daily
Scrum);
6. Огляд спрінтів, формування зворотного зв’язку (sprint
review, demo);
7. Ретроспектива (retro);
8. Формування артефактів (product backlog, sprint
backlog, product increment);
9. Реліз продукту (product release);
10. Реінтеграція команди (reintegration team).

10. «Кожне рішення породжує нові проблеми
(виклики)!»
Закон Мерфі
A.Ph.D ©

11. A.Ph.D ©
Основні ризики у ітеративній моделі
розробки продукту (Scrum Framework)
Структурні компоненти процесу
девелопменту
Основні ризики
1. Коректний підбір ролей у команді,
формування самої команди (team building,
team structure)
Недостатня компетентність учасників команди, відсутність відповідального за
формування команди, часта зміна керівника команди, залучення третіх осіб у
процес формування команди, знання методології процесу розробки
2. Формування мапи проекту, загальної
стратегії руху (Road map of the project,
project scope)
Покладання лише на ітеративність і циклічність scrum (відкидання потреби
загального планування проекту), недостатній досвід роботи команди, не
достатнє залучення власника продукту у процес формування дорожньої карти
розробки, відсутність єдиного бачення цілей і процесу девелопменту у проектної
команди і замовника
3. Формування архітектури продукту
девелопменту (product structure)
Погане розуміння (аналіз, оцінка, опис, трансформація у вимоги до продукту)
потреб клієнта проектною командою, недостатнє володіння описовими
техніками архітектури продукту, відсутність або некоректність WBS моделі
4. Планування спрінтів (sprint planning) Недостатня залученість учасників команди у процес планування, невідповідність
кваліфіікації командного і технічного лідерів проекту, а також керівника проекту
(team leader, technical leader, project manager), не знання методики процесу
планування задач у спрінті
5. Проведення спрінтів, скрам-мітинги
(doing sprint, daily Scrum)
Відсутність коретних навиків роботи із дошкою виконання задач у scrum,
нерозуміння (незнання) методики проведення статус мітингів, ризик зміни ролей
учасників проекту в результаті проведення девелопменту

12. A.Ph.D ©
Основні ризики у ітеративній моделі
розробки продукту (Scrum Framework)
Структурні компоненти процесу
девелопменту
Основні ризики
6. Огляд спрінтів, формування зворотного
зв’язку (sprint review, demo)
Недостатній рівень комунікації з замовником та в середині команди після отримання
зворотної реакції замовника, ризик критичної зміни вимог до продукту, команди та
організації процесу девелопменту
7. Ретроспектива (retro) Нечесність учасників проектної команди у аналізі і обговоренні проблем під час
ретроспективи, відсутність системи (методики, правил) опису отриманого
проектного досвіду, його розповсюдження і використання у майбутньому проектною
командою
8. Формування артефактів (product
backlog, sprint backlog, product increment)
Неякісне формування проектної документації (штучне спрощення опису проблем,
функціоналу, вимог, проектних рішень тощо), відсутність стійкої звички зверення до
минулого досвіду вирішення проблем
9. Реліз продукту (product release) Відсутність цільової підготовки до релізу (аналізу потенційних проблем, відстуність
(недостатність) оцінки побажань замовника
10. Реінтеграція команди (reintegration
team)
Відсутність будь яких планів реінтеграції працівників (учасників проектної команди),
невчасна реінтеграція працівників

13. A.Ph.D ©
Основні ризики якості IT продукта (IT
product):
1. Недосягнення бізнес-цілей замовника (усіх бізнес
цілей);
2. Практичної непристосованості системи до реального
бізнесу замовника;
3. Протиріччя очікувань замовника;
4. Неправильного розуміння поведінки системи
(повного контексту роботи системи);
5. Нереалізації очікуваних функцій;
6. Реалізації зайвого функціоналу;
7. Незадовільних швидкості роботи системи, її
масштабування, обсягу навантаження;
8. Низька якість тестування;
9. Відсутність можливості досліджень під час прийняття
продукту;
10. Складності підтримки і супроводу продукту.

14. A.Ph.D ©
Ризики етапів командотворення:
1. Відсутності мотивації, направленості до цілі;
2. Відсутності авторитетного лідерства у команді;
3. Виникнення гострої конфліктності.
4. Неможливості формування консистентності
занань і досвіду проектної команди;
5. Неякісної комунікації, розбалансування
ритмічності роботи команди;
6. Зайвого мікро контролю;
7. Ризик відсутності ключових показників контролю;
8. Ризик емоційного вигорання (постійного ухилу в
сторону перманентної роботи на максимумі своїх
можливостей);
9. Психологічної і фізичної адаптації працівників;
10. Ризик звільнення працівника.Фокусування на відносинах
Фокусуваннянарезультатах
Формування
Бурління
Нормалізування
Функціонування
Розформування

15. A.Ph.D ©
Основні ризики управління
(обслуговування) процесу ІТ девелопменту
Фінансові Структурні Зовнішніх відносин Загальні організаційні
1. Зміни обсягів
фінансування
проекту;
2. «Надлишкової»
процедури отримання
і використання
проектних коштів;
3. Складного механізму
фінансового
звітування.
1. Зміни куратора
проекту на «верхініх
поверхах» проектної
структури компанії
або проектного
керівника;
2. Зміни статусу і місця
проекту у проектному
портфелі;
3. Зміни організаційної
структури системи
менеджменту
компанії.
1. Зриву поставки
(обладнання, сервісу в
т. ч. аутсорсинг);
2. Ризик перепродажу
проекту;
3. Ризик втручання
нових стейкхолдерів
проекту.
1. Зміни системи
інформаційного
управління
проектною діяльністю
у компанії;
2. Зміни методики
проектного
управління на рівні
компанії і команди.

16. A.Ph.D ©
Оцінка ризиків
1. Вимірювання наслідків настання і їх критичності
впливу на проект;
2. Можливість опису кожного ризику у кількісних або
якісних величинах;
3. Розуміння факторів виникнення ризику;
4. Розробка превентивних та фактичних регламентних
процедур (механізмів) їх подолання;
5. Ведення статистичних даних з метою формування
оновленого уявлення про «поведінковий характер
ризиків».

17. A.Ph.D ©
Практичні методи оцінки
ризиків
Key performance
indicators (KPI)
1. Конкретизовані і існує можливість
порахувати їх через різноманітні
абсолютні і відносні показники;
2. Розрахунок автоматизується легко за
наявності необхідної інформації;
3. Позбавлені впливів суб’єктивних
суджень;
4. Існує можливість групування,
розподілу.
1. Далеко не завжди можливо
розрахувати КРІ для кожного
виду ризику;
2. Змінюється контекст
проходження проекту,
змінюється і характер ризиків,
а відтак і методика їх
розрахунку;
3. Розрахунок потрібно
проводити частіше.

18. A.Ph.D ©
Практичні методи оцінки
ризиків
The impact that is
marked as quality
characteristic
1. Емоційно краще передає повноту
впливу;
2. Можливо застосувати до різних за
походженням і характером об’єктів
ризиків;
3. Швидка оцінка в процесі сприйняття;
4. Існує можливість групування,
розподілу.
1. Потребує створення і
категоризації своєї власної
шкали розуміння;
2. Усі учасники проектної команди
мають мати однакове розуміння
шкали сили впливу ризиків та
симих типів ризиків;
3. Завжди суб’єктивно по
відношенню до об’єкту ризику
визначається характеристика
його ступеня впливу з боку
персоналу.

19. A.Ph.D ©
Практичні методи оцінки
ризиків
Rating score
1. Найбільш проста для розуміння
шкала оцінки;
2. Може бути застосована як
комбінований варіант якісно /
кількісної оцінки ризику або фактору
який його викликає;
3. Практично може бути застосована у
будь якій ситуації;
4. Існує можливість групування,
розподілу.
1. Потребує створення і
категоризації своєї власної
шкали розуміння;
2. Усі учасники проектної команди
мають мати однакове розуміння
шкали сили впливу ризиків (їх
бальної оцінки);
3. Критерії оцінки потребують
чіткого колективного погоження
(затвердження).

20. A.Ph.D ©
Способи формалізації
оцінки ризиків
Табличні форми –
найглядніший
варіант для
сприйняття, також
може
передбачатися і
інфографічний
підхід
Матриця вірогідності і сили
впливу ризиків проекту
Вірогідність /
загрозливий
вплив
Низька = 1 Середня = 2 Висока = 3
Висока = 3
3 6 9
Середня = 2
2 4 6
Низька = 1
1 2 3

21. «Якщо Ви у якійсь процедурі (процесі) передбачаєте
4 можливих неприємності і вдало їх застерігаєте
(вирішуєте), відразу швидко з’являється п’ята
неприємність!»
Закон Мерфі
A.Ph.D ©

22. A.Ph.D ©
Основні правила
оцінки ризиків
В основі
коректного
розуміння
ризику
завжди
лежать прості
правила
1. Будь – який ризик завжди має об’єкт застосування!
2. Для коректної оцінки необхідно виділити фактори виникнення ризику і
фактори позитивного / негативного впливу на ризик!
3. Ризик може мати оцінку: кількісну (абсолютну / відносну), якісну,
комбіновану (рідше)!
4. Ризики невідворотно пов’язані із процесами діяльності, а значить
можуть бути контрольовані відповідальними за процес працівниками!
5. На практиці насправді існує переважно дві категорії ризиків за ознакою
впливу на них: релевантні і нерелевантні! Умовно чи частково релевантні
ризики все одно у процесі роботи мігрують в одну із зазначених категорій!
6. Ризики є завжди, і ліквідація існуючих ризиків завжди породжує нові!
7. Проектний менеджер, як і інші ключові фахівці проектної команди працює
в першу чергу із критичними ризиками проекту! А потім дивиться і
аналізує чи працювати йому з іншими і як саме!
8. Будь яка оцінка ризику - це припущення (персональне, колективне чи
статистичне)! Потрібно пам’ятати, що до кінця ризик прорахувати
достатньо складно!

23. A.Ph.D ©
Hedging risk
practical techniques

24. «Коли справи залишені на самостійне вирішення,
вони мають тенденцію розвитку від поганого до ще
гіршого!»
Закон Мерфі
A.Ph.D ©

25. A.Ph.D ©
Цикл управління ризиками
Виявлення ризиків
Попереднє дослідження і
аналіз ризиків
Наступний аналіз і
пріоретизація
Планування
Моніторинг ризиків
Коригування ризиків
Вивчення уроків
(формування досвіду)
Імплементація досвіду

26. «Не існує нічого більш незворотного, ніж помилка,
час якої прийшов!»
Закон Тассмана
A.Ph.D ©

27. A.Ph.D ©
Техніка хеджування ризиків
Ризик
Головні
запитання
1. До якого процесу відноситься ризик ?
2. Хто контролює даний процес
(номінально / фактично)?
3. Які причини виникнення ризику,
фактори впливу на нього ?
4. Який результат нашої діяльності
зачіпає даний ризик ?
5. Як ми вимірюємо даний ризик (за
якою шкалою, як часто, яким він є по
силі впливу)?
6. Якими мають бути результати
нашого впливу на ризик ?

28. A.Ph.D ©
Прийоми хеджування ризиків
Типи областей
походження ризиків
Пул інструментів хеджування (активні і пасивні)
1. Процесні 1. Комунікаційні інструменти (усі можливі варіації поєднання і типи);
2. Техінчний, процесний, інформаційний, юридичний аудит (інструменти);
3. Страхування випадків (результатів праці і ін.);
4. Створення мотиваційних та персональних планів кар’єрного зростання
працівників;
5. Залучення незалежних експертів (усі можливі видиекспертиз і
досліджень);
6. Вибір оптимальної методології розробки відповідно до типу існуючого
проекту;
7. Застосування практики внутрішньої експертизи;
8. Професійне навчання працівників і цілих проектних команд;
9. Застосування інструментів бізнес аналізу протягом всього часу
реалізації проекту;
10. Використання статистичних і емпіричних даних команди і колег.
11. Професійна інтуіція.
2. Персоналу
3. Оточення
4. Технічні
5. Інші

29. «У випадку будь якої сукупності обставин,
передбачений курс дій визначається характером
наступних подій!»
Наслідок Макдональда із закону Мерфі
A.Ph.D ©

30. A.Ph.D ©
Техніки прогнозування ризиків
Майнд мепінг компонентів критичних ризиків
Карти процесних і функціональних взаємозв’язків
ризиків
Таблиці і схеми процесу розвитку критичних
ризиків проекту і заходів з їх нівелювання (PCP)
Бібліотеки управлінського досвіду компанії
Статистичні дані
Персональна інтуіція

31. «Під тиском справи йдуть гірше!»
Закон Мерфі у термодинаміці
A.Ph.D ©

32. A.Ph.D ©
Джерело синергії роботи
ІТ команд

33. «Уникайте будь яких дій, наслідки вирішення яких
для Вас є неприйнятними!»
Четвертий закон Ніколса
A.Ph.D ©

34. "Simul in lucem scientiae!"
"Together We are the light of knowledge!"
A.Ph.D © Лозовицький Дмитро ©
https://www.linkedin.com/in/dmytriy-lozovytskiy
+ 38 067 370 39 70; + 38 095 602 38 91.
lozovdmt@gmail.com
aphdukraine@gmail.com