Бывает, что люди, близкие к теме разработки софта спрашивают: чем проектная работа отличается от создания MVP (Minimal Viable Product)? Понятно, что при этом у каждого спрашивающего свой контекст вопроса – соответственно, отвечать на него надо по-разному. Однако, если обобщить, то проект и разработка продукта сильно отличаются друг от друга. Вообще всем. Это не так-то легко объять, поэтому давайте попробуем разобраться в проблематике.

 

Проблематизация: проект или разработка продукта

Если смотреть поверхностно, то разработка софта – она и есть разработка софта, будь то проект или разработка продукта. Есть некие функциональные требования – не всегда формализованные. Есть нефункциональные требования – про которые частенько забывают вовсе. Есть разработчики, есть некий условный менеджер, и есть какая-то методология. Разработчики пилят код, менеджер разгребает препятствия у них на пути, решает вопросы с конечным клиентом / пользователем / заказчиком. В конце показывают какой-то результат. Иногда, как любят шутить в индустрии, результат даже соответствует требованиям.  Кстати, вопрос рассогласования требований конечного результата поднимал мой коллега в статье “Формулируем MVP в заказной разработке”

 

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

 

Это так называемые “проектный” и “продуктовый” подходы к разработке. У каждого подхода есть свои особенности, которые мы рассмотрим чуть дальше. Так вот, если копнуть ещё глубже в продуктовый подход, то внутри можно выделить ещё и разработку MVP. Создание MVP, будучи частью продуктовой разработки, в то же время имеет свои особенности и резко отличается от разработки уже полноценного продукта с целью его улучшения и расширения. Помимо MVP также можно выделить MMF (Minimum Marketable Feature). MMF не является объектом рассмотрения данной статьи, просто нужно отметить, что это разные вещи. Их, к сожалению, частенько путают, говоря, что всё это MVP.   И вот теперь, имея представление о существовании всех этих отличий – можно копнуть глубже в детали и рассмотреть, чем же именно отличаются подходы.

 

Проект vs продукт

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

1. Основной задачей проектного управления обычно является попадание в тройственное ограничение: Сроки, Стоимость, Функциональность. Из этого требования логически проистекает необходимость договариваться обо всём “на берегу”, фиксировать эти договорённости, и проводить зачастую очень утомительные циклы согласований для любых изменений. 
2. Этот подход требует специфического состава команды, процессов, коммуникаций.

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

1. Основной задачей продуктового подхода обычно является создание успешного на рынке продукта. При этом ни сроки, ни бюджет, ни функциональность могут быть не зафиксированы вовсе. Главное – сохранение гибкости, ситуативности, и возможности максимально быстро откликаться на сигналы, поступающие от рынка.
2. Этот подход требует специфического состава команды, процессов, коммуникаций.

Как говорится – сюрприз-сюрприз. Цели, поставленные перед системой, определяют всё наполнение системы: материал, из которого она создана, её структуру, процессы, внутренние и внешние связи.

Тройственное ограничение

Когда вы говорите с любым бизнесом, его интересует планируемость. Какой бюджет надо выделить, в течение какого срока будет предоставлен результат, что именно будет входить в результат. Причём это не запрос на предсказание будущего – а именно планируемость. Допускаются небольшие погрешности в сроках – обычно до 20% и стоимости – обычно до 10%, в функциональности – тут погрешность очень сильно зависит от источника требований. Если требования исходят, скажем, из гипотезы отдела маркетинга – то гибкости больше. А если это требования нового закона – с гибкостью беда.

 

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

Специфика проектной системы

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

 

Соответственно, над проектом в разное время работает разный набор специалистов. На первых стадиях нагрузка больше на аналитиков, архитекторов, технических писателей. На этапе дизайна – на дизайнеров, верстальщиков. На этапе реализации – на разработчиков. На этапе отладки – на тестировщиков. На этапе внедрения (если он есть) – на внедренцев, если такая роль присутствует в команде.

 

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

 

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

Гибко откликаться на сигналы рынка

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

 

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

При этом сами итерации не могут быть длинными: результат нужен как можно раньше. Чем быстрее “вброшенная” идея будет реализована и выпущена на рынок – тем раньше будет понятно, стоит ли развивать её дальше, или нужно брать другую. Поэтому сами итерации обычно варьируются от одной недели до одного месяца, и чаще всего команды выбирают “золотую середину” в две недели.

 

При этом по завершении КАЖДОЙ итерации команда выдаёт рабочий результат. Нечто, что можно пощупать, дать пощупать клиентам, выложить в сеть, разрекламировать, увидеть плюсы и минусы, скорректировать дальнейшее развитие. Ну, по крайней мере, гибкие подходы декларируют, что результат будет готов после каждой итерации. Реальность, бывает, вносит свои коррективы.

 

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

 

Бюджеты при этом завязаны на стоимость команды разработки в единицу времени и срок реализации. Чем дольше команда работает – тем больше бюджета она “съедает”.

 

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

Специфика продуктовой системы

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

 

Во-первых, цикл “сбор требований – формализация – разработка – тестирование – внедрение” сжимается до пределов одной-двух итераций. Зачастую, пока команда реализует предыдущие требования, владелец продукта (или менеджер продукта, зависит от фреймворка и ситуации) выясняет, приоритезирует и уточняет требования для следующей итерации. Чтобы ранее формализованные требования не потерялись – всё складывается в так называемый бэклог, строго отсортированный по приоритетам. По завершению итерации команда просто берёт наиболее приоритетные элементы бэклога – сколько поместится – и приступает к их реализации. Если при этом окажется, что свежие требования менее приоритетны, чем уже существующие в бэклоге – то будут реализованы более старые, но более важные. По сути, “свежесть” требований здесь не играет никакой роли: важен лишь приоритет. При этом требования вполне могут устареть, что снизит их ценность для бизнеса и, в свою очередь, снизит приоритет для реализации.

 

Не будем подробно останавливаться на том, как выстраиваются эти приоритеты – это отдельная большая тема. Отметим лишь, что очень большую роль играет именно ценность для бизнеса.

 

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

 

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

 

При этом внедрение может вестись – и зачастую ведётся – параллельно с разработкой. Этим может заниматься либо эта же команда разработки, либо команда внедрения и поддержки, работающая в своём ритме.

 

Результирующая таблица сравнения

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

 

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