Этот материал - часть практического курса “ProductDo: Tech для продакта”.

Ситуации продакта с Архитектурой и их решения

Ситуация Пример ситуации Шаги продакта
Прохожу собеседование, попросили построить архитектуру реального приложения “Нарисуйте нам, пожалуйста, архитектуру приложения знакомств Tinder” Строю архитектуру по шагам: фронтенд, сервисы, базы данных, API (см. следующую таблицу)
Перешел в новую команду/продукт, пытаюсь понять, что к чему Перешел в продукт “Доставка” большого магазина Прошу знающих коллег нарисовать общую архитектуру, чтобы понять, что с чем связано внутри и вне моего продукта и найти своих клиентов и зависимости.
Мне нужно заменеджить создание сложной кросс-командной фичи Задача: ввести единую платежную систему для всех сервисов компании: такси, доставки еды, аренды самокатов Вместе с Тех Лидом рисую архитектуру сервисов, относящихся к оплате в перечисленных продуктах. Продакт не принимает решение о финальной архитектуре, но должен понимать, что к чему, чтобы залидить проект.
Дали задание запустить новый продукт: пытаюсь понять, что строить и сколько это займет Директор: “Хочу поручить тебе разработать систему интеграции с таксопарками для нашего приложения такси” Строю архитектуру (сначала сам, потом с тех лидом), продумываю все связи. Дополняю ее шаблоном “Full Product Review”.
Разработка стала занимать кучу времени, все идет медленно, программисты жалуются Добавление фичи “Корзина” заняло 5 месяцев. Скорее всего, это одна из “болезней” архитектуры:
  1. Сильная связанность
  2. Дуплицирование
  3. Бесполезная зависимость
  4. Монолит

Иду обсуждать это с тех лидом и готовлюсь к сложным миграциям. | | Я - Lead продакт и планирую распределение команд по продукту | Есть 3 команды, чтобы построить онлайн-магазин велосипедов. | Строю архитектуру. На основе архитектуры и бизнес-целей делю команды, например, так:

Как построить архитектуру: короткая версия

  1. Смотрим на требования CJM/Figma (или задаем их сами, если строим с нуля)
  2. Строим пошаговую Service Blueprint табличку
  3. Строим Service Diagram: выделяем и рисуем frontend-элементы продукта
  4. Строим Service Diagram: выделяем и рисуем backend-элементы продукта. Для этого, для всех бизнес-процессов:
    1. Выбираем отдельный бизнес-процесс и называем сервис
    2. Добавляем сервису базы данных
    3. Добавляем сервису API
    4. Добавляем сервису внешние интеграции
  5. Полируем Service Diagram под аудиторию: архитектура должна выглядеть читаемо

Как построить архитектуру: длинная версия

Шаг Простое объяснение Пример
Смотрим на требования CJM/Figma К началу построения архитектуры мы уже знаем, какие фичи нужны пользователю и какие данные это подтверждают. Чаще всего это выражается в каком-то наброске дизайна (например, в Figma). Это твои базовые, не технические навыки. Решили, что для онлайн-магазина велосипедов потребуются:

Если хотим подчеркнуть связь каких-то элементов, используем обычные стрелки. Направление - от “просящего” к тому, кто делает “работу”.

Это - самая трудоемкая и долгая часть, занимает 80% времени, так что не бойся, если идет тяжело. В симуляторе мы разбираем 5 примеров (такси, доставка еды, стриминг музыки и тд), чтобы отработать навык. | См. архитектуру на картинке ниже:

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

Так что будь внимателен, твоя “картинка” - это будущее организации. |

Пример заполненной Service Blueprint и Архитектуры для магазина велосипедов

image.png

image.png

Чек-лист продакта: технический стек

Элемент Простое определение Какие бывают Вопросы продакта
Frontend-технологии Какие технологии использованы для создания UI, которые видит пользователь HTML: каркас web-страницы
CSS: стиль web-страницы
Javascript: язык для ****всего ****интерактива ****web-страницы - Почему выбраны именно эта технология? Можно посмотреть сравнительную табличку?

| SQL: структурированные данные, сложные поиски, быстрый доступ, данные доступны сразу, сложнее скейлить NoSQL: неструктурированные данные, простые поиски, медленный доступ, данные доступны когда-то, легче скейлить Cache/CDN: способ держать частые элементы “под рукой” | - Соответствует ли выбор решения хранения продуктовым требованиям (частота и скорость поиска, скейл, консистентность)?