Первым шагом в запуске IT-продукта является чёткое понимание задачи, которую продукт должен решать. Второй важный шаг — проектное исследование. Они помогают заложить основу для последующих этапов разработки: от проектирования MVP до запуска сервиса.

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

Что такое понимание задачи

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

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

Если продукт сложный и комплексный, то мы проводим углублённое исследование.

Что такое проектное исследование

Проектное исследование

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

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

По итогам работы клиент получает поэтапный план реализации IT-сервиса, который может включать:

• CJM-карту — взаимодействие клиентов с продуктом на разных этапах.
• User Story Map — пользовательские сценарии по ролям и версиям продукта.
• Кликабельный прототип — позволяет заказчику протестировать систему от лица пользователя.
• Техническая архитектура — документ, описывающий технологический стек, архитектуру базы данных, расчёт нагрузки, интеграции с внешними системами и требования к хостингу.
• Описание продукта — резюмирующий документ, который содержит всю информацию о будущем сервисе, включая описание ролей, сценариев и требований.
• План-график — уточняет состав команды, виды работ, задачи. Включает диаграмму Ганта на весь период разработки.
• Бюджет проекта — затраты на разработку по месяцам.

Состав материалов зависит от конкретного проекта. В процессе работы мы понимаем, какие документы лучше всего подходят для данного продукта. Например, мы можем подготовить для клиента User Flow — схему экранов продукта и переходов между ними, карту гипотез, бэклог задач и другие материалы.

Проектное исследование — это больше, чем техническое задание. Оно позволяет детально описать бизнес-идею, учесть ограничения и риски, рассмотреть сценарии и предоставить клиенту чёткий план реализации проекта с точными сроками и бюджетом.

Александр Солтан Продукт-директор Brele

Представьте, в Brele обратилась компания, которой нужен маркетплейс. Мы проанализировали запрос и выяснили, что для решения бизнес-задачи клиенту нужно совсем другое решение.

Как работает проектное исследование на практике

Давайте разберём конкретный пример, когда заказчик пришел с идеей продукта:

Клиент — региональный дистрибьютор 1С, имеет базу проверенных интеграторов продуктов 1С и готов делиться их контактами со своими заказчиками.

Бизнес-идея клиента. Создать маркетплейс интеграторов 1С, где компании смогут выбрать исполнителя для установки или внедрения софта. Основатель проекта имеет чёткие критерии отбора подрядчиков, базу проверенных компаний и прямые связи с ними. В итоге должна была получиться биржа специалистов по 1С.

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

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

Понимание задачи. Мы начали задавать вопросы клиенту и выяснили, что его первостепенная задача — проверить, насколько востребованы услуги по подбору интеграторов 1С. Однако заказчику нецелесообразно тратить 5 млн рублей на проверку гипотезы. Вместо этого мы предложили провести анализ и найти менее ресурсозатратное решение для её проверки.

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

Изучив все детали, мы предложили клиенту вариант реализации, который отличается от его первоначального запроса. В течение месяца мы описали бизнес-модель продукта, и определили, из чего будет состоять его MVP.

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

Вместо маркетплейса мы предложили создать партнёрскую программу для интеграторов 1С, которая включает:

• Два лендинга с внешними интеграциями: один — для заказчиков, второй — для исполнителей.
• Веб-анкеты, на основании которых заполняются карточки заявок и партнёров.
• CRM для автоматического подбора требований клиента и предложений интеграторов.

Разработка такого MVP стоит минимум в 5 раз дешевле, чем маркетплейса.

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

Теперь давайте сравним, насколько первоначальный запрос отличается от понимания задачи:

Задача кардинально изменилась, и возможное решение стало иным по форме, содержанию, срокам и бюджету.

Какие вопросы задать перед запуском проекта

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

1. О бизнесе

Как вы работаете? На чём зарабатываете? Где берёте клиентов? Какой канал продаж самый эффективный?

Как устроена ваша компания? Благодаря чему она развивается? В чём её сила? Какова главная цель компании сегодня?

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

2. Главная задача

Какая ближайшая задача стоит перед вашей компанией? Каковы ваши ближайшие планы? Чего вы хотите добиться?

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

3. Возможное решение

Как можно решить вашу задачу? Чем, по вашему мнению, мы можем стать полезны для вас? Почему вы считаете, что эффективнее улучшать сайт (или другой продукт)?

Что бы вы хотели сделать в первую очередь? Что бы вы сделали, если бы у вас было 1,5 месяца на проект от начала дизайна до запуска?

Когда проект должен быть закончен, открыт, запущен? Почему эта дата важна?

Что вы будете считать успехом проекта? Как будете оценивать, удался ли проект или провалился?

4. Ожидания

В каком виде ожидаете получить результат? Каковы ваши ожидания по взаимодействию? Что для вас важно в исполнителях, с которыми будете работать?

Что вызывает у вас опасения? Что может пойти не так?

Кто будет работать над проектом с вашей стороны? Кто и как будет принимать важные решения о проекте в целом и о дизайне в частности? За кем последнее слово?

Какова ваша личная роль в компании и проекте? Какие ещё компании или организации будут участвовать в проекте? Как и в какой роли?

Какие особенности вашей компании могут упростить или усложнить работу над проектом или отдельными его частями?

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

***

Если у вас есть идея, но вы не знаете, как её реализовать, то мы в Brele поможем вам спроектировать MVP. Чтобы обсудить проект, просто заполните форму в правом верхнем углу страницы.