Одновопросный дизайн-док: маленький приём планирования, который не даёт фичам выйти из‑под контроля

У каждой команды есть похожая история:

Простой запрос на фичу превращается в «давайте ещё заодно сделаем вот это».
Спека разрастается, макеты пухнут, количество крайних кейсов множится.
Месяцы спустя команда выжата, сроки сорваны, а исходная проблема едва угадывается.

Это и есть feature creep — тихий убийца хороших продуктов.

Хорошая новость: с ним можно бороться с помощью чего-то на удивление маленького — одновопросного дизайн-дока.

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

Какой один вопрос эта фича обязана однозначно закрыть, чтобы мы посчитали её успешной?

Если вы формулируете его правильно, объём работ получает внятные границы. Если формулируете плохо — или вовсе пропускаете — вы прямо приглашаете фичу выйти из‑под контроля.

Дизайн-доки vs функциональные спеки: одна проблема под разными углами

Прежде чем перейти к одновопросному подходу, полезно развести два вида документов, которые часто смешивают:

1. Дизайн-доки (инженеры)

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

Они фокусируются на том, как это будет построено: архитектура, компромиссы, потоки данных, режимы отказа.
Обычно это статичные срезы: фиксация состояния системы в момент проектирования плюс ключевые решения.
Они предполагают техническую аудиторию, которая понимает стек, ограничения и жаргон.

Хороший дизайн-док — как карта местности: он объясняет будущим инженерам, почему система выглядит именно так.

2. Функциональные спеки (продуктовые менеджеры)

Продуктовые менеджеры (а иногда и дизайнеры) чаще всего отвечают за функциональные спецификации.

Они описывают, что делает продукт с точки зрения пользователя и бизнеса.
Это живые документы: они меняются вместе с продуктом — сдвигаются требования, приоритеты, появляется обратная связь.
Они должны быть понятны разной аудитории: инженерам, дизайну, QA, маркетингу, стейкхолдерам.

Функциональная спека — это не карта, а скорее живой контракт: что мы обещаем поставить, как это должно работать и почему это важно.

Оба типа документов необходимы. Оба могут быть написаны блестяще. И оба регулярно захватываются feature creep.

Feature creep: угроза, которая всегда рядом

Feature creep — это не просто раздражающий фактор; это системный риск.

Некоторые из самых известных провалов в истории софта во многом связаны именно с ним:

Windows Vista стала показательным примером раздувающегося скоупа, меняющихся приоритетов и усложняющейся архитектуры, которые растянули сроки и подорвали доверие пользователей.
Google Wave, амбициозная попытка переизобрести коммуникацию, развалилась под весом разросшихся возможностей и неясной ключевой ценности. Он умел многое, но ни в чём одном не был достаточно убедителен.

Паттерн почти всегда одинаков:

Исходная проблема описана расплывчато.
Ранние документы скорее пытаются всем угодить, чем чётко обозначить компромиссы.
Новые идеи пристраиваются к основной фиче («раз уж мы туда полезли…»).
Архитектура сгибается, чтобы их вместить.
Проект становится сложнее осмыслить, протестировать и довести до релиза.

Когда вы это замечаете, резать объём уже дорого — и политически, и технически.

Побороть feature creep только «большей дисциплиной» нельзя. Его нужно сделать невозможным для маскировки.

Здесь и нужен одновопросный дизайн-док.

Одновопросный дизайн-док: что это такое

Одновопросный дизайн-док не заменяет ваши обычные документы. Это фокусирующая линза, которую вы накладываете поверх них.

Весь документ крутится вокруг одной строки:

«Эта фича существует, чтобы ответить на вопрос: “Могут ли пользователи X сделать Y при условии Z?”»

Вот и всё.

Вся остальная часть документа лишь раскрывает этот один вопрос:

Почему этот вопрос важен
Как мы на него отвечаем
На что мы осознанно не отвечаем (пока)

Сводя фичу к одному чёткому вопросу, вы:

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

Если нет, идея либо:

Отвлекает (её нужно вырезать), либо
Это отдельная фича (выделить и приоритизировать отдельно).

Как написать одновопросный дизайн-док

Вот лёгкая структура, которую можно прикрутить к вашему текущему процессу. Обычно это 1–2 страницы до любого глубокого погружения в архитектуру или UI.

1. Начните с одного вопроса

Шаблон:

Ключевой вопрос
Эта фича существует, чтобы ответить на вопрос:
«Могут ли [какие пользователи] [сделать что] когда [в каком контексте/при каких ограничениях]?»

Примеры:

«Могут ли новые trial‑пользователи создать и поделиться базовым отчётом в течение первых 10 минут?»
«Могут ли агенты поддержки увидеть 10 последних взаимодействий с клиентом в одном окне, не переключаясь между инструментами?»

Если вам сложно уместить это в одну строку, вы пока не до конца понимаете фичу.

