В проектах по разработке продукта с нуля наша задача — помочь заказчику как можно быстрее запустить MVP, чтобы бизнес начал работать и приносить деньги. Чаще всего мы прибегаем к формату FFF: Fixed Price (фиксированная цена), Fixed Time (фиксированные сроки), Flex Scope (гибкий набор задач).
Обычно в продуктовой разработке используют гибкие методологии. Но на этапе запуска MVP они могут сбить фокус продакшн-команды с быстрого релиза на доведение продукта до идеала. Это замедляет развитие бизнеса.
При этом работа по классической waterfall-модели, когда весь продукт готовят по одному большому техническому заданию без промежуточных результатов, совсем ограничивает команду в гибкости. За несколько месяцев разработки приоритеты бизнеса могут не раз корректироваться. Последний пункт — Flex Scope (гибкий набор задач) — позволяет в оговоренные сроки и бюджет получить работающий продукт. Мы можем заменить менее приоритетные фичи более важными прямо в процессе разработки.
Подробнее о нашем подходе расскажем ниже.
Как происходит разработка цифрового продукта
Разработка с нуля состоит из следующих этапов: аналитики и проектирования, дизайна, разработки, тестирования и отладки. Мы можем подключиться к работе над проектом на любой стадии. Например, если у заказчика уже есть собранные прототипы, мы можем заняться дизайном. Если есть дизайн — переходим к разработке.
Разработку MVP чаще всего предлагаем по Fixed Price, закрепляем договором требования к срокам и стоимости. Если проект требует большей гибкости — мы подскажем заказчику, как выстроить работу, и возьмём на себя приоритизацию задач.
Из каких этапов состоит разработка
Аналитика и проектирование
Функциональность, полностью отвечающая интересам пользователей и бизнеса, — основа успешного продукта, поэтому мы начинаем работу над проектом с аналитики.
Когда приходит новый проект, собираем данные о бизнесе, его структуре и целях, аудитории. Наша команда интервьюирует заказчика и собирает бриф. На этом этапе требуется максимальное участие заказчика, минимум 2-3 встречи в неделю. Аналитика — командная работа, поэтому заказчик должен быть готов инвестировать своё время. Если неверно сформулировать структуру и требования к продукту или плохо расставить приоритеты, вносить изменения в уже работающий сервис может быть дорого. Самое главное — все потеряют время. Лучше предусмотреть всё заранее.
Вместе изучаем бизнес-цели заказчика и планы по развитию, собираем и документируем требования к будущему продукту. Затем аналитики разрабатывают концепцию и структуру сервиса.
Далее дизайнеры создают прототип — кликабельный образец продукта в виде проекта в Figma. Так команда клиента сможет самостоятельно просмотреть все экраны. Также на прототипах мы можем провести коридорное тестирование (проверяется на случайных людях) или полноценный юзабилити-тест (наблюдение за пользователем и выводы на основе этих наблюдений) на ядре аудитории продукта.
Это первое визуальное воплощение будущего сервиса. В прототипе нет цветов, анимаций и других визуальных атрибутов. Он нужен, чтобы согласовать функциональность и достижимость пользователями целевого действия, а также логику информационных блоков внутри продукта.
На основе прототипа и собранных функциональных требований мы пишем техническое задание.
Какие артефакты используем в проектировании
1. User Stories — это короткая формулировка, которая описывает, как система должна отвечать на действия пользователя.
Например: как администратор, я хочу иметь возможность создать нового пользователя в системе, чтобы дать новому сотруднику профиль для работы.
Описывая, как все типы пользователей взаимодействуют с сервисом, мы можем продумать пользовательские сценарии. На этом же этапе мы описываем критерии приёмки, чтобы в момент разработки вся продакшн-команда понимала, по какому принципу работает функциональность и что в ней должно быть учтено.
Мы писали большую и интересную статью о том, как используем User Stories в проектировании, читайте ее здесь:
Roadmap — User Stories группируются по важности для бизнеса, пользовательской логики и технических аспектов. На основе групп User Stories мы прорабатываем roadmap — карту, которая позволит выделить функции для MVP. С помощью дорожной карты проекта менеджеры планируют, какая команда и какой объём работ будет делать на соответствующем спринте.
Мы отмечаем важные контрольные точки в дорожной карте проекта вместе с заказчиком. Так он всегда будет знать, что происходит с разработкой, и на каком этапе мы сейчас находимся. Кроме того, roadmap позволяет фиксировать договорённости, если над продуктом работают несколько команд. На контрольных точках отмечают, что, от кого и к какой дате ждут, чтобы процесс не встал.
Техническое задание
В финале все требования собираются в техническое задание. Здесь мы документируем каждый элемент из прототипа: откуда он появляется и что происходит по его нажатию. Здесь же прописываем, как мы работаем с оптимизацией, какие в продукте будут интеграции, кто наши пользователи и так далее. Ещё одна важная часть технического задания — тест-кейсы. Когда функциональность готова, тестировщики проверяют её на ошибки, опираясь на тест-кейс — инструкцию для проведения проверок.
Дизайн
На основе утверждённых прототипов наши дизайнеры создают сначала дизайн-концепцию, а затем макеты всех страниц. Для определения стиля мы используем визуальные брифы и согласовываем с вами референсы.
Также мы разрабатываем UI-кит и дизайн-систему, чтобы отрисовка и разработка новых страниц занимала меньше времени. В этом решении на цифрах показали, сколько часов на проекте экономит внедрение дизайн-системы.
Разработка
Наш процесс разработки основан на грамотном планировании спринтов. Стараемся строить работу таким образом, чтобы у команды разработки в бэклоге были задачи на 2-3 спринта вперёд. Это помогает избегать пауз в работе над продуктом, если со стороны клиента есть задержки в обратной связи и согласованиях.
После утверждения дизайна мы приступаем к разработке фронтенда. Работаем на реактивных фреймворках Vue.js или React.js.
Бэкенд разрабатываем сразу после утверждения технического задания параллельно с дизайном, чтобы ускорить релиз.
Разрабатываем кроссплатформенные приложения на фреймворке Flutter. Такая разработка экономит до 40% стоимости по сравнению с нативной — не нужно разрабатывать два отдельных приложения под iOS и Android. Также снижается стоимость владения продуктом и ускоряется time-to-market, благодаря единой кодовой базе.
Применяем подход API Based. Сначала разрабатываем API, а потом интегрируем с ним клиентскую часть: фронтенд мобильного и веб-приложения. За счёт этого сокращаем бюджет и сроки разработки.
Для всех проектов мы настраиваем GitLab — систему контроля версий. В ней хранится информация об изменениях на сайте с возможностью вернуться к любому этапу. При необходимости предоставим вам и вашей команде доступ к просмотру.
Для разработки бэкенда мы используем фреймворк Django на Python. Он позволяет поддерживать высокое качество кода, соответствует всем современным требованиям по скорости обработки данных и легко масштабируется при необходимости.
Проекты разрабатываем на демо-площадке, которая расположена на нашем сервере и доступна по отдельной ссылке. Вы получите логин и пароль для входа на площадку, чтобы наблюдать за процессом разработки. Благодаря тестовой площадке во время демо можно будет «потрогать» продукт своими руками. В большинстве случаев в процессе разработки достаточно двух стейджей — Dev и Test. После релиза система будет выглядеть в классической модели: Dev, Test, Preprod, Prod.
Тестирование и отладка
Наши QA-инженеры тестируют всю функциональность продукта в конце каждого спринта.
Для тестирования используем наши внутренние чек-листы и тест-кейсы, можем дать доступ к ним по запросу. Помимо ручного тестирования применяем автотесты или нагрузочное тестирование по необходимости.
После разработки
Завершается разработка продукта финальным тестированием, проведением демо, запуском продукта в сторы и деплоем. После деплоя мы готовим инструкции, переносим проект на сервер клиента и передаём исходный код.
Далее мы берём на себя развитие продукта. Здесь все действия индивидуальны, мы вместе совершенствуем сервис в соответствии с вашими бизнес-задачами. Проверяем наличие и обновление разных технических компонентов, развиваем новую функциональность.
Два пути развития продукта
1. Выкуп команды. Из наших специалистов мы формируем отдельную постоянную команду для дальнейшей работы над продуктом. Сотрудников подбираем с учётом требований и специфики проекта. Идеальный вариант для долгосрочного развития.
2. Итерационное развитие. Развиваем проект небольшими этапами. Параллельно анализируем промежуточные результаты работы и выдвигаем новые требования к продукту.
Что получают наши заказчики
1. Регулярная отчётность
За нами не нужно бегать, чтобы узнать, что происходит на проекте. Мы расскажем всё до того, как заказчик успеет задать вопрос. Заказчик получаете два вида отчётов: еженедельный и ежемесячный. Это позволяет ему понимать, как идёт разработка. Также мы регулярно созваниваемся с заказчиком и демонстрируем промежуточные результаты проекта. Проводим еженедельный демо-дей, на котором демонстрируем новую функциональность, чтобы вся команда была погружена в контекст развития продукта.
2. Гибкая система оплаты
Формат оплаты обговариваем индивидуально. Чаще всего работаем на условиях частичной постоплаты: 50% от стоимости каждого этапа заказчик платит до его начала, 50% — после приёмки работ. При необходимости мы готовы обсудить разбивку общей суммы на более мелкие платежи.
3. Развитие продукта после релиза
После релиза мы предлагаем техподдержку. В договор мы можем заложить любые работы. Например, выделенные часы на постепенные доработки сервиса или регулярную техподдержку с круглосуточным мониторингом. Оплата по факту выполнения работы в конце месяца.
Ещё один формат сотрудничества — выкуп команды. Мы формируем оптимальную команду под продукт. Выбранные специалисты работают только над вашими задачами без переключения на другие проекты. Это помогает достичь максимального погружения и лучших результатов.
Наша команда:
интегрируется в процессы заказчика;
развивает и модернизирует архитектуру продукта;
погружается в бизнес-задачи и подбирает лучшие решения;
контролирует качество.
4. Гарантия на проект
В течение 6 месяцев после запуска на продукт действует гарантия. Если вы найдёте ошибку, мы устраним её за три дня. Если устранение потребует больше трёх дней — мы продлим гарантию на срок, который потребовался на решение проблемы.
Если вы в поисках подрядчика для разработки и запуска MVP — напишите нам в форму ниже. Мы ответим в течение суток, обсудим ваши задачи и подберём лучшее решение.
Свяжусь с вами в течение дня, чтобы уточнить детали проекта и сориентировать по стоимости разработки. После этого обсудим цели проекта, требования к нему и начнём работу.
Свяжусь с вами в течение дня, чтобы уточнить детали проекта и сориентировать по стоимости разработки. После этого обсудим цели проекта, требования к нему и начнём работу.
