Лекції з управління програмними проектами

1. Лекції з управління програмними проектами
2. Лекція 5. Управління ризиками проекту
3. Планування управління ризиками
4. ідентифікація ризиків
5. Якісний аналіз ризиків
6. Кількісний аналіз ризиків

2009 р

Лекції з управління програмними проектами

С. Архипенко

назад зміст вперед

Лекція 5. Управління ризиками проекту

Основні поняття

Том Демарк в своїй книзі [1] пише: «Проект без ризику - доля невдах. Ризики і вигода завжди ходять рука об руку ». У першій лекції ми вже говорили про те, що, в силу специфіки галузі, програмна інженерія залишається і, в найближчому майбутньому, залишатиметься виробництвом з високим рівнем ризиків. Якщо задуматися, то все, що ми робимо, керуючи проектом розробки ПО, направлено на боротьбу з ризиками не вкластися в термін, перевитрачати ресурси, розробити не той продукт, який потрібно. Визначення ризику було дано в попередній лекції.

Ризик це проблема, яка ще не виникла, а проблема - це ризик, який матеріалізувався. Ризик характеризується наступними характеристиками [2] (Малюнок 24):

• Причина або джерело. Явище, обставина обумовлює наступ ризику.
• Симптоми ризику, вказівка ​​на те, що подія ризику сталося або ось-ось станеться. Першопричина нам може бути не спостерігалася, наприклад, заразилися грипом. Ми спостерігаємо деякі симптоми - піднялася температура.
• Наслідки ризику. Проблема або можливість, яка може реалізуватися в проекті в результаті події ризику.
• Вплив ризику. Вплив реализовавшегося ризику на можливість досягнення цілей проекту. Вплив зазвичай стосується вартості, графіка і технічних характеристик продукту, що розробляється. Багато ризики відбуваються частково і надають відповідне негативне або позитивне вплив на проект.

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

Майк Ньюелл, віце-президент компанії PSM Consulting, розповідав, як він пояснює аудиторії на своїх лекціях, що таке ризик. Він пропонує зіграти в кості на таких умовах, якщо на кубику випадає шістка, то виграє він. Якщо - будь-яке інше число, то виграє слухач. Ставка по 1 долару. Як правило, більшість аудиторії погоджується зіграти на таких умовах. Майк піднімає ставки: $ 10, $ 100, $ 1000.. Поступово кількість бажаючих пограти стає все менше і менше. При ставці $ 1000, як правило, бажаючих ризикувати не залишається.

прийнято [3] виділяти дві категорії ризиків:

• «Відомі невідомі». Це ті ризики, які можна ідентифікувати і піддати аналізу. Відносно таких ризиків можна спланувати відповідні дії.
• «Невідомі невідомі». Ризики, які неможливо ідентифікувати і, отже, спланувати дії у відповідь.

Малюнок 24. Приклад характеристик ризику

Невідомі ризики це непередбачені обставини. Єдине, що ми можемо в цьому випадку зробити, це створити управлінський резерв бюджету проекту на випадок незапланованих, але потенційно можливих змін. На витрачання цього резерву менеджер проекту, як правило, зобов'язаний отримувати схвалення вищого керівництва. Керуючі резерви на непередбачені обставини не входять в базовий план по вартості проекту, але включаються до бюджету проекту. Вони не розподіляються по проекту, як бюджет, і тому не враховуються при розрахунку освоєного обсягу.

Девіз розробників ПЗ з Microsoft [2] : «Ми не боремося з ризиками - ми ними управляємо». Цілі управління ризиками проекту - зниження ймовірності виникнення та / або значущості впливу несприятливих для проекту подій. Адекватне управління ризиками в компанії - ознака зрілості виробничих процесів. Том Демарк пише [1] : «Розглядати тільки сприятливі сценарії і вбудовувати їх в план проекту - справжнє дитинство. І все ж ми постійно так чинимо. ... Якщо тих, хто говорить про можливі проблеми до відкриття проекту, називають troublemakers, а тих, хто здає проект через 2 місяці після обіцяного терміну, працюючи при цьому по 6080 годин на тиждень, - героями, то у вас погана команда ».

Відмовлятися від управління проектними ризиками це все одно, що в кінотеатрі не мати вогнегасників і плану евакуації на випадок пожежі.

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

