Проектный VS продуктовый подход: что эффективнее

Отличие проекта от продукта не всегда очевидно, иногда компании не могут чётко сформулировать, какого подхода они придерживаются. Понять, в чём же разница, нам поможет Станислав Беляев, инженерный менеджер из Microsoft и наставник на курсе «Менеджер проектов».

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

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

В рамках проектной деятельности производились:

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

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

→ Проект — это ограниченное во времени мероприятие с установленными ресурсами и бюджетом. То есть проект будет сделан в срок с А по Б. При этом мы получим осязаемый результат или достигнем конкретной цели (показателей). Для её постановки отлично подойдёт фреймворк SMART.

Примеры проектов:

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

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

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

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

→ Продукт — это то, что востребовано клиентами. Если он не востребован — это провал, и неважно, делает его проектная или продуктовая команда. У него нет чёткого конечного результата, он постоянно улучшается и развивается.

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

В процессе создания и выхода на рынок продукт может переродиться и уйти от изначального видения. Ошибки при создании неизбежны, ведь всё построено на базе гипотез и их проверок. Примеры и история такого перерождения продукта: ProductHub и Cherry Labs (ролик на YouTube с таймкодом).

Главная цель продукта — удовлетворение потребностей клиента. Изменение потребностей (требований) — постоянный его атрибут.

Примеры продуктов:

Или просто посмотрите на экран мобильного телефона. Каждая иконка — это отдельный продукт: )

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

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

Можно предположить, что реализация каждой функции — это проект. Наверняка вы скажете:

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

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

Всё это подводит к выводу, что разработка фичей не является проектом.

В компании, где я работал, считали иначе. Мне казалось, что именование продукта «проектом» уже определяло отношение к нему. Это было заметно в том, как формировались проектные команды.

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

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

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

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

→ Продуктовая команда — команда, способная автономно и самостоятельно развивать продукт или часть его функциональности во всех направлениях.

Характеристики такой команды:

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

Особенности процессов:

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

→ Разработка новой функциональности

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

Продуктовая команда. Функциональность отдаётся в любую свободную команду или близкую по задачам (например, открытие депозита и открытие валютного счёта отдаются в команду открытия счетов).

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

Нет лишних трат времени на организацию проектного пространства и разделения ответственности между участниками, не требуется тратить время на формирование команды (по Брюсу Такману) — всё происходит в рамках одного коллектива и существующих процессов.

→ Развитие существующей функциональности

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

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

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

→ Ускорение работы над фичей

Проектная команда. Решение принимается на самом верху и спускается вниз на исполнение. Как это происходило в случае с нашей финтех-компанией:

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

→ Идея или функциональность не взлетела

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

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

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

→ Отсутствие новых задач

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

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

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

Если сравнить проектные команды и продуктовые, каждая из них имеет свои положительные и отрицательные стороны. Это заложено в изначальных принципах, процессах и целях существования команд.

→ Проектная команда

Преимущества:

Недостатки:

→ Продуктовая команда

Преимущества:

Недостатки подхода:

Может возникнуть ощущение, что продуктовый подход более удачный и стоит выбирать именно его. Я бы не спешил с выводами. Вернёмся к нашему кейсу: почему же компания упорно хотела применять и применяла проектный подход к работе над продуктом? Для неё была важна прозрачность процессов. Не продукт как таковой, а именно прозрачность:

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

Нет правильного подхода для создания и развития продукта. Правильный подход тот, который позволяет компании существовать и развиваться.