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

Уход западных игроков освободил ниши на рынке для российских предпринимателей. Чтобы успешно вступить в новую конкурентную среду, сегодня не обойтись без программных продуктов. Создание нового программного решения — процесс, всегда требующий основательного подхода. Так на помощь бизнесу пришел продуктовый подход. Его идея проста: создавать решения, которые будут максимально востребованы пользователями. У него «под капотом» — большая работа: исследование потребностей рынка, проверка гипотез, тестирование, анализ обратной связи и многое другое.

Об основных принципах его разработки: от постановки задач до релиза — рассказывает Александр Жуков, директор по развитию бизнеса компании «Формат Кода».

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

Что понимают под этим понятием? Это процессная работа, направленная на конечного потребителя продукта заказчика и выгоду, которую может извлечь бизнес. Это глубокое аналитическое погружение, поэтому экспертная команда подключается к проекту еще на этапе формулировки идеи. Одни клиенты приходят с уже проработанной идеей, другие — с идеей на ранней стадии. 

Как создаются такие цифровые решения?

При разработке проводится последовательная работа, заранее спланированная и проверенная. Команда описывает концепт, обозначает бизнес-цели в более формальном виде, создает техническое задание, рисует макеты, на базе которых будет эффективнее и проще выстраивать дальнейшую работу, объясняет те KPI и средства аналитики, которые будет использовать для измерения успеха проекта. После этого происходит переход к стадии разработки программного обеспечения. Базовый принцип — индивидуальных подход к каждому проекту. Это гарантирует, что готовый программный продукт будет учитывать все детали конкретного бизнеса.

Кто составляет ядро экспертной команды?

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

Сбор и анализ требований — это, пожалуй, самый ответственный и важный из всех этапов. Вся собранная информация используется для планирования. Поэтому необходимо работать с аналитическими инструментами, такими, как Amplitude Analytics, Яндекс.Метрика, Google Analytics и другими. Решения принимаются на основе данных: каждая идея и гипотеза должна подтверждаться фактами и цифрами.

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

Как выстраивается работа?

Достаточно короткими циклами. Первый этап проекта формулируется как базовая версия продукта «MVP за три недели». MVP (Minimum Viable Product) — это самая ранняя версия, у которой есть минимальный набор функций, уже достаточный для презентации и тестирования на первых потребителях.

Это базовый продукт, полноценный с точки зрения дизайна, интерфейса, функциональности. В этом виде он запускается на рынок, и им начинают пользоваться. Разработчики закладывают время на проверку решения, получают обратную связь, вносят изменения вместе с клиентом и только потом масштабируют.

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

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

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

К моменту окончательного релиза это уже «живой», многократно проверенный, работающий продукт, имеющий своих пользователей.

Скажите, а возможен ли консалтинг на площадке клиента? Существует ли возможность масштабировать коллектив заказчика для разработки?

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