Как описать задачу, чтобы вас поняли

Представьте, что вы написали трём студиям одну фразу: «Нужна CRM для отдела продаж». Одна поймёт это как список клиентов с напоминаниями, вторая — как воронку сделок с отчётами, третья — как систему с телефонией, ролями и интеграцией с 1С. Каждая назовёт честную цену — за свой продукт. Сравнивать эти сметы нельзя: вы сравниваете три разные вещи, а выбираете по цене и обаянию менеджера.

Механика простая. Любая неясность в описании подрядчик вынужден закрыть одним из двух способов:

• заложить запас в цену — «если окажется сложнее, мы должны это покрыть»;
• промолчать и вернуться к вопросу после старта — тогда он появится как «дополнительная работа» с отдельной стоимостью.

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

Это не соперники, а два этапа. Бриф фиксирует суть и границы, ТЗ раскрывает детали, когда подрядчик выбран или когда проект сложный.

Структуру полного ТЗ из семи блоков мы разобрали в статье «Как составить ТЗ на разработку». Здесь — практика: как уместить главное на одной странице и не оставить дыр.

Скопируйте список и заполните каждый пункт одним-тремя предложениями. Пустой пункт — это не пропуск, а вопрос к вам самому.

1. 1.Цель и метрика. Какую проблему решаем, какое число должно измениться и от какого значения. Берите из «паспорта проблемы» первого урока.
2. 2.Пользователи. Кто будет работать с продуктом, на каком устройстве, как часто, какой у них опыт. Отдельной строкой — кто принимает решения у вас.
3. 3.Сценарии. Три-пять главных путей пользователя по шагам: «менеджер получает заявку — назначает ответственного — фиксирует результат звонка».
4. 4.Критерии готовности. Для каждого сценария: как мы проверим, что он работает (подробнее ниже).
5. 5.Роли и права. Кто что видит и меняет. Даже набросок «директор видит всё, менеджер — только свои сделки» избавляет от скрытой сложности.
6. 6.Данные и интеграции. Откуда берутся данные, с какими системами обмен, какая из них главная по каждому виду данных. Если есть 1С, Kaspi или платёжные сервисы, дополните бриф по статье «Бриф на интеграцию».
7. 7.Ограничения. Бюджетный потолок, желаемая дата и её причина, обязательные требования (хранение данных, отраслевые правила), технологии, которые нельзя менять, и риски, о которых вы знаете.
8. 8.Вне рамок и открытые вопросы. Что в первую версию точно не войдёт и что вы пока не решили. Эта строка защищает бюджет сильнее всех остальных.

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

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

Обратите внимание на три вещи. У цели есть число и способ его замерить. Критерии проверяются без толкований. А последняя строка прямо говорит, что в версию не войдёт, и называет, что ещё не решено, — подрядчик видит границы и не закладывает запас «на всё сразу».

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

Сравните:

Допустимые значения (секунды, количество полей, интервал синхронизации) должны назвать вы, исходя из работы людей, а не подрядчик. Если не знаете числа, договоритесь замерить текущий процесс.

• Описание интерфейса вместо задачи. «Кнопка слева, красная» — это решение. Опишите, что человек должен успеть сделать.
• Все функции на одном уровне. Разметьте «обязательно в первой версии», «желательно», «потом». Без приоритетов оценка раздувается.
• Забытые пользователи. Администратор, бухгалтер и служба поддержки тоже пользуются продуктом, хотя редко попадают в первую версию описания.
• Нет владельца решений. Если бриф согласуют пять человек и никто не отвечает за итог, на каждой итерации появятся новые требования.
• Скопированный чужой бриф. Он описывает чужой процесс.

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

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