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