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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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