Ловушка тяжёлого ТЗ: 30 страниц документации вместо 2-недельного теста

PM открывает Confluence и начинает писать. Контекст продукта. Цели и метрики. Описание пользователей. Пользовательские истории — двадцать штук. Use ca...

PM открывает Confluence и начинает писать. Контекст продукта. Цели и метрики. Описание пользователей. Пользовательские истории — двадцать штук. Use cases. Edge cases. Acceptance criteria для каждого сценария. Макеты с аннотациями. Технические ограничения. Открытые вопросы. Глоссарий.

Через три недели документ готов. Тридцать одна страница. Все поля заполнены, все вопросы закрыты. PM отправляет ссылку команде и чувствует удовлетворение — работа сделана профессионально.

Разработчик открывает документ, читает первые три страницы, закрывает и идёт на стендап, чтобы спросить: «Чего конкретно хотим?» Дизайнер начинает с макетов, потому что текст читать долго. Тимлид добавляет документ в закладки и больше к нему не возвращается.

Через два месяца — релиз. Клиент смотрит на продукт и говорит: «Хм, мы имели в виду немного другое».

Почему команды пишут тяжёлые ТЗ

Тяжёлое ТЗ — не про качество коммуникации. Оно про страх и снятие ответственности.

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

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

Ловушка 01 - Полнота как замена ясности

Интуитивное решение: чем подробнее описание — тем меньше разночтений. Добавить больше деталей, закрыть больше edge cases, описать больше сценариев.

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

Ясность — это способность любого члена команды за 30 секунд ответить на три вопроса: кто наш пользователь, какую проблему мы решаем, как мы поймём, что решили. Если тридцать страниц не дают ответа на эти три вопроса — они создают шум, а не ясность.

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

Что произошло: команда одного B2B-инструмента для автоматизации HR написала PRD на 28 страниц для нового модуля онбординга. Через неделю после старта разработки провели синхронизацию. Выяснилось: три разработчика поняли «онбординг» как процесс регистрации нового сотрудника, два — как процесс обучения после найма. Документ описывал оба сценария вперемешку. Две недели разработки в двух разных направлениях. Потребовалась ещё одна встреча на два часа, чтобы договориться о том, что должно было быть в первом абзаце PRD.

«Мы написали подробный документ, чтобы избежать недопониманий. В итоге именно документ их и создал — потому что каждый прочитал нужное ему место и пропустил остальное» — типичная ситуация после первого ревью тяжёлого ТЗ с командой.

Ловушка 02 — Документ как замена эксперименту

Интуитивное решение: прежде чем начать разработку, нужно всё продумать и зафиксировать. Чем тщательнее проработка — тем меньше ошибок в реализации.

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

Lean-подход к этой проблеме: сначала проверьте рискованнейшее предположение за минимальное время, потом документируйте то, что работает. Не наоборот.

Ключевая метрика: время от формулировки гипотезы до первого контакта с реальным пользователем. Если это время превышает три недели — документация стала барьером между командой и рынком.

Что произошло: стартап в сфере EdTech потратил шесть недель на написание детального ТЗ для нового формата курсов — интерактивных кейсов. Документ описывал механику каждого экрана, систему оценок, логику переходов. После трёх месяцев разработки и пяти дней тестирования с реальными пользователями выяснилось: целевая аудитория не хотела проходить кейсы последовательно — им нужен был доступ к отдельным блокам в любом порядке. Вся архитектура, детально описанная в ТЗ, опиралась на линейный сценарий. Переделка заняла ещё два месяца. Альтернатива: пять разговоров с пользователями перед написанием документа — три дня.

Ловушка 03 - Снятие ответственности через детализацию

Интуитивное решение: если всё задокументировано — претензий не будет. Инженер не может сказать «я не знал», дизайнер не может сказать «мне не объясняли».

Почему это ломает систему: детальная документация переносит ответственность с принятия решений на соблюдение инструкций. Инженер следует спецификации, дизайнер реализует макеты, QA проверяет acceptance criteria. Никто не думает о том, решает ли конечный продукт реальную проблему — это уже «было написано в ТЗ», значит, ответственность PM.

PM, написавший подробное ТЗ, часто оказывается в парадоксальной позиции: команда сделала всё точно по документу, но продукт не работает. И никто в команде не чувствует ответственности за результат — каждый выполнил свою часть договора. Подробное ТЗ убивает ownership.

Ключевая метрика: как команда реагирует, когда после релиза оказывается, что продукт не решает нужную задачу. Если ответ «но мы сделали всё по ТЗ» — культура документирования уже сдвинулась в сторону снятия ответственности.

Что произошло: в одной продуктовой команде B2B SaaS PM писал настолько детальные спецификации, что разработчики перестали задавать вопросы — они просто следовали документу. После очередного релиза, который клиенты не приняли, провели ретроспективу. Разработчик сказал прямо: «Я видел, что это решение не будет работать — но в ТЗ было написано именно так. Я решил, что PM знает что-то, чего не знаю я». PM не знал — он тоже делал предположения, просто оформлял их как факты.

«Когда документ стал достаточно толстым, люди перестали его читать — они просто ссылались на него как на доказательство того, что сделали своё дело» — паттерн, который всплывает в командах после первого честного разговора о культуре документации.