2. Определите успех через призму этого вопроса

Добавьте короткий раздел Критерии успеха, напрямую связанный с вашим вопросом:

80% новых trial‑пользователей формируют отчёт в течение 10 минут после регистрации.
Агенты поддержки закрывают на 25% больше тикетов без эскалации.

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

3. Явно пропишите нецели

Нецели — ваша самая дешёвая защита от расширения скоупа.

Нецели (для этой итерации)

Продвинутые фильтры отчётов сверх базового шаблона.

Кастомный брендинг для экспортируемых отчётов.

Оффлайн‑доступ.

Часть из этого может быть отличными идеями. Но сейчас они не являются ответом на ключевой вопрос.

4. Набросайте минимальную архитектуру, которая отвечает на вопрос

Теперь в дело вступает полноценный инженерный дизайн-док.

Вы не пытаетесь спроектировать «финальную, все поющих и танцующих» систему. Вы проектируете минимальную цельную архитектуру, которая способна ответить на ключевой вопрос.

Здесь важны описания архитектуры:

Зафиксируйте, как взаимодействуют ключевые компоненты.
Запишите принимаемые решения и их мотивацию.
Отметьте, что вы сознательно откладываете на потом.

Архитектурная документация — не бюрократия, а страховка. Она формализует, чем система является и чем она пока не является, чтобы последующие доработки не незаметно превратили её в хрупкий и несвязный ком.

5. Оставьте док статичным, но свяжите его с живыми спеками

Одновопросный дизайн-док — это скорее снимок состояния:

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

Ваши функциональные спеки, напротив, остаются динамичными:

По мере накопления опыта вы уточняете UX‑детали, крайние кейсы, сценарии.
Спека эволюционирует, но всегда в рамках исходного вопроса.

Когда что-то действительно не вписывается, вы не «тихо переписываете» вопрос — вы осознанно признаёте, что теперь работаете над другой фичей.

Чем это помогает разным ролям

Инженерам

Вы получаете чёткие границы задачи до того, как делать крупные архитектурные ставки.
Когда кто-то просит «маленькую быструю доработку», вы можете ссылаться на ключевой вопрос и нецели, а не спорить о вкусах.
Ваши дизайн-доки остаются компактными: они объясняют, как вы отвечаете на один вопрос, а не как потенциально ответите на десять гипотетических.

Продуктовым менеджерам

Легче отбивать оппортунистическое расширение скоупа: «Это другой вопрос. Давайте заведём под него отдельную фичу».
Функциональные спеки получают твёрдый якорь: изменения либо служат ключевому вопросу, либо уходят вниз в приоритете.
Стейкхолдеры понимают, зачем этот релиз, не перелопачивая десятки страниц требований.

Команде целиком

Выравнивание усиливается, потому что каждый может повторить одну и ту же формулу про назначение фичи.
Компромиссы принимать проще: если оба пути отвечают на вопрос, выбираете более простой.
Шанс выпустить что-то конкретное, получить фидбек и доработать выше, чем при гонке за бесконечно расширяющимся видением.

Как рано ловить feature creep

Чем раньше вы замечаете feature creep, тем дешевле его остановить.

Характерные признаки:

Ваш ключевой вопрос требует «и ещё вот это…», чтобы звучать осмысленно.
Раздел с нецелями пустой или расплывчатый.
Вы добавляете новые сценарии, которые не влияют на ваши метрики успеха.
В архитектурных схемах появляются компоненты «которые могут пригодиться потом».

Лекарство всегда одно и то же: вернуться к одному вопросу.

Спросите себя:

Это всё ещё тот вопрос, который нас волнует больше всего?
Если нет, стоит ли закончить текущую фичу как есть и начать новую, или осознанно развернуть трек?

Так вы избегаете худшего сценария: наполовину ответить на пять разных вопросов и ни на один — по‑настоящему.

Последовательные архитектурные доки: ваша защита в долгую

Со временем продукт будет расти. Появятся новые фичи. Люди будут уходить и приходить.

Ваши архитектурные описания — это долговременная память продукта.

Когда они последовательны:

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

Связка последовательной архитектурной документации и одновопросных дизайн-доков даёт вам два мощных ограничения:

Намерение: зачем эта вещь существует и на какой вопрос она отвечает.
Структуру: как она реализована и какие изменения её сломают.

Именно эта комбинация удерживает продукты сфокусированными, а не хрупкими.

Вывод: один вопрос — много решённых проблем

Feature creep — не моральный изъян и не признак «недисциплинированной» команды. Это естественный результат, когда:

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

Одновопросный дизайн-док — небольшой, но практичный антидот:

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

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

И когда кто-то предложит «ещё одну маленькую штуку», у вас будет спокойный, объективный ответ:

«Идея хорошая. Она просто отвечает на другой вопрос. Давайте напишем под неё отдельный док.»