Дмитро Лозовицький: Критичні ризики роботи ІТ –...

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 [email protected]@gmail.com

https://www.linkedin.com/in/dmytriy-lozovytskiy

mailto:[email protected]


«Ніщо не буває таким простим, як здається з початку!» Закон Мерфі

Категорія «ризик» – це завжди динамічне поняття!

A.Ph.D ©

A.Ph.D ©

Основним джерелом виникнення ризиків роботи ІТ команди є

сам процес девелопменту

ISO 31000:2009

Ризик Менеджмент –Принципи і керівництво до дій

A.Ph.D ©

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

Вплив невизначеності на цілі організаціївизначається як “ризик”!»

A.Ph.D ©

Ризики роботи ІТ команд класифікують і поділяють:

1. За областю (сферою) походження: - зовнішні;- внутріші;- змішані.

2. За характером: - структурні (рольові, ієрархічні);- особистісні (ризики персоналу);- організаційні (процесні, комунікаційні);- технічні.

A.Ph.D ©


3. За часом дії: - постійні (перманентні);- тимчасові (разові).

4. За ступенем впливу: - критичні (загроза зриву проекту);- важливі (значний вплив);- мало важливі (вплив не суттєвий);- незначні (впливом можемо нехтувати).

A.Ph.D ©


5. За ймовірністю настання (реалізації): - високо імовірні (більше 90%);- середньо імовірні (від 60% до 90%);- мало імовірні (від 20% до 60%);- нереальні (від 0% до 20%).

6. За релевантністю впливу на ризик: - релевантні (вплив можливий);- не релевантні (вплив не можливий).

A.Ph.D ©

Ризики управління (обслуговування)

Ризики процесу девелопменту

1 2

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).

«Кожне рішення породжує нові проблеми (виклики)!»

Закон Мерфі

A.Ph.D ©

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,нерозуміння (незнання) методики проведення статус мітингів, ризик зміни ролей учасників проекту в результаті проведення девелопменту

A.Ph.D ©

Основні ризики у ітеративній моделі розробки продукту (Scrum Framework)

Структурні компоненти процесу девелопменту

Основні ризики

6. Огляд спрінтів, формування зворотногозв’язку (sprint review, demo)

Недостатній рівень комунікації з замовником та в середині команди після отримання зворотної реакції замовника, ризик критичної зміни вимог до продукту, команди та організації процесу девелопменту

7. Ретроспектива (retro) Нечесність учасників проектної команди у аналізі і обговоренні проблем під час ретроспективи, відсутність системи (методики, правил) опису отриманого проектного досвіду, його розповсюдження і використання у майбутньому проектною командою

8. Формування артефактів (productbacklog, sprint backlog, product increment)

Неякісне формування проектної документації (штучне спрощення опису проблем, функціоналу, вимог, проектних рішень тощо), відсутність стійкої звички зверення до минулого досвіду вирішення проблем