Ловушка 04 — Сложность как сигнал профессионализма

Интуитивное решение: хороший PM пишет подробный документ. Это показатель глубины проработки и серьёзного отношения к задаче.

Почему это ломает систему: сложность документа — это не показатель сложности мышления. Часто наоборот: чем чище понимание задачи, тем короче документ. Подробный документ может скрывать отсутствие чёткого ответа на вопрос «зачем». Команда читает двадцать страниц about what и ни одного абзаца about why — и строит то, что описано, не зная, нужно ли это вообще.

В командах, где PM оценивается по количеству страниц, а не по качеству решений, тяжёлая документация становится карьерной страховкой. Но это именно она — не инструмент для создания продукта.

Конкурентный контекст

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

Стартап с командой в пять человек, имитирующий корпоративные процессы документирования, теряет главное преимущество: скорость. Пять человек могут провести разговор за 40 минут и прийти к такому же пониманию, которое достигается 30-страничным документом — только быстрее и с живым ownership у каждого участника.

Именно скорость гипотеза → обратная связь от рынка — то, чего крупный игрок достичь не может. Тяжёлое ТЗ эту скорость обнуляет.

Цена ошибки

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

Потеря ownership в команде. Команда, следующая инструкциям, не инвестирована в результат. Когда продукт не работает — никто не чувствует себя частью решения, потому что они просто выполняли ТЗ. Это культурная проблема, которая накапливается с каждым новым тяжёлым документом.

Потеря скорости обучения. Гипотеза, оформленная в тридцать страниц, трудно пересматривается. Через месяц разработки никто не хочет говорить «может, мы неправильно сформулировали задачу» — слишком много вложено. Тяжёлый документ создаёт психологический барьер против пересмотра предположений.

Как делать правильно

1. Начните с одностраничного brief, а не с полного PRD. Пять полей: проблема в одном предложении, сегмент в одном предложении, гипотеза решения в одном предложении, критерий успеха — конкретное число, out of scope — что мы не делаем. Если не можете заполнить эти пять полей — гипотеза не готова к разработке. Если можете — этого достаточно для первого спринта.
2. Пишите документ после первой итерации, а не до. Проведите пять разговоров с клиентами. Постройте минимальный прототип. Покажите реальным людям. Зафиксируйте, что узнали. Теперь пишите спецификацию — она будет описывать то, что работает, а не то, что вы предполагаете.
3. Разделите «что» и «почему» явно. Первый абзац любого продуктового документа: проблема и сегмент. Не решение, не требования — контекст. Команда должна иметь возможность предложить альтернативное решение, если поймёт задачу иначе. Документ, начинающийся с решения, лишает команду этой возможности.
4. Используйте живой разговор для сложных вопросов. Всё, что требует больше двух абзацев текста для объяснения — выносите на встречу. Живой разговор с вопросами и ответами передаёт контекст за 20 минут вместо часа чтения. Документируйте решения встречи, а не саму встречу.
5. Введите максимум страниц для рабочего документа. Операционное правило: рабочий PRD для одного спринта — не более трёх страниц. Если не помещается — либо scope слишком большой, либо в документе есть лишнее. Три страницы читают. Тридцать — сканируют.
6. Разделите документацию по стадиям. Pre-PMF: одностраничник. Пост-PMF, этап роста: полный PRD с деталями. Масштаб: RFC (Request for Comments) для технических решений. Использование enterprise-документации на стадии поиска PMF — попытка делать то, что уместно через два года, прямо сейчас.
7. Добавьте явный раздел «что мы не знаем». Лучший способ показать зрелость мышления — не заполнить все поля, а явно зафиксировать открытые вопросы и риски. «Мы предполагаем X, но не проверяли» — более честный и полезный сигнал команде, чем три абзаца, написанных как факт, хотя за ними стоит предположение.

Литература и источники

1. Marty Cagan - «Inspired» (2017) Почему читать: глава о «product discovery» объясняет, почему документация после discovery — описание реальности, а не инструмент её создания. Что взять: принцип «спецификация описывает, что мы узнали, а не что мы хотим» как фундамент легковесной документации.
2. Jeff Patton - «User Story Mapping» (2014) Почему читать: альтернативный подход к спецификациям, который заменяет линейный документ визуальной картой пользовательского опыта. Что взять: техника story mapping как способ достичь общего понимания в команде за один workshop вместо двух недель документации.
3. Ryan Singer - «Shape Up» (Basecamp, 2019, бесплатно онлайн) Почему читать: описание подхода, при котором документ («pitch») умещается на одну страницу и содержит только то, что нужно команде для автономной работы. Что взять: формат «fat marker sketch» как замена детальным макетам на стадии постановки задачи.
4. Henrik Kniberg - «Lean from the Trenches» (2011) Почему читать: практический опыт работы с минимальной документацией в enterprise-контексте. Что взять: принцип «just enough documentation» и конкретные примеры того, что реально нужно разработчикам, а что является бюрократическим артефактом.
5. Gojko Adzic - «Specification by Example» (2011) Почему читать: методология, при которой вместо подробного описания требований команда формулирует конкретные примеры ожидаемого поведения. Что взять: технику «given-when-then» как замену многостраничным acceptance criteria.