«А мы думали...» и другие проблемы без понимания задачи

В большом проекте легко отклониться в сторону и начать делать не то, с чего начинали. Чтобы этого не случилось, нужен своего рода компас, с которым сверяешься на каждом этапе. Для нас таким компасом становится документ под названием «понимание задачи».

Что такое понимание задачи и для чего нужно

Понимание задачи (ПЗ) — это ёмкое и внятное описание сути проекта. Что именно нужно сделать, зачем это вообще затевается, как мы собираемся это реализовать, какие ресурсы понадобятся и по каким критериям поймём, что всё получилось.

Этот документ готовим мы — как исполнитель, ещё на этапе коммерческого предложения.

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

Зачем нужно ПЗ?

• Понять, что действительно важно. Не на уровне кнопок или дизайна, а стратегически — что клиент хочет получить и зачем. Это помогает с самого начала выбрать правильное направление.
• Составить план. Обсуждаем подходы, разбиваем проект на шаги, расставляем приоритеты — что важно сразу, а что может подождать. И главное — договариваемся, какой результат должен быть на каждом этапе.
• Избежать переделок. Когда всё согласовано заранее, итог совпадает с ожиданиями, а не становится неприятным сюрпризом.
• Разруливать спорные моменты. Например, не можете выбрать навигацию? Смотрим в задачу из ПЗ — и выбираем тот вариант, который её решает лучше.
• Закрепить договорённости. Фиксируем сроки, бюджет, условия, ограничения — чтобы потом не было «а мы думали, что вы…».
• Стартовать проект быстро. Клиенту не нужно готовить ТЗ, тратить время на формулировки или искать, кому бы это делегировать. Мы всё уточняем голосом и сами оформляем ПЗ. Это позволяет сразу переходить к делу, а не зависать на этапе обсуждения.

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

Чем понимание задачи отличается от ТЗ

ПЗ легко спутать с ТЗ — техническим заданием, но это совсем не одно и то же. Они действительно чем-то похожи: у обоих нет строгого шаблона, фиксированного объёма страниц или требований к формату. И в том, и в другом могут быть технические детали. Оба — про постановку задачи.

Но есть ключевые отличия.

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

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

Проще говоря, ПЗ помогает выбрать направление, а ТЗ — зафиксировать маршрут.

Почему клиенту лучше с ПЗ

Представьте, вы приходите в агентство за сайтом, а менеджер сразу: «Пришлите нам ТЗ, чтобы мы посчитали стоимость». Вы лезете в интернет, как его составить, дёргаете коллег, тратите время — и через 1–2 недели приносите техзадание. А в ответ слышите: «Это будет стоить хренадцать миллионов» или «мы такое не делаем». И всё зря.

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

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

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

ПЗ даёт свободу найти лучшее решение. Мы разбираемся, какой результат вам нужен, и предлагаем разные пути, как к нему прийти. У нас шире насмотренность, и это помогает выйти за пределы привычного видения вашего проекта. А ТЗ сразу загоняет в жёсткие рамки: что и как делать, — часто без шанса на более удачные идеи.

Как написать понимание задачи — пример

У ПЗ нет ГОСТа. Каждый пишет его по-своему — если вообще пишет. Мы в Brele подходим к этому осознанно и собрали свой шаблон понимания задачи. Вы можете использовать эту структуру у себя — она помогает быстро навести порядок в проекте.

Вот пример (сильно сокращённый, но суть передаёт):

• Клиент и ситуация. «Новация» — компания, которая продаёт мебель и оборудование для школ и детсадов по всей России.
• Цель — где хотим оказаться, какой результат получить. Увеличить выручку интернет-магазина.
• Задача — что нужно сделать, чтобы достичь цели. Создать ценностное предложение, которое захочется купить.
• Гипотеза — что может помочь получить нужный результат. Если обновить сайт визуально и технически — это повысит конверсию в покупку и увеличит прибыль.
• Решение — что конкретно будем делать. Редизайн интернет-магазина: оптимизация кода, новый дизайн, автоматизация процессов.

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

Например, в проекте Freedom Football Manager сначала хотели сделать мобильную версию сайта — чтобы игроки и тренеры оперативно заполняли отчёты прямо на поле. Но мы прикинули: долго и дорого. И предложили другой путь — Telegram-бот. Проектируем интерфейс, разработка быстрее, потому что фронтенд не нужен. Цель та же, решение — проще.

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

Например, новая мультикорзина поможет клиентам «Новации» быстрее оформить заявку, получить и согласовать смету на десятки или сотни товарных позиций. Она же поможет менеджерам сократить время на подготовку коммерческих предложений.

Ожидаемый результат — то, как клиент видит итог работы. Это может быть MVP, UX/UI-аудит, редизайн каталога или что-то ещё — главное, сформулировать общее представление. Также важно заранее договориться с заказчиком, как поймём, что цель достигнута. Например, если делаем редизайн — на что именно он должен повлиять: рост конверсии, больше регистраций или снижение времени на покупку.

В понимании задачи клиента мы также фиксируем: кто целевая аудитория (кто будет пользоваться продуктом), конкурентов, метрики, референсы — проекты, на которые бизнес хочет равняться по стилю или структуре.

Ниже покажем, какие ещё блоки обычно включаем в ПЗ.

Хорошее ПЗ: как понять, что вы всё сделали правильно

Со структурой разобрались. Теперь — общие принципы: каким должно быть хорошее ПЗ. Понимание задачи всегда:

• Ясное и понятное — без расплывчатых формулировок и двусмысленностей. Чтобы и клиент, и дизайнер, и бэкендер понимали, о чём речь. С одной стороны, «удобный интерфейс», а с другой — «настройки проекта можно редактировать со смартфона».
• Конкретное и измеримое — с чёткими целями и понятными критериями успеха. Например, не «улучшить сайт», а «сократить путь до оформления заказа до 3 кликов».
• Реалистичное — с задачами, которые действительно можно реализовать в срок, с учётом бюджета, команды и стартовых условий. Не «создать нейросеть, которая заменит отдел продаж», если в проекте два разработчика и неделя на реализацию. А, например, «сделать лендинг с формой запроса, который передаёт заявки в CRM и дублирует в Telegram-бота».
• Согласованное — чтобы цели, гипотезы и решения не противоречили друг другу. Если хотим запуститься быстро — не предлагаем разработку платформы с нуля.
• Актуальное — значит, соответствует текущим целям и ситуации проекта. Если стратегия изменилась, а в ПЗ остались старые задачи, оно уже не работает. Например, раньше фокус был на зарубежный рынок, а теперь из-за санкций на внутренний — и всё в проекте нужно пересмотреть.

Когда вы приносите клиенту такое понимание задачи, он может сказать: «Да, вот это вы точно подметили — забыл об этом упомянуть» или «Нет, на эту аудиторию мы больше не ориентируемся, теперь хотим привлекать другую». Это нормально. Дополнение и корректировка ПЗ — часть его создания. Документ помогает свериться и скорректировать курс до старта, а не в середине проекта.

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

Виктор Тимофеев

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

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

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

Расскажите нам о своём проекте и получите понимание задачи.