Як оцінити ризики та можливості на етапі Discovery

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

Звучить жахливо, але статистика свідчить, що це доля восьми з десяти IT-стартапів. Як знайти інший шлях? Одна з головних причин поразок криється в хибному аналізі проєкту вже на самому його старті. Адже саме правильна оцінка ризиків на етапі discovery фази є ключем до успіху.

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

Що таке етап Discovery та в чому його важливість?

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

Найчастіше до discovery долучаються такі фахівці як бізнес-аналітики (BA), UI/UX дизайнери, проджект-менеджери (PM) та менеджери з продукту, сейлз-менеджери, технічні експерти з розробки (Solution Architect, Tech lead), а також галузеві експерти зі сфери для якої призначається продукт (SME, subject matter experts). У тісній взаємодії вони мають вирішити в рамках discovery низку завдань: 

• Збір інформації. Здійснюється аналіз стану індустрії, ринку, конкурентів, цільової аудиторії, наявних на ринку рішень тощо;

• Формулювання гіпотез. Збираються припущення щодо того, який продукт потрібен ринку, як він буде розв'язувати проблеми аудиторії; 

• Оцінка технічних можливостей. Визначення технічних можливостей та обмежень для реалізації проєкту;

• Тестування гіпотез. Перевірка припущень за допомогою різних методів, таких як опитування користувачів, A/B-тестування тощо.

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

Залежно від потреб проєкту фаза discovery може охоплювати навіть детальне прототипування чи створення MVP. 

Головне завдання цієї фази в IT-проєкті – визначити реалістичний шлях його втілення в життя, виявити потенційні проблеми та ризики. Чимало проєктів вже на етапі discovery демонструють свою нежиттєздатність або надмірну ризикованість, рятуючи бізнес від втрат. Щонайменше концепцію таких проєктів варто відкласти, або доопрацювати. Та навіть якщо ідея має очевидні перспективи, нехтувати фазою discovery не можна. Про це свідчать цифри. 

• За даними McKinsey&Company, у проєктах з якісним проведенням фази discovery продукт можна вивести на ринок на 20-30% швидше. Детальний збір вимог та опрацювання скоупу проєкту можуть прискорити його реалізацію на 45%

• За оцінкою Gartner, недостатня увага до збору вимог є причиною 70-80% провалів IT-проєктів. Добре структуровавна фаза discovery дозволяє мінімізувати ці ризики. 

• Дослідження IBM Systems Sciences Institute свідчать, що вартість виправлення помилки, виявленої вже після релізу продукту, може бути до 100 разів дорожчою, ніж її виявлення на етапі розробки вимог та проєктування. Тож якісний етап discovery може захистити проєкт від прихованих фінансових ризиків. 

Ґрунтовна оцінка можливостей проєкту на етапі discovery допомагає створити для нього цілу низку передумов успіху. Зокрема: 

• Точно визначити обсяг та скоуп робіт, а відповідно – точніше окреслити строки реалізації та кошторис проєкту;

• Ухвалювати на проєкті якісні рішення, що грунтуються на данних, а не на суб’єктивних припущеннях;

• Прискорити вихід продукту на ринок та повернення інвестицій;

• Реалізувати найкращий користувацький досвід, відштовхуючись від потреб аудиторії;

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

Водночас нехтування фазою discovery може дуже сильно нашкодити проєкту, навіть якщо він має всі об’єктивні передумови для успіху. Відсутність цілісного бачення та вектору розробки, нестача чітких критеріїв успіху та вимірюваних очікуваних результатів, нерозуміння ринку та аудиторії – усе це міни уповільненої дії, які врешті можуть перетворити розробку на хаос. У світі IT для таких хаотичних проєктів існує дуже красномовний термін: “виробниче пекло” (Development hell). В такій розробці скоуп робіт та витрати зростають неконтрольовано, дедлайни раз у раз зриваються, а гарантувати результат просто неможливо. 

Чому оцінка ризиків на етапі Discovery є критично важливою?

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

• Завчасне виявлення проблем

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

• Зменшення невизначеності 

Чітке розуміння можливих ризиків допомагає зменшити обсяги “білих плям” та невідомих факторів в проєкті. Це, своєю чергою, дозволяє ухвалювати більш обґрунтовані рішення, робить скоуп та дорожню карту проєкту більш реалістичною.

• Оптимізація ресурсів

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

• Поліпшення якості продукту

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

• Підвищення шансів на успіх 

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

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

Методи оцінки ризиків на етапі Discovery

Сфера проєктного менеджменту в IT напрацювала цілу низку методів оцінки ризиків. Зокрема – для етапу discovery. Нижче ми визначимо та розберемо найпопулярніші з них. 

SWOT-аналіз

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

• Сильні (Strengths) та Слабкі (Weaknesses) сторони процесу/проєкту

• Можливості (Opportunities) та Загрози (Threats), що виникають під час здійснення процесу/проєкту.

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

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

Метод PESTLE 

Аналітична модель PEST (в подальшому – PESTLE) була створена дослідником бізнес-планування Френсісом Агіларом у 1967 році. Її суть полягає в оцінці впливу на проєкт чинників зовнішнього середовища. Зокрема:

• Політичні (Political): врахування впливу політичних факторів, таких як стабільність уряду, законодавство, податкова політика тощо;

