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

Impediment backlog

Той хто ближче знайомий зі Scrum напевно знає, що єдиний інструмент яким володіє лише Scrum Master — Impediment Backlog. Impediment — це перепона, яка не дає команді бути повністю ефективною і scrum master має їх усувати.

Можна усувати проблеми (читай: імпедіменти) в міру їх появи — реактивний підхід. Якщо скрам мастер це робить — це непогано. Добре: працювати проактивно — реєструвати потенційні проблеми команди — ризики.

Відповідно Impediment backlog — дуже спрощена форма роботи з поточними ризиками в скрамі.

Impediment backlog можна організувати різними способами:

• Стікерами на окремій дошці (працює для доволі рідкісного випадку коли вся команда таки знаходиться в одній кімнаті)
• Віртуальними стікерами на віртуальній дошці — на зразок RealtimeBoard (для повністю розподілених команд)
• Окремим проектом в трекері задач. Так наприклад TFS Online, JIRA теж дозволяють побудувати окрему канбан дошку для скрам мастера. Можна навіть додати окремий лінк для будь якого члена команди, щоб він міг створити імпедімент на розгляд
• Будь-який інший інструмент що підтримує списки і дозволяє спільну роботу

Всі наведені підходи дуже схожі за принципом, але якщо підсумувати: якщо ви вже користуєтесь якимось трекером задач для роботи — просто створіть окремий проект для імпедіментів. Список пріоритетних ризиків / проблем треба винести як окремий елемент на dashboard (а це вже класичний функціонал таких інструментів), котрий у вас перед очима щодня. Якщо ні — фізична дошка чи віртуальний інструмент візуалізації — це один з основоположних інструментів аджайлу.

Risk Register

Якщо є досвід в управлінні ризиками (а також час — що насправді немало важливо) — то можна створити цілий реєстр ризиків. Так варто робити кожному менеджеру проектів, коли щоденна робота включає трохи більше обов’язків та відповідальності, ніж у срам мастера. Це перехід від реактивного підходу у проактивний. Я зазвичай робив їх у Google Spreadsheets чи Excel. Тут можна просто задати всі необхідні атрибути ризиків.

Я використовував вбудовані фільтри та Conditional Formatting для наочності та зручності роботи. Таким чином можна відсікти наприклад watchlist — ті ризики які треба переглядати значно рідше через їх менше значущість. Ось колонки які я використовую в таких реєстрах ризиків:

• Назва ризику (до 60 символів)
• Опис ризик: його для простоти роботи з реєстром можна ховати, коли знає про що йдеться і відкривати коли демонструєш реєстр тим хто з ним стикається значно рідше (Twitter-статус — 140 символів, чи для любителів — 280 символів)
• Сфера впливу: випадний елемент (time, scope, budget, quality, team satisfaction, customer satisfaction)
• Опис впливу: аналогічно до опису самого ризику
• Ймовірність: оцінкова ймовірність за шкалою 1..3, 1..5, 1..10
• Вплив: йдеться про вплив ризику на проект як і ймовірність вище
• Значущість ризику: добуток і ймовірності на вплив
• Статус ризику: можна легко відфільтрувати закриті ризики щонайменше
• Стратегія: стратегія реакції на ризик (mitigate, omit, transfer, accept) — ці реакції заслуговують на окремий пост чи навіть статтю
• Тип: позитивний чи негативний — ризик чи можливість
• Дата створення
• Дата закриття
• Власник ризику: особа яка відповідальна по роботі з ризиком (і так це не завжди скрам мастер чи менеджер)
• Коментарі: тут можна дати волю письму, не обмежуватись в 140 символів. Я пишу сюди всі оновлення і новини, які я отримую по ризику з датами.

Самописні інструменти

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