Управління ризиками це певна діяльність, яка виконується в проекті від його початку до завершення. Як і будь-яка інша робота в проекті управління ризиками вимагає часу і витрат ресурсів. Тому ця робота обов'язково повинна плануватися. Планування управління ризиками - це процес визначення підходів і планування операцій з управління ризиками проекту. Ретельне і докладне планування управління ризиками дозволяє:

• виділити достатню кількість часу і ресурсів для виконання операцій з управління ризиками,
• визначити загальні підстави для оцінки ризиків,
• підвищити ймовірність успішного досягнення результатів проекту.

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

Відповідно до [3] вихідними даними для планування управління ризиками є:

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

План управління ризиками зазвичай включає в себе наступні елементи:

• Визначення підходів, інструментів і джерел даних, які можуть використовуватися для управління ризиками в даному проекті.
• Розподіл ролей і відповідальності. Список позицій виконання, підтримки та управління ризиками для кожного виду операцій, включених до плану управління ризиками, призначення співробітників на ці позиції і роз'яснення їх відповідальності.
• Виділення ресурсів і оцінка вартості заходів, необхідних для управління ризиками. Ці дані включаються в базовий план по вартості проекту.
• Визначення термінів і частоти виконання процесу управління ризиками на протязі всього життєвого циклу проекту, а також визначення операцій з управління ризиками, які необхідно включити в розклад проекту.
• Категорії ризиків. Структура, на підставі якої проводиться систематична і всебічна ідентифікація ризиків з потрібним ступенем деталізації. Таку структуру можна розробити за допомогою складання ієрархічної структури ризиків (Малюнок 25).
• Загальні підходи для визначення рівнів ймовірності, шкали впливу і близькості ризиків на проект.

Малюнок 25. Приклад ієрархічної структури ризиків проекту

Шкала оцінки впливу відображає значущість ризику (Таблиця 2) в разі його виникнення. Шкала оцінки впливу може відрізнятися в залежності від потенційно порушеної ризиком мети, типу і розміру проекту, прийнятими в організації стратегіями і його фінансовим станом, а також від чутливості організації до конкретного виду впливів.

Вага Значення Критерій 3 Катастрофічні Втрати понад $ 100K 2 Критичні Втрати від $ 10K до $ 100K 1 Помірні Втрати менше $ 10K

Таблиця 2. Приклад шкали оцінки впливу ризиків

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

Схожа шкала може бути застосована для оцінки ймовірності настання ризику (Таблиця 3).

Вага Значення Критерій 3 Дуже ймовірно Шанси настання дуже великі 2 Можливо Шанси рівні 1 Мало ймовірно Наступ події вельми сумнівно

Таблиця 3. Приклад шкали оцінки ймовірності здійснення ризику

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

ідентифікація ризиків

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

Вихідні дані для виявлення і опису характеристик ризиків можуть братися з різних джерел.

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

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

Кожен проект замислюється і розробляється на підставі ряду гіпотез, сценаріїв і припущень. Як правило, в описі змісту проекту перераховуються прийняті допущення - фактори, які для цілей планування вважаються вірними, реальними або певними без залучення доказів. Невизначеність в припущеннях проекту слід також обов'язково розглядати як потенційне джерело виникнення ризиків проекту. Аналіз допущення дозволяє ідентифікувати ризики проекту, що походять від неточності, несумісності або неповноти припущень.

Для збору інформації про ризики можуть застосовуватися різні підходи. Серед цих підходів найбільш поширені:

• Опитування експертів
• Мозковий штурм
• метод Дельфі
• картки Кроуфорда

Мета опитування експертів - ідентифікувати і оцінити ризики шляхом інтерв'ю відповідних кваліфікованих фахівців. Фахівці висловлюють свою думку про ризики і дають їм оцінку, виходячи зі своїх знань, досвіду і наявної інформації. Цей метод може допомогти уникнути повторного наступу на одні й ті ж граблі.

Перед опитуванням експерт повинен отримати всю необхідну вступну інформацію. Діяльність експертів необхідно направляти, ставлячи питання. Під час опитування вся інформація, яка видається експертом, повинна записуватися і зберігатися. При роботі з декількома експертами вихідна інформація узагальнюється і доводиться до відома всіх задіяних експертів.

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

