🤔Продакт без технического бэкграунда может управлять продуктам или нам нужен архитектор для создания востребованного решения.
Часто сталкиваюсь с запросом и продуктами, которые создавали технари или визионеры. В таких продуктах могут быть великолепные технические решения. Совершенные алгоритмы поиска или определения отклонения, современные языки прогромирования или модные технологии, но в таких продуктах часто нет монетизации. Продукты делались командой увлечённых людей, которые продумали всё кроме того, а кому это всё нужно?
Встречали такое? Давайте вместе разбираться. Попробую кратко в этом сообщении рассказать о разнице ролей Архитектора и продакта (от СРОСТО до бизнес аналитикаразработчика) и в серии постов раскрою разницу 3х популярных фреймворков, относительно связки смыслов(монетизации) и техники(архитектуры и кода).
В B2B-продуктах чёткое разделение ролей архитектора и владельца продукта (Product Owner) критично для успеха. Архитектор фокусируется на технической целостности системы: проектирует инфраструктуру, обеспечивает масштабируемость и интеграцию компонентов. Например, создаёт единую платформу для сервисов строительной отрасли, где продукты взаимодействуют через общие модули (ролевая модель, точки входа) и тем самым экономит командам и бизнесу тучу денег. Владелец продукта максимизирует ценность для бизнеса: управляет бэклогом, расставляет приоритеты задач и синхронизирует команды с целями рынка. В SAFe он работает с Agile-командами для реализации фич, сохраняя баланс между бизнес-требованиями и технической реализацией, возвращая технарей на землю через вопросы: "а сколько мы на этом заработаем?" Отсутствие любой из этих ролей возможно в начальной стадии продукта (команда только ищет себя и пытается решить первые проблемы), но начиная с первых платящих клиентов, надо выделять отдельную роль. Продакт будет сильно топить за новые фичи, забывая про баланс в исправлении багов и перестройки продукта под большие нагрузки, а архитектор будет хотеть больше расширять технические доработки без оглядки на то есть на это деньги или нет.
Что здесь важно: не упустить момент, когда продакт обязан учиться новым техническим аспектам продукта, погружаться в суть изменения и предложений от команды, а архитектор понимает куда приводит "голос клиента" и как P&L(экономика продукта) можем менять запрос. Например: Строили SaaS платформу, но есть запрос на перенос в инфраструктуру клиента и денег там больше и спрос выше... надо менять подход и приземлять на сервера клиента, что часто очень больно.
Метрики технаря и продакта: СРОСЕО - он за деньги и монетизацию. Ближе всех сидит к клиенту и анализирует как может ещё помогать бизнесу, зарабатывая на этом(DAU, LTV, NPS). СТОАрхитектор - он за стабильность работы продукта и снижение затрат на доставку нового( SLA, время отклика системы).
Как им договариваться? Простой ответ - смотреть на деньги вместе :) Сложный - договориться о правилах через фреймворки: Покажу на примере 3х популярных.
Ранние этапы (стартап, MVP или R&D фичи) C4: Быстрое согласование видения через контекстные диаграммы. Пример: визуализация API, баз данных и микросервисов для веб-продукта.
Рост бизнеса (scaling) SAFe: Синхронизация 5-10 команд через Agile Release Trains. Подходит для B2B-платформ с жёсткими сроками поставки. Показывает где может быть место новым техническим решениями в больших командах. Как их правильно планировать и запускать на уже состоявшемся продукте.
Зрелость/Трансформация TOGAF: Работа с доменами (бизнес, данные, приложения, технологии) для самых БОЛЬШИХ. Очень подробные описания, длинные циклы согласования для минимзации рисков, того что пойдёт не туда мысль. Пример: интеграция унаследованных систем в единую архитектуру. 💡 Правило: C4 — для коммуникации, SAFe — для координации, TOGAF — для трансформации. Накидаю примеров в следующих постах. Не зря же сертифицировался и в SAFe и в TOGAF :)
Главный вывод ❌ Миф: «Технарь или продакт могут в одиночку сделать крутой продукт». ✅ Реальность: — Продакт без тех.бэкграунда = рискует потребовать от команды