Свого часу, я брав участь в ініціативній групі розробки рішення на основі розширеного фреймворку роботи з ризиками ADRIANO (сам фреймворк заслуговує окремої серії дописів) на основі JIRA. Здається (але це не точно) нам навіть вдалось вийти на Atlassian Marketplace і навіть продати кілька прикладів цього рішення.

Зараз я працюю з Sigma Software — і у нас також є Project Management Tool, який має вбудовану систему управління ризиками. Список властивостей ризиків приблизно відповідає тому, який описувався у розділі про реєстр ризиків в таблиці. Але перевагою такого інструменту є наприклад те, що активні ризики потрапляють у щотижневі звіти про проект автоматично. Відповідно до критичності ризиків можна сказати ступінь здоров’я проекту по кожній зі складових частин: часу, обсягам робіт, задоволеності команди і клієнта і навіть кошторису проекту. А після закінчення проекту ризики аналізуються під час Post Mortem, і висновки (Lessons Learned) потрапляють до спеціального репозиторію. І їх можна використовувати і при старті інших проектів. Таким чином виконується остання стадія управління ризиками, про яку часто забувають, якщо користуються простими інструментами на кшталт Spreadsheets.

Готові рішення

Зрозуміло, що на ринку існують і готові інструменти по менеджменту ризиків. Але вони несуть навантаження на бюджет, особливо коли оплата відбувається за користувача в місяць (а така модель найпоширеніша). Перевагою звісно є те, що інструмент працює “з коробки”, і часто навіть має багато додаткових інструментів, налаштувати які для початківців з нуля складно. Проте, рідко коли вистачає часу і ресурсів інтегрувати систему управління ризиків з існуючими інструментами (наприклад тими самим таск трекерами чи системами звітування статусу виконання проектів чи затраченого часу), а окремий інструмент малоефективний.

“Risk Gap”

В мене був досвід користуватись одним з готових інструментів Risk Gap. Ми використовували його під час навчального проекту Expedition PM (про нього я теж колись напишу окрему статтю). Перевагами інструменту було те, що він легко налаштовувався, містив оцінки від 1..10 для імовірностей і впливів ризиків (зі зручними підказками), дозволяв оцінювати ризики кількісно, якщо задати скільки коштуватиме в часі, грошах чи обсягу той чи інший ризик. Користувачі могли оцінювати ідентифіковані ризики незалежно одне від одного — а отже оцінка ставала більш об’єктивною. А також можна було створювати завдання для уникнення чи зменшення ризику. Якщо треба “підняти систему з нуля”, то я б радив цей інструмент.

Інші готові рішення

Ось ще кілька інструментів по роботі з ризиками, про які мені розповідали колеги ПМи:

• https://parapet.com/
• www.project-risk-manager.com/
• RiskView
• Citius One
• Prims Risk Management

Висновки

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

Коли йдеться про управління проектами в межах більших компаній з департаментами і потребами проектів, реєстри ризиків переходять в більш структуровані спеціально проектовані продукти. Але потреба працювати з ризиками від того не змінюється. І починати завжди варто з простіших рішень, рухаючись до складніших — інструменти допомагають справитись тільки з обсягами роботи. І при виборі між орієнтуватись на меншу кількість часу ніж би хотілося, та тне працювати з ризиками взагалі — я раджу завжди обирати перший варіант.

Опубліковано для каналу “Мудрий PM”

Що робити із “дуже досвідченими і всезнаючими” членами команди? З моєї практики бачу, що такі люди часто створюють зайві збурення в роботі? Я працюю у виробничий компанії (не ІТ), виконуючи роль координатора проектів. Часто трапляється мати справу з такими персонажами.

Тут можливі кілька варіантів. І щоб ресурсно і продуктивно діяти варто оцінити все за двома питаннями:

1. Який насправді рівень експертизи у такого члена команди: високий чи низький?
2. Який намір він несе своїми коментарями: спрямований на самоствердження чи на допомогу команді?

Різні відповіді на ці питання створюють різні моделі поведінки.

