Керування розробкою програмного продукту на основі ризиків

Ця стаття адресована тим, хто має відношення до розробки програмного продукту. Розуміння принципів управління процесом розробки не менш важливе, ніж фактичні знання технологій програмування. Стаття не адресована тільки тим, хто хоче стати або працює керівником проекту (Project Manager), Розуміння принципів управління принесе користь на будь-якій посаді і в будь-якій команді.

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

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

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

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

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

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

На самому початку необхідно зрозуміти наскільки проект сформований у замовника:

• Є точне уявлення про запитуваний продукт. Наприклад, розробити протокол зв'язку описаний у стандарті.
• Або у замовника приблизне подання про проект. Наприклад, розробити систему пошуку в інтернеті з певними параметрами та параметрами. Однак очевидно, що в процесі розробки, можуть змінюватися критерії та їх взаємозв'язок один з одним.
• Може бути замовник має дуже загальне подання. Наприклад у клієнта є система Уніфікованих комунікацій, щось на зразок «все в одному» для цілей спілкування в компанії. І тепер стоїть завдання розробити додаткові «плюшки». Є список з багатьох варіантів, але клієнт ще не знає, що б краще, вигідніше розробити спочатку, а що потім. А вигідніше для нього - це ставлення цікаво/витратно.

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

За статистикою тільки 28% програмних проектів завершені в термін і в рамках бюджету, 23% розробок скасовуються до завершення, і половина проектів перевищує бюджет на 50%. Ви отримаєте значно спокійніше життя в кінці проекту, якщо подумаєте про можливі проблеми на початку і не будете закривати очі на виникнення «нештатної» ситуації в процесі розробки.

Управління ризиками включає в себе дві групи дій і точку переосмислення (прийняття рішення про зміну - Дизайн). Перша група це Оцінка ризиків і друга Управління ризиками.

Оцінка ризику, в свою чергу, включає в себе виявлення, аналіз і пріоритезацію ризиків. Управління ризиками включає планування, протидію та моніторинг ризиків.

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

У цій частині команда або її керівник повинні скласти список всіх можливих неприємностей, що очікують проект при його реалізації. Ризики можуть бути розділені на Соціальні та Технологічні. До соціальних ризиків будуть відноситься всі ризики не пов'язані безпосередньо з технологією. Наприклад втрата ключового фахівця (хвороба, звільнення) або тимчасове відключення електрики, інтернету, зміна вимог до проекту та ін. До технологічних ризиків відносяться всі ті аспекти, які можуть виникнути через неправильне виконання завдання, не важливо з чиєї вини. Це може бути неправильно сформульоване завдання, незручний фреймворк, неузгоджений інтерфейс між модулями тощо.

Список ризиків повинен включати в себе:

• Умова виникнення ризику та його опис
• Симптоми його завчасного виявлення (якщо можливо)
• На що вплине ризик, що трапився (час, гроші, репутація)
• Що станеться, якщо ризик стане подією і ми не зможемо протидіяти йому

Аналіз

Коли список ризиків готовий, переходимо до їх аналізу. Для кожного ризику виявляються:

Ймовірність виникнення і тяжкість завданої шкоди. Обидві характеристики квантуються приблизно з 4х величин від «мало» до «великої». Оцінку ймовірності проводять в команді як мозковий штурм. Існує багато методів оцінки ймовірності виникнення ризику. Я тут наведу деякі з них:

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

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

У підсумку обговорення повинна з'явитися таблиця схожого змісту

Така таблиця не повинна містити занадто багато пунктів, їх має бути 1-2 на кількість учасників проекту. Так, якщо група налічує 5 осіб, то немає сенсу мати більше 10ти ризиків. При групі в 20 і більше осіб необхідно ділити ризики по групах, а колективна оцінка не повинна перевищувати загальну кількість співробітників.

Пріоритезація

Ризики вибудовуються в порядку - найістотніший перший. Пріоритет обчислюють за формулою (у системі обчислення розмірності оцінки, у нашому випадку 4):

Пріоритет = Ймовірність х Шкода

Планування

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

Протидія

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

Ефективність захисту = (Вартість ризику до протидії - Вартість ризику із застосуванням протидії )/Вартість протидії.

Зрозуміло, що якщо ефективність - 1, то застосування такої протидії не доцільне.

Моніторинг

Коли всі елементи розроблені і таблиця ризиків заповнена, команда починає роботу над проектом і стежить за можливим настанням ризику або його попереджувальних симптомів. Ризики повинні переглядатися з певною регулярністю, наприклад раз на тиждень, але не пізніше «демо» або здачі фази робіт. Якщо використовується метод управління «Stage and Gate», то після проходження кожних воріт вся таблиця переглядається. В результаті перегляду ризику та зміни його положення в таблиці, колишній рівень ризику записується в колонку «Був рівень». Це дає можливість команді відстежувати динаміку зміни ризику і відповідно розуміти, точку наближення ризику або проходження його.

Ключовим моментом в ефективному управлінні проектом на основі ризиків є постійний обмін інформацією між учасниками команди, керівництвом і замовником. Це важливо! Без обміну інформацією щодо ризиків, ви будете як полководець без розвідки.

Є дві основоположні техніки розробки програмного продукту - Послідовне проектування і проектування методом ітерацій. Більшості розробників відомі такі терміни як Waterfall і Agile методи. Нижче ми розглянемо правильний баланс використання їх у застосуванні до моделі керованої ризиками на основі п'ятиступеневої моделі Б. Бема і Р.Тернера.

Але спочатку необхідно відзначити плюси і мінуси обох технологій

* HLD – High Level Design, LLD – Low Level Design

Одним з основоположних факторів в даній моделі є характеристики команди. Бем і Тернер розробили шкалу кваліфікації співробітників:

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

На основі наступної таблиці вибирають базовий метод управління проектом. Бем і Тернер виділили п'ять факторів для визначення базової моделі. Вони представлені в таблиці нижче:

Для візуалізації проекту була розроблена полярна діаграма.

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

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

У підсумку процес формування концепції управління проектом на базі аналізу ризиків набуває 5 кроків:

Перший крок - аналіз ризиків:

Проектування таблиці ризиків.

Оцінка ризиків для Agile і WaterFall методик

Крок другий - порівняння ризиків:

Якщо виявлено базовий метод, переходимо до кроку 4.

Якщо його з'ясувати однозначно не вдається - йдемо в проміжний крок № 3

Крок три - архітектурний аналіз:

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

Крок четвертий - побудова життєвого циклу розробки:

Команда використовує базовий метод розробки, який звіряє себе з ризиками таблиці з кроку № 1.

Крок п'ятий - виконання і моніторинг:

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

На блок діаграмі нижче графічно представлена схема процесу розробки на базі аналізу ризиків і балансування двох методик - Waterfall і Agile

Слід врахувати, що в методиці розробки Agile повинні брати участь керівники груп і провідні програмісти. У той час як юніорам краще не бути присутнім на Скрам мітингах.

Успішних вам проектів друзі!

Використані Джерела:

Boehm, B. and R. Turner (2003). Balancing Agility and Discipline: A Guide for the

Perplexed. Boston, MA, Addison Wesley.

Larman, C. (2004). Agile and Iterative Development: A Manager's Guide. Boston,

Addison Wesley.