Проектно-продуктовый подход в разработке корпоративных платформ

Когда вендор создает новый продукт, часто наиболее эффективным становится гибридный подход к разработке, который сочетает в себе одновременно и проектный, и продуктовый. Рассмотрим особенности и преимущества такого подхода на примере разработки корпоративной платформы. Анастасия Гуляева, Product Manager супераппа для бизнеса eXpress — о разнице подходов при разработке, приоритизации клиентских задач и навыках, которыми должен обладать продакт-менеджер.

Анастасия Гуляева

Product Manager супераппа eXpress

Что такое проектный и продуктовый подходы 

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

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

Гибридный подход: объединяя лучшее 

В гибридном подходе легче создавать продукт, который решает задачи не только конкретного клиента, но и имеет потенциал стать основой для будущих решений. Это особенно полезно, когда заказчик хочет собственное брендированное приложение по White Label. Задача команды — сделать так, чтобы продукт можно было масштабировать и адаптировать для других отраслей. 

Здесь на помощь приходит Agile — популярная методология у разработчиков корпоративных платформ. К примеру, методология Scrum позволяет двигаться короткими спринтами (обычно две недели). При этом разные команды могут параллельно разрабатывать, тестировать и внедрять функциональность, обеспечивая непрерывное обновление для клиентов.

Универсальные функции для разных клиентов 

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

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

Кто двигает продукт вперед в гибридной разработке

Главные визионеры – это, конечно, основатели компании, стейкхолдеры и продакт-оунеры. Они держат руку на пульсе, следят за тем, какие тренды появляются на рынке, и решают, в каком направлении двигаться. 

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

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

Как упорядочить запросы клиентов

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

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

Такую таблицу можно структурировать следующим образом:

• Список функций: перечисление всех фич со ссылками на описание проблемы (например, в JIRA/Confluence) и примеры возможных решений. 

• Статусы выполнения: отметки «Ожидание», «В работе» и «Готово» с указанием версии, в которой реализована фича. 

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

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

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

• Оценка сложности тестирования: оценка сильно зависит от того, насколько глубоко уже проработана фича в аналитике. 

• Оценка сложности дизайна / клиентской архитектуры / серверной архитектуры / разработки по платформам web/ios/android/backend: заранее определяется шкала оценки и выставляются они после обсуждения с лидами заявленных команд. В нашем случае мы взяли аналитику за три года разработки, выявили три типа задач и смогли найти усредненное значение срока реализации каждого типа отдельно (например, маленькая задача — 1 день, средняя — 5 дней, большая — 2 спринта). 

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

  Вас может заинтересовать: 

  Когда без А/В-тестирования можно обойтись
  

Эта система позволяет продуктовой команде двигаться к цели, сохраняя баланс между запросами клиентов и видением разработчика. Например, уже виден тренд на AI. Но при этом он пока не является запросом в виде строчки в ТЗ от большинства заказчиков, хотя команда может уже сейчас закладывать на него ресурсы, так как он несет потенциал для будущего продукта.

Управление техническим долгом 

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

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

Какими навыками должен обладать продакт-менеджер

Сейчас есть тренд на узкую специализацию продакт-менеджеров, особенно в больших компаниях: Growth PM, Marketing Product Manager/PMM, Technical Product Manager, Data Product Manager. Продакт-менеджер может быть ориентирован на рост, маркетинг, дизайн или технологическую составляющую. Но ключевыми остаются навыки общения, критическое мышление, умение договариваться и задавать правильные вопросы. Иногда полезно сказать «нет» — и аргументировать, почему идея клиента не принесет желаемого результата, а также предложить альтернативное решение. 

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

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