Ситуация продакта;Пример;Что делать;Где научиться
<b>Прохожу собеседование, попросили построить диаграмму сервисов реального приложения</b>;“Нарисуйте нам, пожалуйста, архитектуру приложения знакомств Tinder”;Строю архитектуру (service diagram): фронтенд, сервисы, базы данных, API, внешние интеграции. Начинаю с начала CJM (например, регистрация пользователя) и продвигаюсь по ее шагам;Главы "Service Blueprint и Архитектура" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Перешел в новую команду/продукт, пытаюсь разобраться</b>;Перешел в продукт “Доставка” большого магазина;Прошу знающих коллег нарисовать общую архитектуру, чтобы понимать что с чем связано внутри и вне моего продукта и найти своих клиентов и зависимости; Главы "Service Blueprint и Архитектура" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Требуется оценить стоимость/сложность разработки проектов/фичей</b>;Пытаешься оценить, сколько займет добавить фичу “Чаевые курьеру”;Строю архитектуру и заполняю чек-лист “Full Product Review” (полный для проекта, и короткий для фичи). Финальное слово по оценке сложности за командой, но со временем продакт может откалибровать свою оценку и использовать ее для конструктивного спора с технарями (”Здесь будет 1 новое поле в базу данных и 1 интеграция, ты уверен, что это займет 2 месяца?”);Главы "Архитектура" и "Full Product Review" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Пишу стратегию развития большого продукта или PRD фичи</b>;Стратегия: выходим с доставки еды на доставку всего<br>Новая фича: подсчет примерного времени доставки; Строю архитектуру и заполняю чек-лист “Full Product Review”: оцениваю бизнес и технические аспекты продукта / фичи;Главы "Архитектура" и "Full Product Review" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Нужны новые идеи для бизнеса;Придумал, как расширить доставку еды на доставку посылок по городу</b>;Строю детальную архитектуру. После этого станет более ясно, какие полезные для бизнеса фичи можно будет добавить относительно просто (building on Tech Insights).;Главы "Архитектура" и "Сервис стриминга музыки" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Нужна новая функциональность, которая уже доступна по API внутри или вне компании</b>;Нужно интегрировать платежи для чаевых курьеру;Изучаю API документацию, детали параметров, пишу задание на интеграцию с API;Глава "АPI" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Клиент требует создать новую функциональность по API</b>;Просят возвращать примерное время доставки;Изучаю / обсуждаю требования клиента, предлагаю input/output, пишу команде задание на создание API, договариваюсь с клиентом об SLI/SLO;Глава "АPI" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Продукт работает, но понимания его здоровья нет</b>;Вроде доставка доставляет, но какие метрики с какими связаны?;Строю полное дерево метрик: NSM (North Star Metric), главные метрики, уровня продукта, SLI своих сервисов, SLI внешних интеграций;Глава "Полное дерево метрик" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Разработка стала занимать кучу времени, все идет медленно, программисты жалуются</b>;Добавление фичи “Корзина” заняло 5 месяцев;Скорее всего, это одна из “болезней” архитектуры: Сильная связанность, Дуплицирование, Бесполезная зависимость, Монолит.<br>Строю архитектуру, обсуждаю с тех лидом и готовлюсь к сложным миграциям.;Глава "Архитектура" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Продукт постоянно ломается</b>;Только что завершилась авария - 5 часов доставка не работала;Разбираюсь с данной аварией по протоколу Пост-мортем, готовлю проактивную защиту продукта (SLIs, функциональное и нефункциональное тестирование, алерты и так далее).;Глава "Здоровье продукта" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Разработчики говорят: «Нам нужно провести масштабный рефакторинг и миграцию»</b>; «Нам нужно срочно переписать всю логику для платежной системы доставки еды!»;PM не принимает окончательного решения о необходимости рефакторинга ("переписывания") кода, но может контролировать бизнес-результат:<br>1) Какую проблему решает рефакторинг и почему нам нужно сделать это сейчас?<br>2) Что произойдет, если мы ничего не сделаем?<br>3) Какой бизнес-процесс он ощутимо улучшит? (важное изменение в неважном процессе в конечном итоге неважно)<br>4) Сколько времени займет разработка? (PM контролирует ограниченные ресурсы, поэтому всегда может сказать «нет» в пользу какой-то другой задачи); Глава "Full Product Review" симулятора "Тех для продакта" link=https://productdo.it/tech_pm;
<b>Команда пытается сделать выбор между несколькими фронтенд/бэкенд фреймворками</b>;Что использовать: Angular или React, или Flutter? (подставь любые непонятные названия); PM не несет ответственности за то, КАК будет реализовано решение, поэтому решение о фреймворке остается за командой. Работа PM заключается в том, чтобы перечислить требования к продукту (что должен делать данный Frontend, какие функции он должен иметь и т. д.) и предоставить нефункциональные требования (задержка: 50 мс или 5 с, трафик: 10 запросов/сек или 1000 запросов/сек, безопасность, необходимость переиспользования в будущем и т. д.). Теперь команда может выбрать любой фреймворк, удовлятворяющий всем требованиям.;Глава «Полный обзор продукта» симулятора «Tech for PM» link=https://productdo.it/tech_pm;
