Бриф на разработку: что написать, чтобы получить диапазон, а не «зависит»

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

Дело не в длине. Дело в пяти вещах, которых во втором тексте просто не было.

Опишите задачу, а не формат

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

Из формата следует только вёрстка (и спор о том, какой оттенок зелёного правильный). Из задачи следует всё остальное, включая то, чего можно не делать. Для компании из Казани, которая занимается договорами водопользования, задача звучала как «принимать заявки в одном месте». Отсюда в проекте появились калькулятор аренды, две формы и автоматическая отправка заявок в таблицу и менеджерам в Telegram, а половина того, что обычно рисуют на таких сайтах, не появилась вообще.

Дайте сценарий одного человека вместо списка функций

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

Перечислите внешние системы

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

Назовите срок и причину срока

Полезен не сам дедлайн, а его причина. «Хотим побыстрее» не помогает никак. «Открываем офис 15 октября» или «сезон начинается в марте» сразу определяет, что мы режем, чтобы успеть, и что оставляем на потом. Если срок жёсткий, скажите сразу. Тогда разговор пойдёт о том, какая часть продукта должна работать к этой дате, вместо попыток уложить в неё всё.

Назовите рамку бюджета

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

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

Что в бриф писать не надо

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

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

Скопируйте этот шаблон

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

Этого хватает, чтобы получить диапазон и список допущений на первом разговоре.

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

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