Разработка продукта: «дискавери-фаза» и способы оценить необъятное

C чего начать IT-разработку и как посчитать стоимость, если вы создаете продукт с нуля, усиливаете команду или у вас есть идея MVP? Отвечаем на вопросы и делимся лайфхаками, с которыми мы оцениваем 400 проектов в год – в статье Анны Шведовой, главы направления бизнес-решений SimbirSoft. Затронем вопрос, что делать, если нет ТЗ, и как в проработке IT-решения помогает «дискавери-фаза».

Если вы хотите создать IT-продукт – будь то B2B-приложение для предприятия или «новый Uber» для B2C, на старте важно оценить объёмы разработки.

Имея детальную “смету” проекта, вам будет проще сделать следующие шаги – например, найти инвестора или защитить проект перед руководителем, подобрать необходимых специалистов и т.д. Кроме того, без оценки сложно определить как сроки разработки, так и необходимый состав команды.

Чтобы обеспечить точность расчетов и предусмотреть риски, компании стремятся собрать команду экспертов из нескольких подразделений. Зачастую это аналитик, дизайнер, опытные разработчики – по одному от всех задействованных направлений или те, у кого есть узконаправленная экспертиза, например, в построении highload-решений.

Так, у нас в SimbirSoft есть группа оценки – Presale-специалисты. Процесс оценки мы автоматизировали в собственном IT-сервисе, что позволяет оперативно и достоверно рассчитывать сроки и стоимость реализации проектов. Мы оцениваем около 400 проектов в год, на оценку стандартного проекта отводится в среднем 3-5 рабочих дней (в человеко-часах это будут иные цифры, т.к. каждый специалист подключается к процессу оценки только в нужное время).

Работа начинается со сбора требований к продукту. Хорошо, если у клиента есть техническое задание (ТЗ), спецификация или хотя бы краткое описание идеи, на основе которого мы можем сами составить список требований (UserStory) для MVP, по которому уже будут рассчитываться сроки и стоимость разработки.

Однако, не всегда есть сформулированные требования и/или пожелания. В этом случае мы используем иной подход к оценке. Рассмотрим, когда он бывает полезен.

Бывает так, что у клиента есть только идея будущего бизнеса (не “продукта”, а “бизнеса”). Нет ни ТЗ, ни четких требований, даже нет понимания, с чего начать – нет выделенного MVP. В этом случае компания-разработчик может предложить пойти двумя направлениями:

• Способ №1: начать с разработки ТЗ

Данный вариант оправдывает себя, если клиент уверен в “неизбежности” разработки продукта. Например, это B2B-продукт, необходимый для автоматизации бизнеса, без него клиент не сможет оставаться на лидирующих позициях на рынке. Клиенту не надо ни защищать идею перед топ-менеджерами, ни изыскивать бюджет – решение о необходимости продукта принято.

В этом случае необходимо провести аналитику: подготовку ТЗ, прорисовку прототипов – первые этапы (спринты) разработки продукта.

Однако, не всегда ситуация столь однозначна. Например, в случае стартапа клиент стремится сократить сроки проведения аналитики и затраты на неё. Для начала ему нужно сориентироваться с идеей, что-то визуализировать, прикинуть верхнеуровневую архитектуру, определить, какие функции можно и нужно реализовать сразу и в дальнейшем. И главное, узнать, сколько будет стоить и длиться разработка (и стоит ли вообще разрабатывать продукт). Подробнее об этом – в следующем пункте.

• Способ №2: провести «дискавери-фазу» исследования

«Дискавери-фаза» – это сбор информации об идее, формализация требований к продукту, проверка бизнес-гипотез, формализация решения и далее – оценка затрат как на начальную версию (MVP), так и на дальнейшее развитие.

Мы также называем его “нулевой” этап или “Фаза 0”, т.к. это еще не разработка, а только подготовка к старту проекта.

Отличие «дискавери-фазы» в том, что клиент в короткие сроки (2-4 недели) получает «мини-аналитику» будущего приложения. На основании этих данных уже можно сделать оценку, принять решение о дальнейшей разработке, и в случае старта проекта эти данные лягут в основу ТЗ.

Ниже рассмотрим основные “дискавери”-этапы и артефакты, которые мы и клиент получим в результате этих исследований. Этапы могут быть обязательными или необязательными, в зависимости от степени детализации концепции и типа проекта: например, в B2C-приветствуется прорисовка экранов будущего приложения, чтобы оценить UX и помочь будущим инвесторам “впечатлиться” идеей.

Работа, как правило, начинается с анализа идеи в таком объеме, который позволяет составить требования к будущему продукту или системе, оценить перспективы дальнейшего развития и, главное, выработать оптимальное IT-решение для бизнеса.

Задачи presale-специалиста:

• Узнать специфику работы и потребности клиента и пользователей.
• Определить, какими IT-инструментами клиент уже пользуется.
• Правильно выбрать вектор разработки (будет ли это мобильное приложение или сайт с адаптивом, готовое решение или разработка с нуля и т.п.).

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