Метод Дельфі багато в чому схожий на метод мозкового штурму. Однак є важливі відмінності. По-перше, при застосуванні цього методу експерти беруть участь в опитуванні анонімно. Тому результат характеризується меншою суб'єктивністю, меншою упередженістю і меншим впливом окремих експертів. По-друге, опитування експертів проводиться в кілька етапів. На кожному етапі модератор розсилає анкети, збирає і обробляє відповіді. Результати опитування розсилаються експертам знову для уточнення їх думок і оцінок. Такий підхід дозволяє досягти якогось спільної думки фахівців про ризики.

Для швидкого виявлення ризиків можна скористатися ще однією з методик соціометрії є відомою як "Картки Кроуфорда" [5] .

Суть цієї методики в наступному. Збирається група експертів 7-10 чоловік. Кожному учаснику міні-дослідження лунає по десять карток (для цього цілком підійде звичайний папір для записок). Ведучий задає питання: "Який ризик є найбільш важливим в цьому проекті?" Всі респонденти повинні записати найбільш, на їхню думку, важливий ризик в даному проекті. При цьому ніякого обміну думками не повинно бути. Ведучий робить невелику паузу, після чого питання повторюється. Учасник не може повторювати у відповіді один і той самий ризик.

Після того як питання прозвучить десять разів, в розпорядженні ведучого з'являться від 70 до 100 карток з відповідями. Якщо група підібрана добре (в тому сенсі, що в неї входять люди з різними точками зору), ймовірність того, що учасники експерименту вкажуть більшість значущих для проекту ризиків, вельми висока. Залишається скласти список названих ризиків і роздати його учасникам для внесення змін і доповнень.

Як джерело інформації при виявленні ризиків можуть служити різні доступні контрольні списки ризиків проектів розробки ПЗ, які слід проаналізувати на придатність до даного конкретного проекту.

Наприклад, Барі Боем [6] наводить список 10 найбільш поширених ризиків програмного проекту:

1. Дефіцит фахівців.
2. Нереалістичні терміни і бюджет.
3. Реалізація невідповідної функціональності.
4. Розробка неправильного користувальницького інтерфейсу.
5. "Золота сервіровка", перфекціонізм, непотрібна оптимізація і відточування деталей.
6. Безперервний потік змін.
7. Брак інформації про зовнішні компонентах, що визначають оточення системи або залучених в інтеграцію.
8. Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.
9. Недостатня продуктивність одержуваної системи.
10. "Розрив" в кваліфікації фахівців різних галузей знань.

Демарк і Лістер [1] призводять свій список з п'яти найбільш важливих джерел ризиків будь-якого проекту розробки ПЗ:

1. Вади календарного планування
2. Плинність кадрів
3. роздування вимог
4. порушення специфікацій
5. низька продуктивність

Не існує вичерпних контрольних списків ризиків програмного проекту, тому необхідно уважно аналізувати особливості кожного конкретного проекту.

Результатом ідентифікації ризиків повинен стати список ризиків з описом їх основних характеристик: причини, умови, наслідків та збитків.

Якщо повернутися до прикладу проекту створення «Автоматизованої системи продажу документації», який ми розглядали в попередніх лекціях, то список головних виявлених ризиків може виглядати наступним чином:

Таблиця 4 Список ризиків проекту створення «Автоматизованої системи продажу документації»

Причина Умови Наслідки Збиток Вимоги не ясні. Відсутність опису сценаріїв використання системи. Затримка початку розробки прикладного ПЗ. Великий обсяг переробок. Затримки в термінах здачі готового продукту і додаткові затрати праці. Недолік кваліфікованих кадрів. Архітектура і код низької якості. Велике число помилок. Великі витрати на їх виправлення. Затримки в термінах здачі готового продукту і додаткові затрати праці. Плинність кадрів. Часта зміна учасників команди. Низька продуктивність при введенні нових учасників в проект. Затримки в термінах здачі готового продукту і додаткові затрати праці.

За процесом ідентифікації ризиків слід процес їх якісного аналізу.

Якісний аналіз ризиків

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

Якісний аналіз ризиків включає:

• Визначення ймовірності реалізації ризиків.
• Визначення тяжкості наслідків реалізації ризиків.
• Визначення рангу ризику по матриці «ймовірність - наслідки».
• Визначення близькість настання ризику.
• Оцінка якості використаної інформації.

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

Для визначення рангу ризику використовується матриця ймовірностей і наслідків (Малюнок 26). Ранг ризику визначається твором ваги ймовірності і значущості наслідків.

Можуть, звичайно, існувати і більш складні шкал для оцінок ймовірностей, значущості наслідків і рангу ризиків. Зустрічалися шкали, які

