Ситуация продакта;Пример;Что делать;Где научиться
<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>;Разработчик: “Нам срочно нужно переписать всю логику платежей за доставку!”;Продакт не принимает финального решения о необходимости рефакторинга (”переделки”) кода, но может аргументированно поспорить:<br>1) Какую проблему и зачем решает рефакторинг? (понять что и как - главные продуктовые вопросы)<br>2) Что будет, если ничего не делать? (помогает понять, как технари сами оценивают важность)<br>3) Какой бизнес-процесс он улучшит и насколько? (поможет принять бизнес-решение: важное изменение в неважном процессе в итоге неважно);Cимулятор "Тех для продакта" link=https://productdo.it/tech_pm;