9. Реліз продукту (product release) Відсутність цільової підготовки до релізу (аналізу потенційних проблем, відстуність (недостатність) оцінки побажань замовника

10. Реінтеграція команди (reintegrationteam)

Відсутність будь яких планів реінтеграції працівників (учасників проектної команди), невчасна реінтеграція працівників

A.Ph.D ©

Основні ризики якості IT продукта (IT product):

1. Недосягнення бізнес-цілей замовника (усіх бізнесцілей);

2. Практичної непристосованості системи до реальногобізнесу замовника;

3. Протиріччя очікувань замовника;4. Неправильного розуміння поведінки системи

(повного контексту роботи системи);5. Нереалізації очікуваних функцій;6. Реалізації зайвого функціоналу;7. Незадовільних швидкості роботи системи, її

масштабування, обсягу навантаження;8. Низька якість тестування;9. Відсутність можливості досліджень під час прийняття

продукту;10. Складності підтримки і супроводу продукту.

A.Ph.D ©

Ризики етапів командотворення:

1. Відсутності мотивації, направленості до цілі;2. Відсутності авторитетного лідерства у команді;3. Виникнення гострої конфліктності. 4. Неможливості формування консистентності

занань і досвіду проектної команди;5. Неякісної комунікації, розбалансування

ритмічності роботи команди;6. Зайвого мікро контролю;7. Ризик відсутності ключових показників контролю;8. Ризик емоційного вигорання (постійного ухилу в

сторону перманентної роботи на максимумі своїх можливостей);

9. Психологічної і фізичної адаптації працівників;10. Ризик звільнення працівника.Фокусування на відносинах

Фо

кусу

ван

ня

на

рез

ульт

ат

ах

Формування

Бурління

Нормалізування

Функціонування

Розформування

A.Ph.D ©

Основні ризики управління (обслуговування) процесу ІТ девелопменту

Фінансові Структурні Зовнішніх відносин Загальні організаційні

1. Зміни обсягів фінансування проекту;

2. «Надлишкової» процедури отримання і використання проектних коштів;

3. Складного механізму фінансового звітування.

1. Зміни кураторапроекту на «верхініх поверхах» проектної структури компанії або проектного керівника;

2. Зміни статусу і місця проекту у проектному портфелі;

3. Зміни організаційної структури системи менеджментукомпанії.

1. Зриву поставки (обладнання, сервісу в т. ч. аутсорсинг);

2. Ризик перепродажу проекту;

3. Ризик втручання нових стейкхолдерів проекту.

1. Зміни системи інформаційного управління проектною діяльністю у компанії;

2. Зміни методики проектного управління на рівні компанії і команди.

A.Ph.D ©

Оцінка ризиків

1. Вимірювання наслідків настання і їх критичностівпливу на проект;

2. Можливість опису кожного ризику у кількісних абоякісних величинах;

3. Розуміння факторів виникнення ризику;

4. Розробка превентивних та фактичних регламентнихпроцедур (механізмів) їх подолання;

5. Ведення статистичних даних з метою формуванняоновленого уявлення про «поведінковий характерризиків».

A.Ph.D ©

Практичні методи оцінки ризиків

Key performance indicators (KPI)

1. Конкретизовані і існує можливість порахувати їх через різноманітні абсолютні і відносні показники;

2. Розрахунок автоматизується легко за наявності необхідної інформації;

3. Позбавлені впливів суб’єктивних суджень;

4. Існує можливість групування, розподілу.

1. Далеко не завжди можливо розрахувати КРІ для кожного

виду ризику;

2. Змінюється контекст проходження проекту,

змінюється і характер ризиків, а відтак і методика їх

розрахунку;

3. Розрахунок потрібно проводити частіше.

A.Ph.D ©


The impact that is marked as quality

characteristic1. Емоційно краще передає повноту

впливу;

2. Можливо застосувати до різних за походженням і характером об’єктів

ризиків;

3. Швидка оцінка в процесі сприйняття;


1. Потребує створення і категоризації своєї власної

шкали розуміння;

2. Усі учасники проектної команди мають мати однакове розуміння

шкали сили впливу ризиків та симих типів ризиків;

3. Завжди суб’єктивно по відношенню до об’єкту ризику визначається характеристика

його ступеня впливу з боку персоналу.

A.Ph.D ©


Rating score

1. Найбільш проста для розуміння шкала оцінки;

2. Може бути застосована як комбінований варіант якісно /

кількісної оцінки ризику або фактору який його викликає;

3. Практично може бути застосована у будь якій ситуації;


1. Потребує створення і категоризації своєї власної

шкали розуміння;

2. Усі учасники проектної команди мають мати однакове розуміння

шкали сили впливу ризиків (їх бальної оцінки);

3. Критерії оцінки потребують чіткого колективного погоження

(затвердження).

A.Ph.D ©

Способи формалізації оцінки ризиків

Табличні форми –найглядніший

варіант для сприйняття, також

може передбачатися і інфографічний

підхід

Матриця вірогідності і сили впливу ризиків проекту

Вірогідність / загрозливий вплив

Низька = 1 Середня = 2 Висока = 3

Висока = 3 3 6 9

Середня = 2 2 4 6

Низька = 1 1 2 3

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


A.Ph.D ©

A.Ph.D ©

Основні правила оцінки ризиків

В основі коректного розуміння

ризику завжди

лежать прості правила

1. Будь – який ризик завжди має об’єкт застосування!2. Для коректної оцінки необхідно виділити фактори виникнення ризику і

фактори позитивного / негативного впливу на ризик!3. Ризик може мати оцінку: кількісну (абсолютну / відносну), якісну,

комбіновану (рідше)!4. Ризики невідворотно пов’язані із процесами діяльності, а значить

можуть бути контрольовані відповідальними за процес працівниками!5. На практиці насправді існує переважно дві категорії ризиків за ознакою

впливу на них: релевантні і нерелевантні! Умовно чи частково релевантніризики все одно у процесі роботи мігрують в одну із зазначених категорій!

6. Ризики є завжди, і ліквідація існуючих ризиків завжди породжує нові!7. Проектний менеджер, як і інші ключові фахівці проектної команди працює

в першу чергу із критичними ризиками проекту! А потім дивиться іаналізує чи працювати йому з іншими і як саме!

8. Будь яка оцінка ризику - це припущення (персональне, колективне чистатистичне)! Потрібно пам’ятати, що до кінця ризик прорахуватидостатньо складно!

A.Ph.D ©

Hedging risk

practical techniques

A.Ph.D ©

Цикл управління ризиками

Виявлення ризиків

Попереднє дослідження і аналіз ризиків

Наступний аналіз і пріоретизація

Планування

Моніторинг ризиків

Коригування ризиків

Вивчення уроків (формування досвіду)

Імплементація досвіду

A.Ph.D ©

Техніка хеджування ризиків

Ризик

Головні запитання

1. До якого процесу відноситься ризик ?

2. Хто контролює даний процес (номінально / фактично)?

3. Які причини виникнення ризику, фактори впливу на нього ?

4. Який результат нашої діяльності зачіпає даний ризик ?

5. Як ми вимірюємо даний ризик (за якою шкалою, як часто, яким він є по силі впливу)?

6. Якими мають бути результати нашого впливу на ризик ?

A.Ph.D ©

Прийоми хеджування ризиків

Типи областей походження ризиків

Пул інструментів хеджування (активні і пасивні)

1. Процесні 1. Комунікаційні інструменти (усі можливі варіації поєднання і типи);2. Техінчний, процесний, інформаційний, юридичний аудит (інструменти);3. Страхування випадків (результатів праці і ін.);4. Створення мотиваційних та персональних планів кар’єрного зростання

працівників;5. Залучення незалежних експертів (усі можливі видиекспертиз і

досліджень);6. Вибір оптимальної методології розробки відповідно до типу існуючого

проекту;7. Застосування практики внутрішньої експертизи;8. Професійне навчання працівників і цілих проектних команд;9. Застосування інструментів бізнес аналізу протягом всього часу

реалізації проекту;10. Використання статистичних і емпіричних даних команди і колег.11. Професійна інтуіція.

2. Персоналу

3. Оточення

4. Технічні

5. Інші

«У випадку будь якої сукупності обставин, передбачений курс дій визначається характером наступних подій!»

Наслідок Макдональда із закону Мерфі

A.Ph.D ©

A.Ph.D ©

Техніки прогнозування ризиків

Майнд мепінг компонентів критичних ризиків

Карти процесних і функціональних взаємозв’язків ризиків

Таблиці і схеми процесу розвитку критичних ризиків проекту і заходів з їх нівелювання (PCP)

Бібліотеки управлінського досвіду компанії

Статистичні дані

Персональна інтуіція

"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 [email protected]@gmail.com

https://www.linkedin.com/in/dmytriy-lozovytskiy



Дмитро Лозовицький: Критичні ризики роботи ІТ –...

Presentations & Public Speaking

Transcript of Дмитро Лозовицький: Критичні ризики роботи ІТ –...