Продуктовая работа: оценки, декомпозиция, MVP и техдолг

Продуктовая работа это умение видеть за задачей деньги: чего стоит фича, чего стоит её отсутствие, чего стоит способ, которым ты её делаешь. Лестница уровней здесь особенно наглядна: джун оценивает задачи, миддл эпики, Middle+ их декомпозирует, сеньор ищет дыры в соотношении усилий и ценности, лид управляет техдолгом как продуктом.

Junior: оценка типовых задач

От джуна не ждут точных оценок незнакомого, ждут трёх привычек на типовых задачах:

• Оценка со сверкой. Оценил, сделал, сравнил. Журнал «оценка против факта» за пару месяцев калибрует чутьё лучше любых методик.
• Своевременное информирование о сдвигах. Понял, что съезжаешь, сказал в тот же день. Сдвиг, о котором известно заранее, это планирование; сдвиг, о котором узнали на дедлайне, это инцидент.
• Готовые варианты вместо открытых вопросов. Не «как мне быть с валидацией?», а «вижу два способа: А быстрее, Б надёжнее, склоняюсь к Б, ок?». Человек с вариантами получает ответ за минуту, человек с открытым вопросом ждёт встречи.

Middle: оценка эпиков с подводными камнями

Эпик отличается от задачи тем, что главная работа в нём невидима. Миддл, оценивающий эпик, ищет камни до старта:

• Интеграции. Любая внешняя система это плюс неизвестность: документация врёт, песочница лежит, лимиты открываются в проде.
• Миграции данных. «Добавить поле» в таблице на сто миллионов строк это проект, а не строчка.
• Скрытые потребители. Кто ещё читает этот API, эту таблицу, этот формат событий? Поломка обнаружится после релиза.
• Невидимая работа. Аналитика, фичефлаги, обратная совместимость, выкладка, мониторинг. Сам код часто меньше половины эпика.

Честная оценка эпика выглядит как вилка с условиями: «4 недели, если API партнёра работает как в документации; 6, если нет». Вилка переносит риск туда, где им можно управлять.

Middle+: декомпозиция эпиков

Декомпозиция это проектное решение, а не нарезка по файлам. Хорошая декомпозиция:

1. Режет вертикально. Каждый кусок проходит от UI до базы и несёт проверяемую ценность. «Сначала вся база, потом весь бэк, потом весь фронт» откладывает правду о работоспособности на конец. Почему так, разобрано в уроке Вертикальные и горизонтальные срезы.
2. Ставит рискованное вперёд. Кусок с максимальной неизвестностью (новая интеграция, спорная производительность) идёт первым: провалиться дёшево лучше в начале, чем в конце.
3. Выбирает способ реализации. Декомпозируя, ты уже проектируешь: свой сервис или модуль в монолите, очередь или синхронный вызов. Эти решения стоит фиксировать коротким ADR, формат в уроке Design-записи и ADR.
4. Называет риски словами. У каждого куска: что может пойти не так, как узнаем, что пошло, какой план Б.