Разработка продукта: «дискавери-фаза» и способы оценить необъятное
C чего начать IT-разработку и как посчитать стоимость, если вы создаете продукт с нуля, усиливаете команду или у вас есть идея MVP? Отвечаем на вопросы и делимся лайфхаками, с которыми мы оцениваем 400 проектов в год – в статье Анны Шведовой, главы направления бизнес-решений SimbirSoft. Затронем вопрос, что делать, если нет ТЗ, и как в проработке IT-решения помогает «дискавери-фаза».
Делимся опытом, как проводит оценки команда SimbirSoft, и показываем примеры из нашей практики – более 900 проектов, реализованных за 20+ лет. Надеемся, что наш опыт может быть полезен как заказчикам – мы расскажем, какая исходная информация нужна для оценки проекта, так и коллегам по отрасли – обменяемся уникальной presale-экспертизой.
Что такое оценка продукта
Если вы хотите создать IT-продукт – будь то B2B-приложение для предприятия или «новый Uber» для B2C, на старте важно оценить объёмы разработки.
Имея детальную “смету” проекта, вам будет проще сделать следующие шаги – например, найти инвестора или защитить проект перед руководителем, подобрать необходимых специалистов и т.д. Кроме того, без оценки сложно определить как сроки разработки, так и необходимый состав команды.
Чтобы обеспечить точность расчетов и предусмотреть риски, компании стремятся собрать команду экспертов из нескольких подразделений. Зачастую это аналитик, дизайнер, опытные разработчики – по одному от всех задействованных направлений или те, у кого есть узконаправленная экспертиза, например, в построении highload-решений.
Так, у нас в SimbirSoft есть группа оценки – Presale-специалисты. Процесс оценки мы автоматизировали в собственном IT-сервисе, что позволяет оперативно и достоверно рассчитывать сроки и стоимость реализации проектов. Мы оцениваем около 400 проектов в год, на оценку стандартного проекта отводится в среднем 3-5 рабочих дней (в человеко-часах это будут иные цифры, т.к. каждый специалист подключается к процессу оценки только в нужное время).
Работа начинается со сбора требований к продукту. Хорошо, если у клиента есть техническое задание (ТЗ), спецификация или хотя бы краткое описание идеи, на основе которого мы можем сами составить список требований (UserStory) для MVP, по которому уже будут рассчитываться сроки и стоимость разработки.
Однако, не всегда есть сформулированные требования и/или пожелания. В этом случае мы используем иной подход к оценке. Рассмотрим, когда он бывает полезен.
«Дискавери-фаза»
Бывает так, что у клиента есть только идея будущего бизнеса (не “продукта”, а “бизнеса”). Нет ни ТЗ, ни четких требований, даже нет понимания, с чего начать – нет выделенного MVP. В этом случае компания-разработчик может предложить пойти двумя направлениями:
- Способ №1: начать с разработки ТЗ
Данный вариант оправдывает себя, если клиент уверен в “неизбежности” разработки продукта. Например, это B2B-продукт, необходимый для автоматизации бизнеса, без него клиент не сможет оставаться на лидирующих позициях на рынке. Клиенту не надо ни защищать идею перед топ-менеджерами, ни изыскивать бюджет – решение о необходимости продукта принято.
В этом случае необходимо провести аналитику: подготовку ТЗ, прорисовку прототипов – первые этапы (спринты) разработки продукта.
Однако, не всегда ситуация столь однозначна. Например, в случае стартапа клиент стремится сократить сроки проведения аналитики и затраты на неё. Для начала ему нужно сориентироваться с идеей, что-то визуализировать, прикинуть верхнеуровневую архитектуру, определить, какие функции можно и нужно реализовать сразу и в дальнейшем. И главное, узнать, сколько будет стоить и длиться разработка (и стоит ли вообще разрабатывать продукт). Подробнее об этом – в следующем пункте.
- Способ №2: провести «дискавери-фазу» исследования
«Дискавери-фаза» – это сбор информации об идее, формализация требований к продукту, проверка бизнес-гипотез, формализация решения и далее – оценка затрат как на начальную версию (MVP), так и на дальнейшее развитие.
Мы также называем его “нулевой” этап или “Фаза 0”, т.к. это еще не разработка, а только подготовка к старту проекта.
Отличие «дискавери-фазы» в том, что клиент в короткие сроки (2-4 недели) получает «мини-аналитику» будущего приложения. На основании этих данных уже можно сделать оценку, принять решение о дальнейшей разработке, и в случае старта проекта эти данные лягут в основу ТЗ.
Ниже рассмотрим основные “дискавери”-этапы и артефакты, которые мы и клиент получим в результате этих исследований. Этапы могут быть обязательными или необязательными, в зависимости от степени детализации концепции и типа проекта: например, в B2C-приветствуется прорисовка экранов будущего приложения, чтобы оценить UX и помочь будущим инвесторам “впечатлиться” идеей.
Этапы исследования
1) Анализ идеи
Работа, как правило, начинается с анализа идеи в таком объеме, который позволяет составить требования к будущему продукту или системе, оценить перспективы дальнейшего развития и, главное, выработать оптимальное IT-решение для бизнеса.
Задачи presale-специалиста:
- Узнать специфику работы и потребности клиента и пользователей.
- Определить, какими IT-инструментами клиент уже пользуется.
- Правильно выбрать вектор разработки (будет ли это мобильное приложение или сайт с адаптивом, готовое решение или разработка с нуля и т.п.).
На старте специалист выявляет требования к продукту, например, проводит интервью, анкетирование, анализ рынка (для инновационных идей) или конкурентный анализ (если идея не новая, и уже есть аналоги). Также он определяет, кто будет пользователем продукта и какие задачи он решает.
2) Требования к продукту
Этот этап похож на этап аналитики, но с меньшим уровнем детализации. Мы должны собрать требования с уровнем точности, достаточным для подготовки оценки, без погружения в детали и нюансы. Мы фиксируем:
- Функциональные требования
Что должна делать система, кто с ней работает, какие у них права и уровни доступа.
- Нефункциональные требования
Как должна работать система (требования производительности, UX и т.п.)
- Ограничения
Всё, что нужно учесть при создании проекта: ограничения, связанные с законодательством, “железом”, скоростью интернет-соединения, бюджетами и сроками.
Случай из нашей практики: мы оценивали разработку приложения для ВУЗов, и одним из ограничений была низкая скорость доступа пользователей в интернет. Исходя из этого ограничения, мы заложили возможность работы основного функционала в офлайн-режиме.
Даже при проработке MVP нужно планировать развитие продукта на несколько лет вперед. Это позволяет учесть все требования и ограничения, а также заложить гибкую архитектуру продукта. Например, один из наших клиентов начинает интернет-торговлю в своем регионе, но в перспективе он намерен расширять присутствие на рынке и проводить распродажи, во время которых количество пользователей сайта многократно вырастет. В этом случае архитектура проекта должна учитывать возможность масштабирования продукта и роста нагрузки
Вся информация оформляется в виде документов:
- Usеr Story – описывает функциональное требование.
- Бизнес-процессы. При необходимости ключевые User Story мы расписываем в виде бизнес-процессов для того, чтобы при оценке учесть всю сложность и масштабность функционала.
В случае, если мы анализируем проект по автоматизации процессов, то детальное представление “as is” (как есть) User Story помогает выявить узкие места (например: шаги, на которых работники тратят много времени или совершают ошибки) и предложить их корректировку и/или автоматизацию.
- Список нефункциональных требований и ограничений. В зависимости от требований к продукту, возможны различные варианты реализации. Перед началом работы нужно оценить, как они повлияют на продукт, на его стоимость, а также насколько они проработаны.
Например, если компания хочет продвигать в нескольких странах приложение, которое содержит персональные данные пользователей, то архитектура проекта должна соответствовать законодательству всех необходимых стран.
- Модель данных. Составляется предварительная логическая модель данных: сколько сущностей, какие параметры, какие данные и какого объема будут храниться в системе.
Это необходимо для проработки архитектуры и оценки дополнительных работ, таких как, например, нагрузочное тестирование.
3) Решение
После сбора требований мы прорабатываем оптимальное техническое решение или, в случае необходимости, сразу несколько вариантов. Основные этапы:
- Список задач (BackLog)
Как уже говорилось выше, здесь мы прорабатываем все требования – как для MVP, так и с расчетом на дальнейшее развитие продукта. Как правило (особенно при оценке крупных проектов) мы приоритезируем UserStory с целью разделить разработку на этапы и оцениваем каждый этап отдельно. При этом MVP – наивысший приоритет.
Например, если в MVP пользователи могут только скачать отчет в формате pdf, то в дальнейшем у них также появится возможность отредактировать отчет или переслать его в другие приложения.
- Архитектура и структура
Концепция обязательно включает предложение по верхнеуровневой архитектуре IT-продукта. Это схема всех компонентов системы, также внутренних или внешних сервисов (например, Яндекс.Карты или CRM клиента), с которыми нужно осуществлять взаимодействие – здесь мы определяем, какие данными будем обмениваться.
- Прототипы
Прорисовываем ключевые экраны, визуализируем, как может выглядеть будущее приложение.
Этот артефакт не обязателен, но крайне полезен, если требуется продемонстрировать идею инвестору, дать «пощупать» продукт пользователям и получить обратную связь.
- Оценка и RoadMap
Рассчитать сроки разработки можно с помощью разных инструментов, в том числе и в Excel-таблицах. У себя мы используем наш собственный сервис Estimate. Он позволяет настраивать шаблоны и нормочасы, учитывать риски и особенности так называемых bespoke-проектов – разработанных с нуля по индивидуальному заказу.
Что мы получаем
Результат дискавери-фазы – это горизонтальная мини-аналитика, которая позволяет охватить весь проект целиком, не уходя в детали.
Цель исследования – “прощупать” связанные с продуктом гипотезы и собрать требования, чтобы оценить сроки и стоимость разработки.
Закончив исследование, мы получаем концепцию проекта (или Vision). Она представляет собой документ, в котором кратко описаны задачи клиента и предлагаемое решение: архитектура, список функций и логическая модель данных, основные экраны, ожидаемые сроки и стоимость разработки. Фактически это готовое коммерческое предложение, с которым наш партнер может обратиться к инвестору или руководителю для согласования проекта.
Сроки проведения исследования могут составлять от 2 до 4 недель, в зависимости от сложности проекта и количества обязательных этапов “дискавери”.
Выводы
Какие преимущества обеспечивает дискавери-фаза для заказчика:
- Получение наглядной концепции для тестирования бизнес-идеи.
- Оценка срока и бюджета разработки с учетом всех требований к продукту/проекту и перспектив его развития.
- Можно провести отдельные стартовые работы по аналитике и проектированию архитектуры – чтобы снизить трудозатраты на дальнейшую аналитику, ТЗ и roadmap.
- Снижение риска ошибок при реализации продукта.