# Пример: закрываем пробел

Канонический адрес: https://producthub.live/shape-up/primer-zakryvaem-probel
Автор публикации: Product Hub (https://producthub.ru). Опубликовано: 2026-10-13. Обновлено: 2026-10-13.
Книга: Ryan Singer (Райан Сингер), «Shape Up: Stop Running in Circles and Ship Work that Matters», Basecamp, 2019. Оригинал: https://basecamp.com/shapeup

Перевод на русский, часть 1 «Подготовить выполнимый проект», глава 4 «Проверить риски». Оглавление: https://producthub.live/shape-up

Например, когда мы определяли проект «Группы задач» (To-Do Groups), мы предложили разделители в списке задач:

![Разделители в списке: отдельные задачи и задачи, собранные в группы](https://producthub.live/assets/books/shape-up/light/p038-01.webp)

Нам нравилась идея разделителей, и логика разделения на отдельные и сгруппированные задачи казалась разумной. Но при более внимательном рассмотрении мы поняли, что не решили, как показывать выполненные задачи. В прежнем дизайне несколько последних выполненных задач отображались под списком. Нужно ли теперь показывать выполненные задачи внизу каждой группы, а не всего списка? Или по-прежнему показывать их внизу и повторять те же разделители в разделе выполненных задач? А может, стоит полностью пересмотреть то, как мы работаем с выполненными задачами?

Это был пробел в концепции. Если бы мы его не закрыли, то переложили бы на команду глубокую проблему дизайна и без достаточных оснований потребовали найти решение в условиях дедлайна. Безответственно передавать команде запутанный клубок взаимозависимостей, а затем просить распутать его за короткое фиксированное время.

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

![Группируются только невыполненные задачи; к выполненным добавляются названия групп](https://producthub.live/assets/books/shape-up/light/p039-01.webp)

Такой компромисс трудно принять, работая внутри цикла под давлением. Есть множество причин, по которым иной дизайн или более глубокое переосмысление выполненных задач было бы объективно лучше. Почему бы не попробовать показывать их внутри каждой группы? Дизайнер вполне может подумать: «Может, если я ещё немного поэкспериментирую с оформлением, они будут лучше вписываться». Так можно легко потратить несколько дней из и без того немногочисленных недель на тупиковый путь.

При проработке мы думаем меньше об идеальном конечном дизайне и больше — о базовом качестве и риске. Концепция с этим компромиссом сохраняет все элементы, ради которых проект стоило делать, — группы невыполненных задач — и позволяет отсечь большой хвост риска.

При оформлении описания проекта мы отдельно укажем эту «заплатку» как часть концепции. Тогда на следующих этапах никто на ней не споткнётся.

Далее: [Обозначьте, что остаётся за рамками](https://producthub.live/shape-up/oboznachte-chto-ostaetsya-za-ramkami)