Бывает, что люди, близкие к теме разработки ПО, спрашивают: чем работа над проектом отличается от создания MVP (Minimal Viable Product)? Понятно, что у каждого задающего свой контекст вопроса – соответственно, и отвечать на него надо по-разному.
Однако, подводя итог, можно сказать, что дизайн и разработка продукта сильно отличаются друг от друга.
На самом деле все.
Это не так-то просто понять, поэтому попробуем разобраться в проблеме.
Проблематизация: разработка проекта или продукта
Если посмотреть поверхностно, то разработка программного обеспечения — это разработка программного обеспечения, будь то разработка проекта или продукта.Есть некоторые функциональные требования – не всегда формализованные.
Есть нефункциональные требования, о которых часто совершенно забывают. Есть разработчики, есть какой-то условный менеджер, есть какая-то методология.
Разработчики сокращают код, менеджер расчищает препятствия на пути, решает вопросы с конечным клиентом/пользователем/заказчиком.
В конце концов они показывают какой-то результат. Иногда, как любит шутить в индустрии, результат даже соответствует требованиям.
Если посмотреть немного глубже, то окажется, что есть как минимум два огромных направления развития, радикально отличающихся друг от друга буквально во всем: от постановки целей и формулирования требований до процессов исполнения и выдачи результатов.
Это так называемые «проектный» и «продуктовый» подходы к разработке.
Каждый подход имеет свои особенности, которые мы рассмотрим чуть дальше.
Итак, если вы углубитесь в подход к продукту, вы также сможете выделить разработку MVP внутри.
Создание MVP, являясь частью разработки продукта, в то же время имеет свои особенности и сильно отличается от разработки уже полноценного продукта с целью его улучшения и расширения.
Помимо MVP, можно также выделить MMF (Minimum Marketable Feature).
ММФ не является предметом этой статьи, просто нужно отметить, что это разные вещи.
К сожалению, их часто путают, говоря, что всё это MVP. И теперь, имея представление о существовании всех этих различий, мы можем углубиться в детали и рассмотреть, чем именно отличаются подходы.
Проект против продукта
Во-первых, давайте воспользуемся проектным подходом.Есть разные методологии разработки проектов, разные структуры управления проектами, но в целом я бы выделил две основные вещи.
Основная задача управления проектом обычно состоит в том, чтобы достичь тройного ограничения: время, стоимость, функциональность.
Из этого требования логически вытекает необходимость согласовывать все «на суше», фиксировать эти договоренности и проводить зачастую очень утомительные циклы согласования любых изменений.
Этот подход требует определенного состава команды, процессов и коммуникаций.
Если брать продуктовый подход, то, абстрагируясь от конкретных рамок, можно сказать следующее.
Основной целью продуктового подхода обычно является создание успешного продукта на рынке.
В этом случае вообще не могут быть зафиксированы ни сроки, ни бюджет, ни функционал.
Главное – сохранять гибкость, ситуативность и способность максимально быстро реагировать на сигналы, поступающие с рынка.
Этот подход требует определенного состава команды, процессов и коммуникаций.
Как говорится – сюрприз, сюрприз.
Цели, поставленные перед системой, определяют все содержание системы: материал, из которого она создана, ее структуру, процессы, внутренние и внешние связи.
Тройное ограничение
Когда вы разговариваете с представителями любого бизнеса, их интересует возможность планирования.Какой бюджет следует выделить, в какой период будет обеспечен результат, что именно войдет в результат. Причем это не запрос на предсказание будущего, а именно на планируемость.
Допускаются небольшие погрешности в сроках - обычно до 20% и стоимости - обычно до 10%, в функциональности - здесь погрешность очень сильно зависит от источника требований.
Если требования исходят, скажем, из гипотезы отдела маркетинга, то гибкости больше.
И если таковы требования нового закона, то гибкость является проблемой.
Однако мы не будем останавливаться на плюсах и минусах каждого подхода.
Отметим только, что проектный подход идеален в ситуации, когда все плюс-минус ясно заранее: есть фиксированный бюджет, есть сроки, есть понимание желаемого функционала.
Часто неполный.
Но это задача аналитиков и менеджеров: вместе с заказчиком проекта определить, что обязательно должно быть включено в результат, чем желательно, а чем можно пренебречь.
Специфика дизайн-системы
При проектном подходе работа обычно разбивается на понятные этапы.Например, формализация требований и подготовка проектной документации, проектирование, внедрение, тестирование и отладка, внедрение.
Детали могут различаться, но общий подход V-модели в целом остается прежним, даже если он осуществляется неосознанно.
Соответственно, над проектом в разное время работают разные группы специалистов.
На первых этапах нагрузка больше на аналитиков, архитекторов и технических писателей.
На этапе проектирования – для дизайнеров, верстальщиков.
На этапе реализации — для разработчиков.
На этапе отладки — для тестировщиков.
На этапе внедрения (если он есть) — реализаторам, если такая роль присутствует в команде.
Именно поэтому необходимо все документировать.
Чтобы, условно, программист не побежал с каким-либо вопросом к аналитику, который к тому времени уже работает над описанием совсем другого проекта.
Чтобы тестировщик четко понимал, что и как тестировать, каковы критерии принятия результата заказчиком, какие проблемы критичны, а какие в целом приемлемы.
И все это координирует менеджер.
Он часто выступает своеобразной прослойкой между представителями заказчика и командой.
Фактически здесь есть два основных канала коммуникации: менеджер и документация.
Конечно, никто не запрещает людям общаться напрямую, когда это уместно, но на самом деле прямое общение не всегда уместно.
Гибко реагировать на сигналы рынка
Над какой бы структурой ни работала продуктовая команда, в конечном итоге она работает для рынка.Сигналы с рынка могут поступать непосредственно по результатам измерений ключевых показателей.
Сигналы могут поступать косвенно: от маркетологов и аналитиков.
Сигналы могут прийти окольным путем, от руководителя продакт-менеджера или стейкхолдеров, от их представлений о том, что будет востребовано завтра.
Как бы то ни было, команда разработчиков стремится создать адекватный ответ на вызовы рынка.
Эти сигналы могут быть противоречивыми: сам рынок очень динамичен и постоянно меняется, а субъективные представления о том, что будет с рынком завтра, радикально меняются практически каждый день.
Поэтому при продуктовом подходе невозможно что-либо зафиксировать «на берегу».
Более того, часто необходимо не допускать, чтобы заинтересованные стороны бросали слишком много конфликтующих задач, разбивали работу на фиксированные итерации и не брались за новые задачи до того, как будут выполнены уже назначенные.
При этом сами итерации не могут быть длинными: результат нужен как можно раньше.
Чем быстрее «подкинутая» идея будет реализована и выпущена на рынок, тем скорее станет понятно, стоит ли развивать ее дальше или нужно брать другую.
Поэтому сами итерации обычно составляют от одной недели до одного месяца, и чаще всего команды выбирают «золотую середину» в две недели.
Причём по завершению КАЖДОЙ итерации команда выдаёт рабочий результат. То, что можно пощупать, дать потрогать клиентам, выложить в интернет, прорекламировать, увидеть плюсы и минусы и скорректировать дальнейшее развитие.
Ну, по крайней мере, гибкие подходы заявляют, что результат будет готов после каждой итерации.
Реальность иногда вносит свои коррективы.
Что касается сроков, стоимости и функциональности, то зачастую фиксированы только сроки.
Сроки выпуска новой версии продукта, новой функции или MVP нового продукта.
Дело в том, что сроки могут быть привязаны к требованиям внешнего мира – рекламным кампаниям, сезонным колебаниям, выставкам и т. д. Бюджеты привязаны к затратам на команду разработчиков в единицу времени и сроку внедрения.
Чем дольше работает команда, тем больше бюджета она съедает. Функциональность часто фиксированная или очень слабая — например, новый продукт может иметь ключевую функцию-убийцу.
Либо оно вообще не фиксируется и корректируется по мере работы над продуктом.
Особенности продуктовой системы
Понятно, что для обеспечения такой работы должна быть определенным образом организована продуктовая команда, как и ее рабочие процессы.Во-первых, цикл «сбор требований – формализация – разработка – тестирование – внедрение» сжимается до пределов одной-двух итераций.
Часто, пока команда реализует предыдущие требования, владелец продукта (или менеджер продукта, в зависимости от структуры и ситуации) уточняет, расставляет приоритеты и уточняет требования для следующей итерации.
Чтобы ранее формализованные требования не потерялись, все помещается в так называемый бэклог, строго отсортированный по приоритету.
По завершении итерации команда просто берет элементы бэклога с наивысшим приоритетом — столько, сколько поместится — и начинает их реализовывать.
Если окажется, что свежие требования имеют более низкий приоритет, чем уже существующие в бэклоге, то будут реализованы более старые, но более важные.
На самом деле «свежесть» требований здесь не играет никакой роли: имеет значение только приоритет. В то же время требования вполне могут устареть, что снизит их ценность для бизнеса и, в свою очередь, снизит их приоритетность к реализации.
Мы не будем подробно останавливаться на том, как выстраиваются эти приоритеты – это отдельная большая тема.
Отметим только, что стоимость бизнеса играет очень важную роль.
Во-вторых, команда, по сути, не может и не должна приступать к выполнению задач поэтапно.
Взяли в работу один элемент — реализовали, взяли следующий — реализовали.
Мы подошли к концу итерации и выкатили инкремент, то есть рабочий результат. Давайте спланируем следующую итерацию.
Роли внутри команды неизбежно сглаживаются и перестают быть так четко определены, как при проектном подходе.
Разработчик может написать серверный код, интерфейсный код, макет и протестировать за один день.
Разбивать и без того небольшие задачи на отдельные блоки и раздавать их людям с разными компетенциями становится слишком дорого.
Поэтому резко возрастают требования не к специализации, а к кросс-функциональности членов команды, растет ценность фуллстек-разработчиков.
В то же время внедрение может осуществляться – и часто осуществляется – параллельно с разработкой.
Это может сделать либо одна и та же команда разработчиков, либо группа внедрения и поддержки, работающая в своем собственном темпе.
Вернуться к MVP
Однако вернемся к нашим овцам.Для начала давайте кратко определим, что это за MVP. Minimal Viable Product — это тот самый минимум, который вы можете дать рынку, чтобы он «пощупал», собрал отзывы и принял решение, развивать его дальше или отложить на полку до лучших времен.
Соответственно, прежде чем разрабатывать MVP, нам нужно решить, каким будет тот минимум, которого будет достаточно для тестирования рынка.
И вот здесь возникает почва для непонимания и путаницы.
С точки зрения любого менеджера проекта, разработка MVP — это проект. Заказчик уже определился с требованиями, мы можем просчитать бюджет и сроки – и все, наш тройной ограничитель готов, можно запускать по нашей схеме реализации проекта! Да и нет. Давайте посмотрим, как это обычно происходит в парадигме проектного подхода, и сравним это с продуктовым подходом.
Парадигма проекта
Маркетолог на основе исследования рынка США обнаружил потребность российского рынка в определенном товаре.В США такой продукт уже есть, есть характеристики А, Б, С, D и Е, спрос растёт, появляются конкуренты.
Эти возможности решают определенные проблемы пользователей — и исследование российского рынка показывает, что у российских пользователей проблемы такие же, и решаются они так же плохо и неудобно, как это было в США до выхода новинки.
Маркетолог, подумав, кратко записывает требования к новому продукту и идет к разработчикам.
Они, привлекая аналитиков, уточняют функциональные и нефункциональные требования, составляют техническое задание на разработку, определяют тройное ограничение — и проект начинается.
Примерно через месяц проект утверждается, в техническое задание вносятся некоторые изменения – и вот команда готова приступить к реализации.
Через два-три месяца продукт готов, проходит тестирование, внедряется в производство, только пришла рекламная кампания — ура, запускаем! Что будет, если что-то не учесть при составлении и проверке макетов и дизайнов? Кто-то из руководителей проекта сейчас вскочит и обиженно заявит, что все учесть невозможно.
Что пользователи часто ведут себя странно, да и вообще наш UX-архитектор настолько замечательный, что отсекает большинство проблем на этапе обдумывания.
Но все равно.
Но все равно.
Уважаемые руководители проектов, честно говоря, редкость, когда заказчик, получив готовый продукт, искренне ему удивляется? Да, он где-то об этом не подумал.
Да, он сам что-то недопонял, когда подписывал макеты, дизайн и техническое задание.
Это нормально, когда человек не до конца понимает, как будет выглядеть и работать конечный результат. В любом случае, это уже произошло.
И это нужно как-то исправлять.
Либо в рамках предыдущих договоров, для которых часто закладывается буфер при оценке сроков и стоимости, - либо по дополнительным соглашениям.
соглашение.
В любом случае продукт готов, подпилен, отшлифован и запущен.
Далее идет сбор отзывов пользователей, разработка новых функций, изменение или удаление старых.
В целом нормальная разработка продукта.
При этом, с точки зрения команды проекта, их полномочия начинаются на этапе сбора требований к MVP и заканчиваются после его реализации.
Разработка продукта в проектной парадигме чрезвычайно сложна.
Но давайте представим, что для разработки продукта остается та же команда проекта.
Что случится? Маркетолог проводит еще одно исследование рынка и предлагает включить в продукт функцию Е.
Команда уточняет требования, составляет техническое задание, устанавливает тройное ограничение — и за месяц выкатывает новую фичу.
Работают аналитики, работают технические писатели, работает менеджер проекта, составляющий диаграммы Ганта или критического пути, работают разработчики, тестировщики и внедрятели.
Если позже выяснится, что эта функция неэффективна или даже вредна, вы можете начать проект по ее удалению.
В общем, эти накладные расходы никому не очевидны — ни маркетологу, ни менеджеру проекта, ни членам команды.
Все при деле, все работают эффективно.
Со временем даже документацию можно сократить до минимума.
Но есть еще накладные расходы.
Где? Попробуем найти это в сравнении.
Парадигма продукта
В продуктовом подходе все происходит совершенно иначе.Опять же, не так уж важно, Scrum это или другой фреймворк.
Когда тот же маркетолог подходит к продукту и показывает свое описание того, что он считает MVP. Хороший продукт всегда будет задавать вопрос: какова сравнительная ценность этих функций для бизнеса? Поняв вместе с маркетологом их бизнес-ценность, он даст очень приблизительную оценку трудоёмкости каждой фичи, включая, при необходимости, компетенции команды.
Далее, используя подход Easy First, команда быстро выпустит первую версию продукта с одной или двумя функциями.
Это может произойти буквально за одну-две итерации.
Более того, если окажется, что часть возможностей можно реализовать с помощью стороннего сервиса или коробочного решения, именно так и будет сделано.
При полном осознании того, что для промышленного решения такой вариант реализации фичи придется выбросить на свалку истории.
В любом случае маркетолог – а через него и рынок – получит первую версию продукта гораздо раньше.
Начнёт расти база пользователей – сначала внутренняя, а затем и внешняя.
Обратная связь начнет поступать.
Оказывается, ценность функций для бизнеса в действительности несколько иная, чем считалось ранее.
В результате некоторые функции могут вообще не попасть в конечный продукт, но появятся другие, или можно будет сосредоточиться на главных, killer-фичах.
Еще один важный момент заключается в том, что разработка продукта заканчивается только со смертью продукта.
В этом ключевое отличие от проектного подхода, который всегда конечен.
Пока продукт живет, он активно используется — будут возникать запросы на изменение функционала и добавление новых возможностей.
Именно здесь на сцену выходит минимальная рыночная функция.
Методологически это очень похоже на MVP: для создания новой функции не создается новый проект со своими этапами V-цикла, подробной документацией и соблюдением тройного ограничения.
Вместо этого продукт определяет, какова минимальная полезная функциональность, которая может быть представлена на рынке для получения обратной связи от пользователей.
И этот минимальный функционал команда берет в работу, зачастую без длительной проработки деталей.
Если при проектном подходе пишут сценарии использования и планы тестирования, то при продуктовом подходе собирают отзывы пользователей и исправляют ошибки.
А если окажется, что отзыв отрицательный или отсутствует, вы можете прекратить поддержку функции или вообще отказаться от нее.
Причем сделать это следует достаточно рано, не вкладываясь в полный цикл разработки всего его функционала.
Или инвестируйте в другую функцию, имеющую больший рыночный потенциал, подтвержденный отзывами пользователей.
Другими словами, суть продуктового подхода к созданию MVP заключается в том, чтобы разбить процесс его реализации на очень короткие циклы создания ценности и получения обратной связи, что дает гораздо более гибкую управляемость и позволяет принимать решения по развитию продукта.
продукта в ходе его разработки.
Еще одна особенность подхода MVP — способность буквально делать дерьмо и кирпичи.
Это звучит пугающе для любого менеджера проекта или архитектора и прекрасно для предпринимателя.
Если вы не знаете, сработает ли новая идея, не нужно вкладывать в нее сотни тысяч долларов и надеяться на лучшее.
Лучше сделать что-то за несколько тысяч, что можно будет использовать и привлечь инвестиции в существующую базу пользователей.
Можно утверждать, что разработка MVP — это лишь небольшой этап жизненного цикла продукта.
Этот MVP можно разработать в рамках проектного подхода, а затем обогатить его MMF в рамках того же проектного подхода.
Да, вполне возможно так работать.
Это существенно увеличит цикл обратной связи и предотвратит ситуативное использование решений «на коленке».
Это изолирует команду разработчиков от коммерческой ценности создаваемого продукта.
Но так работать вполне возможно — и так работают довольно часто.
Далее я попытаюсь показать, почему это происходит и почему это не совсем так.
Возможно, самым важным, а также самым трудным и, следовательно, недооцененным преимуществом продуктового подхода является способность быстро реагировать на сигналы рынка и обеспечивать именно то, что требует рынок.
Проектный подход основан на негласной уверенности в том, что мы точно знаем, что нужно рынку, — и делаем именно это.
Сравнивая это с военным делом, можно планировать операцию по карте, а можно проводить разведку на местности.
Как говорится, на бумаге было гладко, но про овраги забыли.
Однако ключевой проблемой в получении этого преимущества является возможность удаления обратной связи.
Команда должна понимать, на каких бизнес-показателях ориентирован MVP или MMF. Какую информацию — системную, пользовательскую и другую — необходимо собирать, отслеживать, контролировать.
К сожалению, часто можно наблюдать картину, когда команда занимается только разработкой по техническому заданию.
Другие люди обслуживают продукт, собирают кучу информации, третьи эту информацию анализируют, третьи думают, что с ней делать.
Максимум, что команда делает в этом смысле — предоставляет возможность собирать метрики, подключая логи и другие инструменты, и создает дашборды для администраторов и аналитиков.
В результате функциональность системы создается людьми, не понимающими бизнес-смысл того, что они создают. Опять же, часто бывают ситуации, когда информация вообще не собирается.
Мало того, что анализировать некому, даже не смотрят. Весь смысл быстрой обратной связи просто теряется.
В данном случае особой пользы от продуктового подхода действительно нет. Вполне можно включить проектный подход, вложить деньги и посмотреть, что из этого выйдет, с циклом в квартал или даже год. Подводя итог, хотелось бы отметить, что продуктовый подход НЕ ЛУЧШЕ проектного подхода.
Каждый из них лучше в пределах своей применимости.
Все дело в том, что очень часто — даже ОЧЕНЬ ЧАСТО — разработка MVP осуществляется в проектной парадигме.
И они получают результаты.
Хороший менеджер и хорошая команда — ключ к преодолению тройного ограничения.
Но при этом никто даже не пытается задуматься о том, какой результат был бы получен, если бы команда подошла к вопросу в продуктовой парадигме.
Более того, зачастую ни команда, ни руководитель просто не готовы работать в этой парадигме и не понимают ее.
И, как следствие, они просто не умеют работать по-другому.
Но почему так происходит, и что нужно понимать, быть готовым и уметь применять продуктовый подход к разработке — это отдельный большой разговор.
Напишите в комментариях, интересна ли эта тема и вопросы, на которые вы хотели бы получить ответы.
Теги: #Разработка стартапов #Разработка мобильных приложений #Управление разработкой #mvp #продуктовый подход #проектный подход #mvp vs project #IT-разработка
-
Ноутбук Toshiba Satellite A505 Серии S6025
19 Oct, 24 -
Нокиа Н9. Nokia Снова Слила Информацию?
19 Oct, 24 -
Структурирование Аспектов 2
19 Oct, 24 -
Blackberry Похвасталась Новым Blackberry 10
19 Oct, 24 -
Ak4452 Представляет Бюджетный Hi-Fi Цап
19 Oct, 24 -
Внимание-Реклама От Samsung
19 Oct, 24
