Как оценить риски и возможности на этапе 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-решения с нуля. Мы рекомендуем обращаться с такими проектами к профессиональным командам, наработавшим соответствующее портфолио и репутацию.