Как происходит декомпозиция задач

Что проверяют

Умеете ли вы превратить расплывчатую фичу в набор задач, каждую из которых можно сделать, проверить и влить за день или два. Следом обычно дают пример, скажем страницу каталога с фильтрами, и просят разбить её вслух.

Как отвечать

Покажите порядок действий:

• уточнить результат: что пользователь сможет сделать, критерии приёмки, макеты, поддерживаемые браузеры и разрешения экрана;
• резать вертикально: каждая задача даёт видимый кусок поведения. Не «вёрстка», «логика», «тесты», а «список карточек с пагинацией», «фильтр по цене», «фильтры сохраняются в URL»;
• договориться о контракте с бэкендом: формат ответа API фиксируется заранее, фронтенд работает на моках через MSW или по OpenAPI-схеме и не ждёт готового сервера;
• перечислить состояния: загрузка, пустой результат, ошибка, медленная сеть, мобильная вёрстка, работа с клавиатуры. Каждое состояние это отдельная работа, и её часто забывают оценить;
• выделить неизвестное: новая библиотека или сложная анимация выносится в spike с ограничением по времени;
• общее вперёд: переиспользуемые компоненты и типы делаются первыми, от них зависят остальные задачи;
• выкатывать частями: незаконченная фича вливается в main за фичефлагом, без долгоживущей ветки.

Ориентир размера: задача помещается в один pull request, который коллега прочитает за полчаса.

Приведите свой пример с цифрами: сколько задач получилось, что оказалось недооценённым. Если декомпозицию всегда делал лид, расскажите, как вы разбивали свою часть на коммиты и PR, это тот же навык.

Где спотыкаются

Режут горизонтально: сначала вся вёрстка, потом вся логика, потом тесты. До последнего шага показать нечего, а риски всплывают в конце.

Разбивают только happy path. Ошибки, пустые списки и адаптив потом превращаются в незапланированные задачи.

Не учитывают зависимость от бэкенда и дизайна и срывают сроки из-за неготового API, хотя моки сняли бы блокировку.