Представьте, что вам нужно попасть из точки А в точку Б. Вы можете дойти пешком, прокатиться на велосипеде, сесть на поезд или вызвать такси. Скорость, сложность и материальные затраты будут напрямую зависеть от выбранного варианта передвижения.

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

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

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

Итак, поехали.

Знакомство лицом к лицу

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

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

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

Подготовка перед началом разработки

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

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

Структура работы

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

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

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

Техническое задание

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

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

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

Сроки и продолжительность

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

Проекты имеют конечные, заранее оговорённые сроки, и завершаются, когда достигают своих целей.

Оплата

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

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

Показатели эффективности

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

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

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

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

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