• Економічні (Economic): оцінка економічних факторів, таких як інфляція, безробіття, економічне зростання, привабливість інвестицій, валютні курси тощо;

• Соціальні (Social): аналіз соціальних трендів, таких як демографічні зміни, культурні та соціальні тенденції, споживчі уподобання, етика та ін; 

• Технологічні (Technological): прорахування впливу технологічних інновацій, швидкості технологічного розвитку та доступності нових технологій;

• Правові (Legal): оцінка впливу правового середовища, такого як законодавство про конфіденційність даних, інтелектуальну власність, регулювання технологій тощо;

• Екологічні (Environmental): визначення впливу екологічних факторів, таких як екологічні стандарти, вимоги сталого розвитку, відновлювана енергія і т.д.

Аналіз PESTLE вкрай важливий для будь-якого IT-проєкту, тому що дозволяє вчасно прорахувати комплексну реакцію суспільства на продукт. Відповідна оцінка ризиків на discovery фазі може вберегти бізнес від фінансових та репутаційних втрат. 

Діаграма Ішикави

Цю модель у 1952 році запропонував японський теоретик менеджменту Ішикава Каору. Діаграму Ішикави часто називають діаграмою “риб’ячого кістяка”, тому що вона пропонує характерну візуалізацію ключових причинно-наслідкових зв’язків між явищами. 

У такій діаграмі роль “риб’ячої голови” виконує проблема, що потребує рішення, чи результат, якого треба досягти. Від “голови” відходять гілки – вони ведуть до карток з усіма чинниками, що впливають на розв'язання проблеми або досягнення результату. На “риб'ячих ребрах” можуть міститись такі категорії як люди, процеси, технології, фактори PESTLE тощо. Це набагато простіше показати, ніж пояснити: 

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

Матриця ризиків

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

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

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

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

Дерево ризиків

Дерево ризиків (також відоме як дерево вибору, або дерево подій) – це ще один метод візуального моделювання й управління ризиками, який допомагає розробникам аналізувати та прогнозувати можливі наслідки тих чи інших рішень/подій на IT-проєкті.

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

Дерево ризиків допомагає оцінювати ризики на discovery фазі проєкту, оскільки дозволяє: 

• Прогнозувати можливі наслідки тих чи інших рішень та подій;

• Визначати ймовірність певних ризиків та їхній вплив на проєкт;

• Розробляти стратегії управління ризиками на основі аналізу сценаріїв;

• Визначати найбільш вразливі точки в проєкті, де ризики можуть бути критичними.

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

Метод FMEA

Методологія FMEA (Failure Mode and Effects Analysis) виникла на аерокосмічних підприємствах США, які свого часу зіткнулись із проблемою забезпечення надійності вкрай складних машин та технологій. Сьогодні FMEA широко застосовується у різних сферах для  ідентифікації потенційних відмов, визначення їхніх наслідків та побудови стратегій управління ризиками.  

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

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

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

Метод FMEA складний і потребує залучення висококласних фахівців, однак у деяких комплексних та суспільно важливих IT-продуктах контролювати ризики інакше неможливо. Використання FMEA на етапі discovery працює на якість, безпеку та прискорення розробки продукту. 

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

Оцінка можливостей та перспектив проєкту на етапі Discovery

Під час етапу досліджень вивчаються не лише ризики. Вона також є критично важливою для визначення потенціалу продукту.  Оцінка можливостей проєкту на етапі discovery фази дозволяє визначити та вдосконалити низку ключових параметрів продукту. Назвімо їх: 

• Бізнес-модель та монетизація

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

• Команда та ресурси

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

• Потенціал для зростання

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

• Технологічні та інноваційні можливості

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

• Фінансові перспективи

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

Розробка IT-рішень з командою WEZOM

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

Абсолютна більшість кейсів у нашому портфоліо – це продукти, створені з нуля. Відтак команда WEZOM чудово розуміє, як провести оцінку можливостей проєкту на discovery фазі, як визначити найболючіші ризики для продукту та ефективно мінімізувати їх. 

Ми ніколи не боялися складних завдань, та не відступали перед технічними викликами. Тож якщо ви шукаєте IT-команду, що готова пройти з вами через усі етапи розробки (від обговорення ідеї до релізу), то опинились на правильній сторінці. Звертайтесь по консультацію до WEZOM просто зараз. Наші менеджери радо вивчать вашу проблему, поділяться власним досвідом та запропонують оптимальні рішення. 

Висновки

Розробка диджитал-продуктів – непросте, та в чомусь ризиковане ремесло. Статистика свідчить, що три чверті проєктів в IT досягають успіху лише частково, або ж взагалі провалюються через проблеми з концепцією продукту, низьку якість та/або проблемний менеджмент. 

Аби досягнути успіху з продуктом, варто вже на старті приділити максимальну увагу дослідженням ринку та менеджменту ризиків. Такі методи як SWOT, PESTLE, FMEA та різноманітні моделі візуалізації допоможуть задокументувати ризики, аби оцінити їх небезпеку і вжити заходів. Не менш важливою є комунікація розробників з усіма зацікавленими сторонами. Такими як замовники рішення та галузеві експерти.
Далеко не кожний колектив розробників має достатній досвід, аби створювати IT-рішення з нуля. Ми рекомендуємо звертатись з такими проєктами до фахових команд, що напрацювали відповідне портфоліо та репутацію.