Відповідно до кожного з 4 типів є різні види реагування. Їх найкраще подавати у вигляді матрички 2*2.

Світла сторона сили

Джедай (Jedi)

Якщо такі люди є в команді на них треба орієнтуватись і прислухатись до їх порад. Це справді майстри своєї справи. Часом їх поради дуже доречні, а часом не надто, адже вони не повністю в курсі трикутника менеджера: обсяг (scope) <-> бюджет (cost) <-> час (time). Найкращим меседжем до них буде: “Гарні ідея, але я бачу, що вона не буде працювати з певних причин. Давай обговоримо можливості того, як вона може бути видозмінена, щоб запрацювати”.

Падаван (Padawan)

Такий член команди справді хоче допомогти, але через брак знань і досвіду пропонує нереалістичні чи поверхневі ідеї. Вони часом можуть відволікати від головного, чи дратувати, чи здаватись надто очевидними. Але оскільки падавани орієнтовані на команду, то з них можуть колись вирости джедаї. І цьому треба допомагати:

• якщо ідея подана невчасно — запропонувати перенести її в Parking Lot (список до обговорення пізніше), але відреагувати
• попросити якомога детальніше описати ідею: людина щось навчиться навіть в процесі підготовки ідеї
• якщо є майстер-джедай, котрий готовий працювати з падаваном, організувати їх в команду

Тим часом перейдімо на темну сторону…

Темна сторона

Позер (Poser)

Підозрюю, що власне цей тип “знавців” найбільше цікавив Дмитра. Позер хизується своїми знаннями більше заради власної користі, ніж для загального блага. Тут основне зрозуміти мотивацію. Деякі з можливих варіантів: привернення уваги до своєї особи; бажання вказати на некомпетентність менеджера, приміром через нездійснені амбіції опинитись на його місці; загальне незадоволення життям, і бажання ускладнити його комусь іще.

Діємо залежно від ситуації:

• Привернення уваги. Гіперболізувати привернення уваги: “Блискуча ідея Макаре! З цього можна підготувати чудовий майстер клас для всіх, щоб всі поглибили своє знання. Як щодо того, щоб ти провів його через 2 тижні”. Протягом двох тижнів увага буде прикута до позера і всі очікуватимуть його виступу. (Деколи, але рідко, якщо позер захоче втерти вам носа — він буде на півдорозі до світлої сторони в напрямку Джедая)
• “Вказування” на некомпетентність. Перевірте чи є в цьому вказуванні раціональне зерно. Якщо так — то можна поговорити приватно, і попросити поділитись досвідом і пояснити в деталях — це вкаже на домінацію дорослої частки особистості менеджера. Якщо атака безпідставна — модна наприклад іронічно запропонувати викласти це у формі статті з докладним трактуванням.
• Загальне незадоволення життям. Навряд чи ви вирішите проблеми з особистим життям людини. Це радше робота психоаналітика ніж менеджера. Тут краще зробити довгу МХАТовську паузу, прищурено подивитись, різко змінити вираз обличчя, можна навіть на розуміючий чи співчутливий, і вести далі в продуктивному руслі.

Гоблін (Goblin)

Гоблін не знає предмету дискусії й сам, і іншим не прагне допомогти. Його метикуваті коментарі зазвичай спроба привернути увагу до себе. В найкращому разі з нього виросте позер. Але такому виду позера ніколи не стати джедаєм.

Головне йому не потурати, адже інакше доведеться спуститсь до його рівня, а там він має перевагу в досвіді “гоблінізму”.

Використовуйте сарказм, іронію, вправляйтесь у власній дотепності. При нагоді видайте попередження. Головне тримати баланс, щоб не втратити авторитет.

Схема поведінки доволі проста, але містка. Тут потрібні аналіз і практика.

Охоче прочитаю в коментарях і про ваш досвід стосунків із такими “експертами”.

Опубліковано для каналу “Мудрий PM”

Інструменти управління ризиками