Разработка продукта: в какой парадигме работать?

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

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

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

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

Проект VS Продукт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Back to MVP

Впрочем, немного вернёмся.

Для начала давайте в двух словах определимся — что же такое этот самый MVP.

Minimal Viable Product — это тот самый минимум, который можно дать рынку «на пощупать», собрать обратную связь и определиться: развивать ли его дальше, или положить на полку до лучших времён. Соответственно, прежде, чем разрабатывать MVP, нам необходимо определиться — что же будет тем самым минимумом, которого будет достаточно для прощупывания рынка.

И вот здесь-то и появляется почва для непонимания и путаницы.

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

Давайте посмотрим, как это обычно происходит в парадигме проектного подхода, и сравним с продуктовым подходом.

Проектная парадигма

Маркетолог, на основании исследования рынка США, обнаружил потребность российского рынка в определённом продукте. В США такой продукт уже есть, там есть фичи А, Б, В, Г и Д, спрос растёт, появляются конкуренты. Эти фичи решают определённые проблемы пользователей — и исследование российского рынка показывает, что те же проблемы есть у российских пользователей, и решаются они так же плохо и неудобно, как это было в США до выхода нового продукта.

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

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

И всё же. И всё же. Уважаемые менеджеры проектов, положа руку на сердце, разве редко бывает такое, что заказчик, получив готовый продукт, искренне ему удивляется? Да, он где-то сам недодумал. Да, он где-то сам недопонял, подписывая мокапы, дизайн и ТЗ. Это нормально для человека — не до конца понимать, как будет выглядеть и работать конечный результат.

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

В любом случае — продукт готов, подпилен напильником, отполирован и запущен.

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

Но представим, что та же проектная команда остаётся развивать продукт. Что же получится?

Маркетолог проводит очередное исследование рынка и предлагает включить в продукт фичу Е. Команда уточняет требования, составляет ТЗ, устанавливает тройственное ограничение — и выкатывает новую фичу через месяц. Работают аналитики, работают технические писатели, работает менеджер проекта, составляя диаграммы Гантта или критического пути, работают разработчики, тестировщики, внедренцы. Если потом оказывается, что фича неэффективна или даже вредна — можно завести проект по её удалению.

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

Где? Давайте попробуем найти в сравнении.

Продуктовая парадигма

В продуктовом подходе всё происходит совсем иначе. Повторюсь, не так важно, Scrum ли это или другой фреймворк.

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

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

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

Ещё один немаловажный момент — разработка продукта заканчивается только со смертью продукта. В этом ключевое отличие от проектного подхода, который всегда конечен. Покуда продукт живёт, им активно пользуются — будут возникать запросы на изменение функциональности и добавление новых фичей. И здесь на подиум выходит Minimal Marketable Feature (минимально полезная функциональность).

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

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

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

Еще одна особенность MVP подхода — умение делать буквально из говна и палок (shit and bricks). Это звучит страшно для любого менеджера проекта или архитектора — и прекрасно для предпринимателя. Если неизвестно, «выстрелит» ли новая идея — незачем вкладывать в неё сотни тысяч долларов и надеяться на лучшее. Лучше сделать за несколько тысяч что-то, чем можно пользоваться, и привлекать инвестиции на уже существующую пользовательскую базу.

Можно поспорить, что разработка MVP — лишь небольшой эпизод жизненного цикла продукта. Что MVP можно разрабатывать в рамках проектного подхода, и потом обогащать его MMF в рамках всё того же проектного подхода. Да, так вполне можно работать. Это существенно увеличит цикл обратной связи и не даст ситуативно пользоваться решениями «на коленке». Это изолирует команду разработки от бизнес-ценности создаваемого продукта. Но так вполне можно работать — и так довольно часто работают. Дальше я постараюсь показать, почему так происходит, и почему это не совсем верно.

Почувствуйте разницу

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

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

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

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

Подытоживая — хочу отметить, что продуктовый подход НЕ ЛУЧШЕ проектного. Каждый лучше в рамках своей применимости.

Штука в том, что очень часто — вот прямо ОЧЕНЬ ЧАСТО — разработку MVP ведут в проектной парадигме. И получают при этом результаты. Хороший менеджер и хорошая команда — залог попадания в тройственное ограничение.

Но при этом никто даже не пытается задумывать о том, какой результат был бы получен, подойди команда к решению вопроса в продуктовой парадигме. Более того — часто ни команда, ни менеджер просто-напросто не готовы в этой парадигме работать, не понимают её. И, как следствие, просто не умеют работать по-другому.

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

Получить консультацию