Заказчик — сеть гипермаркетов строительных материалов и товаров для дома из Барнаула. Задача — разработать инвестиционный продукт: мобильное приложение для всех, кто строит или делает ремонт. Целевая аудитория широкая: небольшие бригады, студии интерьера, архитектурные бюро, компании по ремонту, свободные мастера, строительные компании и частные лица, которые планируют или уже делают ремонт.
Продуктовая цель: приложение должно было стать инструментом привлечения новых покупателей и конкурентным преимуществом на рынке — перед Leroy Merlin, Алтерра, Hoff и IKEA. Основной референс — сервис для исполнителей от бренда «Петрович».
Ключевой функционал: создание объектов и смет, каталог работ с автоматическим пересчётом стоимости, координация сотрудников, контроль графика работ, коммуникация с клиентами, сквозной сценарий покупки материалов, экспорт существующих смет из Excel.
Стек: Axure RP, Figma.
Управленческие решения
1. Организовал предпроектную аналитику с акцентом на JTBD
Продукт создавался для широкой и разнородной аудитории — от частных мастеров до строительных компаний. Без понимания задач каждой группы разработка была бы усреднённой и не решала бы проблемы никого.
Решение: поставил задачу провести предпроектную аналитику по методу JTBD (Jobs To Be Done) — выявить, какие задачи пользователи «нанимают» продукт решать. Плюс анализ конкурентов, видение проекта и структура приложения.
Результат: на основе анализа сформирована структура приложения и понимание, какие сценарии критичны для каждой группы пользователей.
2. Выстроил процесс проектирования через интерактивный прототип
Для продукта с большим количеством взаимосвязанных сценариев (объекты → сметы → материалы → покупка → доставка) важно было проверить логику до дизайна.
Решение: организовал разработку интерактивного прототипа в Axure RP — чтобы заказчик мог кликать по сценариям, видеть связи между разделами и давать обратную связь по конкретике. Только после утверждения прототипа команда переходила к дизайну.
Результат: логика продукта была зафиксирована до визуальной части — это снижало риск переделок на следующих этапах.
3. Заложил в продукт механику удержания и снижения барьера входа
Один из ключевых рисков для нового сервиса — сложность «переезда» пользователей со своими наработками. Прораб или бригада, у которых уже есть сметы в Excel, не станут переносить всё вручную.
Решение: на этапе проектирования заложили функционал экспорта существующих смет — возможность оцифровать данные из Excel и сразу приступить к работе в сервисе. Плюс каталог работ с автоматическим пересчётом стоимости: если цена работы меняется, она обновляется во всех сметах, а не правится вручную.
Результат: продукт проектировался с учётом реального барьера входа для целевой аудитории — это усиливало его конкурентоспособность.
4. Заложил в проект сквозной сценарий покупки материалов
Приложение задумывалось не как отдельный сервис, а как часть экосистемы — с возможностью покупать материалы прямо из сметы. Это влияло на структуру продукта ещё на этапе проектирования.
Решение: на этапе аналитики и проектирования заложил связку приложения с основным сайтом заказчика — чтобы в сметах отображались актуальные цены и наличие товаров. Спроектировали разделение товаров и работ в сметах, сценарий «товары → корзина → доставка».
Результат: сценарий «смета → покупка → доставка» был заложен в структуру продукта как сквозной, без разрыва между планированием и закупкой.
5. Управлял проектом до момента остановки
Проект был заморожен на этапе дизайна — в компании заказчика произошло перераспределение ресурсов, и продукт не получил дальнейшую инвестиционную поддержку.
Решение: держал команду в курсе ситуации, зафиксировал результаты проделанной работы, чтобы в случае возобновления проекта можно было продолжить с точки остановки без потери контекста.
Результат: на момент остановки были готовы предпроектная аналитика, интерактивный прототип и дизайн. Проект закрыт по решению заказчика — это внешнее обстоятельство, не связанное с ходом работ.
Результат проекта
- Проведена предпроектная аналитика: видение проекта, анализ ЦА по JTBD, анализ конкурентов, структура приложения
- Разработан интерактивный прототип в Axure RP
- Подготовлен дизайн приложения
- Заложен функционал: создание объектов и смет, каталог работ, координация сотрудников, календарь работ, коммуникация с клиентами, сквозной сценарий покупки материалов, экспорт смет из Excel
- Проект остановлен на этапе дизайна по решению заказчика (перераспределение ресурсов), не получил дальнейшую инвестиционную поддержку
Чему научился
Широкая аудитория требует чёткого разделения сценариев. Когда продукт создаётся «для всех, кто строит», важно понимать задачи каждой группы — иначе получается усреднённое решение, которое не подходит никому. JTBD помог структурировать это понимание.
Прототип до дизайна — это страховка от переделок. Для продукта с большим количеством взаимосвязанных сценариев проверка логики на прототипе экономит время и бюджет на более поздних этапах.
Не все проекты доходят до релиза — и это часть работы. Проект может быть остановлен по причинам, которые от тебя не зависят. Важно довести свою часть качественно и зафиксировать результат, чтобы он не потерялся.