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

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

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

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

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

• запуск новых услуг на рынок;
• модернизация процессов;
• трансформация компании;
• наём людей (массовый набор специалистов);
• маркетинговые кампании.

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

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

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

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

• Построить дорогу в 100 км от пункта В до Г в 2024 году.
• Внедрить новое ПО, отвечающее характеристикам, согласно ТЗ.
• Достичь 100 000 просмотров этой статьи в течение 3 месяцев после публикации.

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

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

• документы (паспорт проекта, чек-лист тестировщика);
• системы управления (P3.express);
• фреймворки (SCRUM);
• статусные встречи и отчёты (Monthly/Quarterly Business Review);
• и другие инструменты.

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

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

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

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

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

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

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

• мобильная игра Crash of Clans;
• интернет-банк Точка;
• iPhone и Android;
• VK.

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

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

• открытие расчётного счёта без посещения офиса;
• выпуск виртуальной карты из мобильного приложения;
• чат поддержки 24/7;
• бесконтактную оплату картой.

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

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

• при разработке каждой функциональности есть скоуп и требования;
• наверняка внутри у каждой функции есть требования со стороны заказчика — запустить функцию к 1 июля или к 20-летию компании;
• результат — отдельная, осязаемая функциональность.

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

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

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

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

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

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

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

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

• создание процесса сопровождения;
• введение ответственного за процесс;
• выделение отдельной команды для сопровождения и решения инцидентов;
• обозначение целевых показателей, формирование SLA;
• создание классификации багов: какой баг критический, какой — с низким приоритетом;
• и так далее.

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

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

• самодостаточность: владение компетенциями, необходимыми для развития продукта;
• самостоятельность: принятие решений без согласования с ЛПР;
• постоянность: накопление знаний, необходимых для принятия решений здесь и сейчас. Как правило, эти знания невозможно задокументировать в полной мере;
• открытость: обеспечение согласованности в развитии продукта. Горизонтальные связи между участниками различных команд выстраиваются с помощью демо или дайджестов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• приоритеты команды А менялись, чтобы помочь команде Б реализовать фичу;
• команда А подключалась к новой области и помогала зарелизить фичу в неизвестном ей домене;
• как правило, между необходимостью ускориться и принятием решения об ускорении происходило несколько итераций обсуждений, эскалаций вопроса и привлечения лиц большей зоны ответственности;
• договориться команде А с командой Б напрямую было сложно — у каждой из команд свои цели, показатели, которых они должны достигнуть (их KPI, обещания).

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

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

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

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

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

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

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

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

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

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

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

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

• способность соблюдения сроков (но всё ещё без 100% гарантии их исполнения);
• наличие центра принятия решений, который способен разрешить большинство вопросов (он же является источником метазнаний в командах);
• процесс разработки понятен для большинства сотрудников (не погруженных в продуктовую разработку).

Недостатки:

• ориентация на процесс: сделать в срок, пройти все обязательные процедуры, даже если в них нет необходимости;
• низкая вовлечённость в создание продукта, поскольку сотрудники привлечены временно на выполнение задачи;
• излишняя бюрократия из-за необходимости контроля процессов;
• сравнительно высокий уровень затрат на управленческие расходы (на сотрудников, которые контролируют процесс и принимают решения);
• центр принятия решений — узкое место всей цепи. Отсутствие автономии в принятии решений замедляет работу команды;
• проверка гипотез требует отдельного планирования или создания отдельной группы.

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

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

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

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

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

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

• предсказуемость сроков реализации фичи;
• возможность планировать, делать оценки бюджетов на запуск проекта (фичи);
• руководство компании не может отпустить команды в свободное плавание — им важно принимать решения;
• «Открыл таск-трекер — понятно, кто и чем занимается» — эта фраза описывает подход к созданию продукта, расставляет приоритеты.

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

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