January 12, 2024

#6: Продукты и проекты. А в чем разница?

Вам переслали эту ссылку? Вы можете подписаться на рассылку и получать письма по пятницам. Или подписывайтесь на канал Meet Deadlines в Телеграм, если вы предпочитаете эту платформу

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

О компании кратко - это fintech-компания, которая разрабатывала финансовый сервис для своих клиентов. Проектная деятельность до трансформации была внедрена во все сферы жизни:

• Запуск новых услуг на рынок.
• Модернизация процессов.
• Трансформация компании.
• Найм людей (если нужно нанять за 1 раз сразу много специалистов).
• Маркетинговые кампании - тоже проекты.

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

В чем же диссонанс?

Основа этого конфликта - в теории. Давайте взглянем на то - что является проектом, а что продуктом.

Проект

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

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

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

• Не имеющее конечной фиксированной цели (по SMART - это отличный фреймворк);
• Не имеет конечных сроков или сроки постоянно переносятся с ростом функциональности (и бюджета, и ресурсов);
• Серийное производство продукта (выпуск автомобилей Lada Vesta).

И самое главное в проекте - это процесс (сбор требований, критерии приемки результата, планирование и т.д.), а не продукт (результат деятельности проекта). То есть проект важен тогда, когда необходимо обеспечить для всех вовлеченных лиц понятную и прозрачную деятельность и попытаться достичь измеримого и понятного всем результата. Для этого придуманы документы (Паспорт проекта, Чек-лист тестировщика), процессы (P3.express), фреймворки (SCRUM), статусные встречи и отчеты (Monthly/Quarterly Business Review), и т.д.

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

Продукт

Продукт - это то, что востребовано клиентами, то что постоянно улучшается и развивается, без четкого представления конечного результата. Если продукт не востребован клиентами - это плохой продукт и это провал, независимо от способа его создания (делает его проектная или продуктовая команда). Главный критерий качества продукта - востребованность и удовлетворенность клиента. Продукт - решает проблемы клиента и это привлекает, заставляет клиента пользоваться продуктом снова и снова.

Как правило, на начальном этапе создания продукта есть очень смутное представление о том как он будет выглядеть. В процессе создания продукта, команда уточняет, экспериментирует, приземляет и кристаллизует продукт исходя из востребованности функций продукта и обратной связи пользователей. При этом, продукт в процессе создания и выхода на рынок может переродиться и уйти от изначального видения. Так происходит, поскольку шаги создания продукта построены на базе гипотез и их проверок, ошибки при создания продукта - неизбежны. Примеры и история такого перерождения продукта в процессе развития - ProductHub и Cherry Labs (cсылка с Timestamp)

Примеры продуктов: - Мобильная игра Crash of Clans - Интернет-Банк Точки - Apple iPhone и Google Android - VK

Если вы посмотрите на экран вашего мобильного телефона - каждая иконка, это отдельный продукт :)

Таким образом, главное отличие продукта и проекта, в следующем:

Проект ориентирован на соблюдение процесса Продукт - на удовлетворение потребностей клиента. Изменение потребностей (требований) - постоянный атрибут продукта

Продукты и проекты - связаны между собой

Давайте возьмем продукт, которым вы можете пользоваться практически каждый день - Интернет-Банк (или Мобильный) от вашего Любимого банка.

В рамках сервиса рождается различная функциональность:

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

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

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

Но…

1 июля - это не срок завершения проекта в нашем случае, а дата вывода функциональности на рынок. После этой даты развитие функциональности не останавливается. Мы собрали фидбэк об использовании этой фичи в течения 1 месяца, сделали выводы о поведении пользователей и запускаем следующую итерацию развития функциональности или фичи - Открытие расчетного счета за 1 минуту! Жизненный цикл работы с фичей не завершается с выпуском первой версии.

Есть ли Понятная цель? Нет. Есть потребность, хотелка. На старте есть лишь осязаемые видения, которые в процессе реализации могут измениться, расшириться. Здесь нет цели по SMART. После запуска этой функциональности может произойти переосмысление (появилась гипотеза, идет проверка гипотезы и далее - подтверждение/опровержение) и перерождение функциональности.

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

Возвращаясь к компании, где я работал. Реализации новой функции, рассматривалась как отдельный проект. С упрощенным, с точки зрения бюрократии, проектом. Формировались проектные команды. Каждую фичу называли "Проектом". Мне казалось, что называя Продукт - "Проектом" - уже определяло отношение к нему. Я это видел в том, как формировались проектные команды.

Проектная или продуктовая команда?

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

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

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

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

Как решаются задачи в Продуктовых и Проектных командах?

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

Масштабирование команды и продукта

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

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

Сопровождение продукта

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

• Необходимо создать процесс Сопровождения.
• Необходимо вводить роль ответственного за процесс, чтобы управлять потоком задач.
• Команды динамические, поэтому выделяется отдельная команда для сопровождения и решения инцидентов.
• Чтобы контролировать процесс - обозначаются целевые показатели, формируется SLA.
• Описывается классификация багов - какой баг Критический, какой - с Низким приоритетом.

Фокус - на прозрачности.

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

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

В случае передачи сопровождения фичи в другую команду - новой команде понятно, куда обратиться за знаниями.

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

Если нужно доработать продукт, в соответствии с текущими реалиями? Представить рынку и пользователям - новую функциональность.

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

• Необходимо сформировать команду, в соответствии со стэком,
• Провести процессы инициации проекта.
• Начать работу.

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

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

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

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

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

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

У нас уже разработана функциональность, но мы решили ее адаптировать под требование рынка и времени.

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

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

Если закончились задачи

Если работа над фичей завершена, все баги починены. Что делать?

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

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

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

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

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

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

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

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

Если возникает необходимость ускориться для работы над фичей - какие опции доступны?

Проектная команда. Такое решение принимается на самом верху и спускается вниз на исполнение:

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

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

Основные сложности

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

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

• Ориентация на процесс - сделать в срок, пройти все обязательные процедуры.
• Низкая вовлеченность в создание продукта, поскольку сотрудники привлечены временно на выполнение задачи.
• Создает излишнюю бюрократию с целью обеспечения контроля процессов.
• Сравнительно высокий уровень затрат на управленческие расходы (наличие сотрудников, функции которых - контролировать процесс и принимать решения).
• Центр принятия решений - узкое место всей цепи. Отсутствие автономии в принятии решений - замедляет работу команды.
• Проверка гипотез в работе продукта - требует отдельного планирования или создание отдельной группы, цель которой - проверить гипотезу

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

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

Основные плюсы

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

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

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

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

Что же лучше?

Спустя некоторое время, анализируя, почему компания упорно хотела применять и применяла проектный подход к работе над продуктом, я пришел к выводу, что для компании была важна прозрачность процессов. Не продукт, как такой, а именно прозрачность:

• Предсказуемость сроков реализации фичи.
• Возможность планировать, делать оценки бюджетов на запуск проекта (фичи).
• Основная идея была: "Открыл таск-треккер и понятно кто и чем занимается".
• Руководство компании не смогло отпустить команды в свободное плавание - им важно принимать решения.

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

Узнать подробнее обо мне можно здесь, об этой рассылке - в специальном разделе