Этапы продуктовой разработки: инструкция от Red Collar
Рассказываем о том, как с нуля создаём сложные цифровые продукты и из каких этапов состоит продуктовая разработка.
Мы — Red Collar. Если вы о нас слышали, то, наверняка, в первую очередь как о диджитал-агентстве.
Мы времени даром не теряли: развивались в интересующих нас сферах и, как результат, эволюционировали в компанию-разработчика, которая умеет создавать с нуля сложные IT-продукты.
В этой работе мы выступаем как стартап-лаборатория: проходим все стадии от предпроектной аналитики и формирования гипотез до создания дизайн-концепции, разработки и даже брендинга будущего продукта.
Эти процессы мы на протяжении нескольких лет выстраивали так, чтобы создать комфортный темп разработки для нас и результативный — для заказчика. Скажем сразу: получалось не всегда, и теперь мы готовы поделиться нашими наработками, поскольку наш опыт может быть полезен другим компаниям-разработчикам.
По нашему грандиозному плану, эта публикация — первая в серии статей, где мы подробно опишем каждый этап создания цифрового продукта и функции всех команд.
Сегодня же мы расскажем про начальные этапы заказной продуктовой разработки и перечислим основные типы наших заказчиков.
Продуктовая разработка: заказчики
Всё начинается с идеи.
Заказчики приходят к нам с самыми разными идеями цифровых продуктов: это и разработка с нуля, и поддержка существующих решений, и перевод в «цифру», и многое другое.
Весь этот опыт мы объединили и конвертировали в небольшую классификацию.
Стартапы
Как правило, стартапы приходят только с идеей. И, как правило, с идеей приходят те стартапы, у владельцев которых уже есть бизнес в других сферах в офлайне, а стартап — это способ расшириться и попробовать закрепиться в новой диджитал-сфере. Соответственно, чёткого понимания новой сферы, рынка и его потребностей может и не быть, поэтому Red Collar выступает в роли консультанта: во-первых, глубоко анализирует рынок, во-вторых, рекомендует заказчикам, какую именно команду для развития продукта нужно будет иметь в штате в дальнейшем.
Далеко не всегда в результате аналитики первоначальная идея клиента остается неизменной. После изучения причин появления идеи и ситуации в реальном мире (исследований окружения и потребностей рынка) концепция может измениться. Мы стараемся не дублировать существующие решения и пытаемся новой идеей заполнить пустующую нишу. И вот тут очень важно всегда быть на одной волне с заказчиком и разработать продукт, которым будут довольны обе стороны.
Переход бизнеса в цифру
Есть заказчики, которые хотят полностью или частично перевести в «цифру» уже работающий офлайн-бизнес.
Тут важно понимать, что каждый переход бизнеса в цифру имеет конкретную цель: привлечение новой аудитории, автоматизация существующих процессов, упрощение работы какой-либо услуги (бронирования, покупки и т.д.).
И, пожалуй, это один из самых сложных типов запроса, поскольку все те проблемы, которые существуют в бизнесе в офлайне, в цифре становятся ещё более критичными.
Представьте себе магазин, у которого плохо работает система логистики: например, нет чёткого понимания, что есть на складе, какие товары доступны и в каком количестве. Соответственно, эта проблема автоматически переносится на онлайн-версию магазина, что абсолютно точно не поможет ни росту продаж, ни повышению лояльности покупателей.
В такой истории критически важно начать с классического бизнес-анализа: выявить и описать существующие бизнес-процессы и спроектировать решение, которое при переносе в онлайн органично встроится в уже работающий бизнес и будет выполнять те цели, которые поставил перед собой заказчик.
Работа с готовым бизнесом и рефакторинг
Мы берём готовые продукты и улучшаем их.
Как правило, заказчик — это бизнес, который давно успешно существует на рынке и нуждается в модернизации устаревших технологий.
Для заказчика важно оставить работоспособными все бизнес-процессы и учесть привычки целевой аудитории, поэтому тут всё вновь начинается с этапа аналитики. Мы выясняем потребности и заказчика, и его аудитории, анализируем текущий технологический стек и находим наиболее подходящие решения.
Нам важно здраво оценить сложность и сроки проекта и требуемый уровень команды, поскольку ошибки на этом этапе могут быть весьма критичными. И во избежание ошибок мы уже на этапе предпроектной аналитики подключаем к исследованиям разработчиков и системных аналитиков.
Этапы создания цифровых продуктов
Все запросы клиентов, будь то цифровизация, создание продукта с нуля или рефакторинг, проходят одни и те же этапы.
Предпроектная аналитика
Это самый первый, а в некоторых случаях, которые мы описали ранее, едва ли не самый критически важный этап, который позволяет заказчикам и разработчикам избежать очень дорогостоящих ошибок.
Тут начинают работу сразу две команды Red Collar: бизнес-аналитики и маркетологи.
Состав исследований и задач меняется от проекта к проекту и подбирается под конкретный запрос, но есть своего рода «золотой стандарт» этапов: брифинг, изучение бизнес-процессов, описание целей и желаемого состояния продукта, исследования целевой аудитории и окружения, валидация гипотез и выбор лидирующей гипотезы. Иногда сюда добавляется просчет монетизации.
В рамках этих этапов мы собираем всю возможную информацию как со стороны заказчика, так и со стороны потенциальной аудитории. Это позволяет понять, есть ли вообще потребность в продукте, который хочет запустить заказчик.
Продукт должен нравиться не заказчику, а пользователям продукта. Есть многочисленные кейсы, когда целевая аудитория не заинтересована в том, что нравится заказчику.
Весь этот объём информации позволяет перейти к проектированию сервиса и определению состава MVP (минимально жизнеспособного продукта), где бизнес-аналитики описывают функциональные и нефункциональные требования, текущие («As Is») и целевые («To Be») состояния продукта, ролевую модель пользователей и карту сервиса.
И теперь, наперевес с чётким пониманием концепции, переходим к этапам, в которые постепенно включаются дизайнеры.
Совмещаем аналитику и визуал: вайрфреймы и прототипы
Вайры
Проектирование вайрфреймов начинается с определения необходимого минимума функциональностей системы, как и какие блоки будут взаимодействовать. Эту задачу выполняют бизнес-аналитики.
Вайр подходит для того, чтобы понять, как расположен контент. Это самый первый и самый низкодетализированный этап, своего рода статическая визуализация.
Прототипы
В этапе прототипирования участвуют и аналитики, и дизайнеры: аналитики объясняют функциональную часть и бизнес-логику. Дизайнеры же занимаются визуализацией прототипа. Как итог мы имеем базовую структуру будущего продукта. Заказчику мы показываем обесцвеченный вариант прототипа для более комфортной работы — такой прототип не будет отвлекать лишними элементами.
Проектируем архитектуру приложения
Теперь переходим к проектированию архитектуры продукта на базе вайрфреймов. Здесь подключаются архитекторы и разработчики — первые проектируют систему, вторые — непосредственно занимаются её созданием. Технологический стек выбираем на основе данных аналитики.
Создаём дизайн-концепцию
Здесь этапы зависят от того, с каким запросом пришёл заказчик: если пришёл бизнес, который ещё не сформировал свой бренд, то мы его создаём с нуля: опираемся на запрос заказчика и текущие тренды, отстраиваемся от конкурентов и находим что-то особенное. То есть, может добавиться этап, в котором работает команда брендинга. Но это отдельная история, которой мы обязательно поделимся позже, а пока вернёмся к дизайн-концепции.
Как правило, результат разработки дизайн-концепции — несколько ключевых экранов, по которым можно понять, как будет выглядеть готовый продукт.
Важно понимать, что дизайн – это не только «сделать красиво»: это совокупность опыта, понимания того, как и какие UX-решения будут эффективно работать. В первую очередь, это создание работоспособного и эстетичного решения, которое будет учитывать запросы и аудитории, и заказчика.
Обычно на этапе создания дизайн-концепции мы закладываем принципы. Например, что для нас важнее — чтобы продукт быстрее работал или для нас важнее красота? Иногда закладываем метафору на уровне типологии, к примеру, один из проектов мы окрестили “тиндер для щебня”.
В итоге мы определяем, какое настроение хотим передать через интерфейс в рамках существующего бренда, ищем референсы, подбираем элементы, которые будут отвечать задачам будущего продукта.
На основе всей собранной информации отрисовываем экраны, но отметим, что они ещё не финальные и на протяжении всей разработки будут уточняться.
Что будет в следующих сериях?
Итак, мы прошли достаточно долгий путь: поняли, что будем создавать и для какой аудитории, оценили, насколько аудитория заинтересована в продукте, продумали функционал, на основе вайрфеймов и прототипов продумали архитектуру, выбрали технологический стек и начали работать над дизайн-концепцией. Впереди нас ожидает ещё много этапов, и вот как раз о них расскажем в следующей публикации.
Причина проста: процессов много, и мы не хотим запутать читателей или переборщить с информацией. В следующей публикации расскажем о том, как переходим от «водопада» к Agile и через какие ещё этапы проходят сервисы, которые мы создаём.
Вместо итогов
Мир диджитал-продуктов, сервисов, видов бизнеса и клиентов, этапов разработки и прочего, прочего невероятно богат и многогранен. Настолько многогранен, что можно легко потеряться, но мы надеемся, что наш небольшой рассказ поможет сориентироваться.
Как вы могли заметить, создание цифрового продукта, как и запуск любого бизнеса, очень сильно зависит от многих факторов: от заказчиков, целей и задач; от рынка и направления бизнеса; от того, кто клиенты и кто конкуренты.
В работе с такими цифровыми продуктами важно понимать, что заказчик и разработчик по сути становятся партнёрами, и чем надёжнее это партнерство, тем успешнее создаваемый продукт.
Поэтому при работе с такими задачами мы стараемся глубоко погрузиться в бизнес клиента, становимся не только подрядчиком, но и консультантом, что позволяет понимать очень тонкие детали. Тем и ценны такие проекты: мы расширяем свою доменную экспертизу, заказчик получает сервис высокого уровня и работающий бизнес. Win-win.