містили до 10 градацій. Але, на мій погляд, найбільш прагматичний підхід - це використовувати трирівневу ранжування.

Продовжуючи розгляд прикладу проекту створення «Автоматизованої системи продажу документації», матриця рангів головних виявлених ризиків може виглядати наступним чином (Таблиця 5).

Таблиця 5. Матриця рангів головних виявлених ризиків проекту створення «Автоматизованої системи продажу документації»

Причина Імовірність Вплив Ранг Вимоги не ясні Дуже ймовірно Катастрофічні 9 Недолік кваліфікованих кадрів. Дуже ймовірно Критичні 6 Плинність кадрів. Можливо Критичні 4

Малюнок 26. Ранг ризику і матриця ймовірностей і наслідків

Для оцінки ризиків необхідна точна і адекватна інформація. Використання неточної інформації веде до помилок в оцінці. Невірна оцінка ризику також є ризиком.

Критерії оцінки якості використовуваної при аналізі інформації виглядають наступним чином:

• Ступінь розуміння ризику.
• Доступність і повнота інформації про ризик.
• Надійність, цілісність і достовірність джерел даних.

Результатом якісного аналізу ризиків є їх докладний опис (Таблиця 6).

Таблиця 6. Приклад картки з описом ризику

R-101 Категорія: Технологічний. Причина: Недолік кваліфікованих кадрів. Симптоми: Розробники будуть використовувати нову платформу - J2EE. Наслідки: Низька продуктивність розробки Вплив: Збільшення термінів і трудомісткості розробки. Вірогідність: Дуже ймовірно. Ступінь впливу: Критична. Близькість: Дуже скоро. Ранг: 6. Вихідні дані: «Зміст проекту», «План забезпечення ресурсами», Протоколи нарад №21 від 01.06.2008, №27 від 25.06.2008.

Результати якісного аналізу використовуються в ході подальшого кількісного аналізу ризиків та планування реагування на ризики.

Кількісний аналіз ризиків

Кількісний аналіз проводиться щодо тих ризиків, які в процесі якісного аналізу були кваліфіковані як такі, що високий і середній ранг.

Для кількісного аналізу ризиків можуть бути використані наступні методи:

• Аналіз чутливості.
• Аналіз дерева рішень.
• Моделювання та імітація.

Аналіз чутливості допомагає визначити, які ризики мають найбільший потенційним впливом на проект. У процесі аналізу встановлюється, якою мірою невизначеність кожного елементу проекту відбивається на досліджуваній цілі проекту, якщо решта невизначені елементи приймають базові значення. Результати представляються, як правило, у вигляді діаграми «торнадо». Малюнок 27 представляє приклад такої діаграми, яка відображає вплив на проектні трудовитрати різних факторів професіоналізму розробників ПЗ [7] .

Малюнок 27. Вплив факторів професіоналізму розробників ПЗ на трудовитрати по проекту.

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

Малюнок 28. Приклад аналіз дерева рішень при виборі купувати або виробляти необхідну для проекту бібліотеку візуальних компонентів (VCL).

При моделюванні ризиків проекту використовується модель для визначення наслідків від впливу детально описаних невизначеностей на результати проекту в цілому. Моделювання зазвичай проводиться за допомогою методу Монте-Карло.

Цікавий приклад подібної моделі - система Riskology від Демарк і Листера, який ілюструє застосування методу Монте-Карло для отримання інформації про те, який запас часу буде необхідний для того, щоб подолати вплив всіх некерованих ризиків проекту, наведено в джерелі [8] . Модель дозволяє врахувати п'ять основних (Малюнок 29) і п'ять додаткових ризиків проекту.

Малюнок 29. П'ять основних факторів ризику програмного проекту, враховуються в моделі Riskology

Характеристики зумовлених в системі Riskology ризиків користувач може змінити, задавши значення мінімальної, максимальної і найбільш вірогідною затримки термінів здачі проекту через вплив даного ризику. Можна включити в модель додаткові власні ризики. Результат моделювання по методу Монте-Карло буде представлений у вигляді гістограми розподілу терміну завершення оцінюваного проекту (Малюнок 30).

Малюнок 30. Гістограма розподілу можливого терміну завершення проекту, розрахована за результатами моделювання методом Монте-Карло

На діаграмі також наведено кількість випадків, приблизно 80 з 500 прогонів, в яких проект, згідно з результатами моделювання, був скасований до свого завершення.

назад Зміст вперед