Антон Ставицький
28.12.2022
•
5 хв читання
Начало IT-проекта иногда приносит непредсказуемый результат. Работы могут затянуться и потребовать дополнительных затрат, отдельные функции останутся невостребованными, а возможно и сама идея окажется неосуществимой. Более того. Даже если задание будет выполнено за выделенное время и не потребует дополнительного финансирования, все будет соответствовать спецификациям – нет никакой гарантии коммерческого успеха проекта.
Для того чтобы снизить вероятность неудачи и существует так называемая Дискавери-фаза.
Неопределенность – это один из наиболее весомых минусов, которыми характеризуется начало любого проекта. На старте очень трудно сразу определить каких пределов может достигнуть масштаб IT-проекта, что из функционала будет важным для пользователя, а без чего можно будет легко обойтись, какие бизнес-процессы и технологические сложности могут помешать реализации проекта. И конечно вопрос финансирования – окупит ли использование конечного IT-продукта затраты на его разработку, внедрение и поддержку?
Ответить на эти вопросы можно на этапе исследования IT-проекта. По крайней мере можно минимизировать неопределенность на старте, зафиксировав область применения IT-продукта и получив реальные сроки выполнения работ, а также составив смету расходов с цифрами, максимально приближенными к окончательным.
Взвешенное решение о том, стоит ли разработка запланированных инвестиций, позволит составить точный оптимизированный план реализации IT-проекта, а также минимизировать риски. При этом подготовительный период определяет дальнейшее развитие программного продукта, не увеличивая конечную стоимость.
Данный этап не является обязательным и в пользу этого есть немало аргументов. Например то, что подготовка может занять от 2 до 4 недель, потребуются расходы на оплату работы аналитика, технического специалиста, дизайнера и руководителя. Поэтому в целях экономии для более быстрого старта и сокращение периода окупаемости вложений от этого этапа часто отказываются. Но в долгосрочной перспективе такая экономия может повлечь за собой задержки, неоправданное увеличение затрат, а также несоответствие результата ожиданиям.
В связи с этим можно вспомнить, что произошло с мобильным приложением Everest. Идея его создания очень понравилась публике и на разработку платформы инвесторы выложили более 2 миллионов долларов. Но процесс затянулся и перешагнул установленный дэдлайн в полгода.
Вместо того чтобы сосредоточиться на реализации базового функционала, неоднократно принималось решение о добавлении дополнительных функций. В результате в приложении оказалось много ненужного, без чего вполне можно было бы обойтись. Выход релиза показал, что программа работает медленно и время от времени перестает функционировать. К тому же оказалось, что и пользоваться ею неудобно. В результате бюджет был исчерпан задолго до завершения работ, и, просуществовав около 2 лет, проект был закрыт.
Это наглядно показывает, что уникальность и востребованность IT-продукта не является гарантией успеха. Очень важно рационально распорядиться инвестициями и не вкладываться в создание слабо востребованного функционала. А составить реалистичный план можно именно на этапе Discovery.
Большое влияние на комплекс задач, которые придется решить на данном этапе, оказывают требования заказчика, а также масштаб и характер IT-проекта. Чтобы точно описать, что происходит в процессе исследования, разделим задачи на три основных вида:
Определение целей бизнеса.
Исследование рынка.
Определение проблемных точек и подготовка первичной спецификации.
Вначале производится сбор требований, предъявляемых клиентом к работающей системе, а также их систематизация. Группой специалистов вырабатывается единая точка зрения на проблематику, производится определение объема заданий и целей. Фиксируются данные, показывающие прогресс и указываются результаты, к которым надо стремиться. Составляется ментальная карта проекта, позволяющая увидеть собственными глазами его масштабы, а также зафиксировать роли и сроки исполнения, выделенные на каждый этап разработки.
Поскольку никто лучше владельца бизнеса и его компетентных представителей не знает, что в итоге требуется получить, то необходимо, чтобы они участвовали в обсуждении. Активное взаимодействие на данном этапе позволит максимально точно смоделировать будущую систему.
IT-продукт нельзя начинать разрабатывать, пока вы не ответите на следующие вопросы:
Какую целевую аудиторию вы можете считать своей?
Каким образом предлагаемая программа решит проблемы, стоящие перед ней?
Сможет ли приложение конкурировать с тем, что предлагают другие компании?
Какие предлагаемые возможности действительно интересны клиенту?
В результате исследования рынка и предложений конкурентов аналитик находит ответы. Ещё он общается непосредственно с вашей аудиторией, собирая данные о том, что ей нужно в первую очередь.
Результатом для данного этапа является пошаговое описание взаимодействия потенциального клиента с вашим приложением или веб сайтом – это так называемая User Story (пользовательская история). Она помогает убедиться в том, что все потребности целевой аудитории удовлетворяются в текущей версии создаваемого программного продукта и дает возможность исключить ненужные функции. В дальнейшем User Story используется при разработке UX-прототипа будущего IT-продукта.
В этой части этапа определяются требования к функциональным особенностям, необходимым и достаточным для создания минимально жизнеспособного IT-продукта (MVP). Это позволяет немедленно проверить идею на реальных пользователях.
Эксперт проверяет наличие узких мест, связанных с выполнением основных функций. Технический специалист дает рекомендации по наиболее подходящий архитектуре и по списку технологий, которые можно применить.
Самый сложный и непроверенный функционал требуется протестировать перед запуском. Данная задача решается с помощью специального инструмента – Proof of Concept.
На этом этапе определяются также не функциональные требования, способные оказать существенное влияние на стоимость разработки и сроки, если забыть о них на старте. Сюда входят:
Специфические для компании или страны правила, по которым действуют бизнес-процессы.
Правовые требования.
Ограничения, налагаемые инструментами и стратегиями разработки.
Взаимодействие с внешними интерфейсами, включая требования к API системы или IT-продукта.
В результате заказчик получает предварительную оценку разработки, в которую входят затраты на запуск и сроки выполнения задания, а также рекомендации по составу команды. Задача этой фазы состоит в том, чтобы сделать любые изменения при непосредственной разработке более простыми в реализации и предсказуемыми.
В самом начале работы, конечно, очень важно выявить узкие места в проекте. И это надо сделать обязательно. Но не менее важно и проверить общую концепцию, поскольку только так можно получить четкий ответ на следующие вопросы:
Действительно ли осуществим предлагаемый метод, технология или идея, и будет ли программный продукт работать вообще?
Насколько затратным и сложным в реализации будет внедрение?
Многолетний опыт показывает, что используемый при создании стандартных IT приложений подход практически никогда не работает или работает неправильно в том случае, если требуется создание с нуля инновационного IT-продукта. Поэтому, когда для реализации новаторской идеи необходимо убедиться в том, что нет никаких ограничений, препятствующих реализации проекта, и что затраты на внедрении не выйдут за рамки разумного, специалисты рекомендуют начинать тестирование с наиболее инновационных и сложных функций. И делать это надо в самом начале, поскольку концепция только формируется, а значит внесение изменений не приведет к срыву сроков и значительному превышению бюджета разработки.
Очень часто PoC путают с MVP, принимая проверку концепции за своего рода черновик проекта, который нуждается в доработке, только после этого может быть запущен в дело. Фактически же, проверка концепции представляет собой дополнительные исследования, ориентированные лишь на небольшую часть будущего приложения, а не на всю систему целиком. Она позволяет определить имеющиеся технологические ограничения и выяснить, можно ли их обойти.
С помощью PoC можно довольно точно оценить затраты труда и установить сроки – в качестве основы для реализации необходимых функций бизнес получает конкретные значения. Результаты исследования могут показать, что реализация идеи потребует больших затрат чем ожидалось, или же что ее вообще невозможно реализовать. В таком случае у вас появляется возможность, не тратя лишние финансовые ресурсы отказаться от продолжения разработки и направить сэкономленные средства для реализации более удачного проекта.
Обзор концепции в среднем занимает около одного месяца. В течение этого периода определяется функционал, формируется список возможных сценариев использования приложения, разрабатывается и тестируется PoC. После окончания работы заказчик получает техническое доказательство состоятельности идеи, подробный отчет с указанием найденных ограничений и недостатков, а также рекомендации по дальнейшему развитию.
После подтверждения реализуемости идеи необходимо узнать, будет ли IT-продукт востребован пользователями, то есть определить его в жизнеспособность (MVP).
Наличие большого количества перспективных идей, точно так же, как и их полное отсутствие, способно стать причиной неудачи при реализации проекта. На приложение с функционалом, который может оказаться слишком сложным для пользователя, не всегда целесообразно тратить бюджет. Ваше желание минимизировать риски вполне совпадает с предлагаемый методикой – вы можете сначала разработать только базовый функционал, необходимый для своевременного запуска в рамках установленного бюджета. При этом нельзя откладывать тестирование до полного завершения разработки.
На создание MVP обычно уходит полтора месяца. Вначале определяются и сортируются по приоритету основные функции, составляется функциональная карта, а также готовятся прототипы будущего программного продукта. После этого начинается непосредственное создание MVP.
Такой подход позволяет компании OCEAN одновременно вести несколько проектов, дорабатывая еще на начальных стадиях те из них, которые не вызвали у аудитории большого энтузиазма. То есть, поставив перед нами несколько проблем сразу, вы можете ускорить освоение новых рыночных ниш.
Создать продукт, пользующийся успехом у целевой аудитории, можно проанализировав потребности клиентов. Мы уже говорили, что на начальном этапе производится сбор информации о продукте, а также составление пользовательской истории, что позволяет создать прототип UX, который будет соответствовать потребностям потенциальных пользователей. Такой подход позволяет глубже проанализировать потребности целевой аудитории, выполняя тестирование прототипов на реальных людях. Причем ещё до окончательного завершения работ над продуктом.
В сотрудничестве с заказчиком происходит согласование описания целевой аудитории. Создается макет интерфейса, на основе которого с привлечением фокус-группы осуществляется тестирование продукта. Результаты тестирования фиксируются, в прототипы вносятся изменения. Процесс повторяется столько раз, сколько необходимо для того, чтобы результат начал полностью соответствовать подставленному заданию. Клиенту передаются детализированные макеты программного продукта, в дальнейшем используемые проектной командой.
Как показывает опыт, Customer Development позволяет на начальном этапе сэкономить до 70 процентов бюджета.
Желание сократить процесс творения IT-продукта и стремление прийти к финишу раньше конкурентов может сыграть с владельцем бизнеса злую шутку. Игнорируя Дискавери-фазу и связанные с ней этапы и считая, что они являются необязательными, можно запросто потерпеть неудачу даже при реализации стопроцентно удачной идеи.
В то же время, если эти процессы становятся неотъемлемой составляющей комплекса работ над новым продуктом, то вы получаете следующий результат: ваш бизнес становится более успешным, развивается быстрее, увеличивая прибыль и опережая конкурентов. Новые клиенты с удовольствием пользуется вашей программой, точно соответствующей их ожиданием.
Антон Ставицький
Редактор, Ocean