Этот этап похож на этап аналитики, но с меньшим уровнем детализации. Мы должны собрать требования с уровнем точности, достаточным для подготовки оценки, без погружения в детали и нюансы. Мы фиксируем:

• Функциональные требования

Что должна делать система, кто с ней работает, какие у них права и уровни доступа.

• Нефункциональные требования

Как должна работать система (требования производительности, UX и т.п.)

• Ограничения

Всё, что нужно учесть при создании проекта: ограничения, связанные с законодательством, “железом”, скоростью интернет-соединения, бюджетами и сроками.

Даже при проработке MVP нужно планировать развитие продукта на несколько лет вперед. Это позволяет учесть все требования и ограничения, а также заложить гибкую архитектуру продукта. Например, один из наших клиентов начинает интернет-торговлю в своем регионе, но в перспективе он намерен расширять присутствие на рынке и проводить распродажи, во время которых количество пользователей сайта многократно вырастет. В этом случае архитектура проекта должна учитывать возможность масштабирования продукта и роста нагрузки

Вся информация оформляется в виде документов:

• Usеr Story – описывает функциональное требование.

• Бизнес-процессы. При необходимости ключевые User Story мы расписываем в виде бизнес-процессов для того, чтобы при оценке учесть всю сложность и масштабность функционала.

В случае, если мы анализируем проект по автоматизации процессов, то детальное представление “as is” (как есть) User Story помогает выявить узкие места (например: шаги, на которых работники тратят много времени или совершают ошибки) и предложить их корректировку и/или автоматизацию.

• Список нефункциональных требований и ограничений. В зависимости от требований к продукту, возможны различные варианты реализации. Перед началом работы нужно оценить, как они повлияют на продукт, на его стоимость, а также насколько они проработаны.

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

• Модель данных. Составляется предварительная логическая модель данных: сколько сущностей, какие параметры, какие данные и какого объема будут храниться в системе.

Это необходимо для проработки архитектуры и оценки дополнительных работ, таких как, например, нагрузочное тестирование.

После сбора требований мы прорабатываем оптимальное техническое решение или, в случае необходимости, сразу несколько вариантов. Основные этапы:

• Список задач (BackLog)

Как уже говорилось выше, здесь мы прорабатываем все требования – как для MVP, так и с расчетом на дальнейшее развитие продукта. Как правило (особенно при оценке крупных проектов) мы приоритезируем UserStory с целью разделить разработку на этапы и оцениваем каждый этап отдельно. При этом MVP – наивысший приоритет.

Например, если в MVP пользователи могут только скачать отчет в формате pdf, то в дальнейшем у них также появится возможность отредактировать отчет или переслать его в другие приложения.

• Архитектура и структура

Концепция обязательно включает предложение по верхнеуровневой архитектуре IT-продукта. Это схема всех компонентов системы, также внутренних или внешних сервисов (например, Яндекс.Карты или CRM клиента), с которыми нужно осуществлять взаимодействие – здесь мы определяем, какие данными будем обмениваться.

• Прототипы

Прорисовываем ключевые экраны, визуализируем, как может выглядеть будущее приложение.

Этот артефакт не обязателен, но крайне полезен, если требуется продемонстрировать идею инвестору, дать «пощупать» продукт пользователям и получить обратную связь.

• Оценка и RoadMap

Рассчитать сроки разработки можно с помощью разных инструментов, в том числе и в Excel-таблицах. У себя мы используем наш собственный сервис Estimate. Он позволяет настраивать шаблоны и нормочасы, учитывать риски и особенности так называемых bespoke-проектов – разработанных с нуля по индивидуальному заказу.

Результат дискавери-фазы – это горизонтальная мини-аналитика, которая позволяет охватить весь проект целиком, не уходя в детали.

Цель исследования – “прощупать” связанные с продуктом гипотезы и собрать требования, чтобы оценить сроки и стоимость разработки.

Закончив исследование, мы получаем концепцию проекта (или Vision). Она представляет собой документ, в котором кратко описаны задачи клиента и предлагаемое решение: архитектура, список функций и логическая модель данных, основные экраны, ожидаемые сроки и стоимость разработки. Фактически это готовое коммерческое предложение, с которым наш партнер может обратиться к инвестору или руководителю для согласования проекта.

Сроки проведения исследования могут составлять от 2 до 4 недель, в зависимости от сложности проекта и количества обязательных этапов “дискавери”.

Какие преимущества обеспечивает дискавери-фаза для заказчика:

• Получение наглядной концепции для тестирования бизнес-идеи.
• Оценка срока и бюджета разработки с учетом всех требований к продукту/проекту и перспектив его развития.
• Можно провести отдельные стартовые работы по аналитике и проектированию архитектуры – чтобы снизить трудозатраты на дальнейшую аналитику, ТЗ и roadmap.
• Снижение риска ошибок при реализации продукта.