Как поставить задачу разработчику, если вы не технарь: ТЗ на одной странице

Игорь, основатель Diaverse · 8 октября 2026 · 15 минут чтения

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

Почему короткое ТЗ и «сделайте как у X» заканчиваются словами «сделали не то»?

Главное: всё, чего нет в задаче, исполнитель додумывает сам. Чем короче описание, тем больше он додумал и тем дальше результат от картинки в вашей голове.

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

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

Двадцать слов — это двадцать пробелов

«Нужен интернет-магазин одежды с личным кабинетом и доставкой» — для вас понятная фраза. Для разработчика в ней десятки непринятых решений. Кто загружает товары? Что происходит, если оплата не прошла? Что лежит в личном кабинете? Кто считает стоимость доставки?

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

Что не так с «как у X»

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

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

1. Проверьте готовые решенияодин вечер: возможно, разработка не нужна
2. Опишите задачу на одной страницечас-два, без технических слов
3. Попросите исполнителя пересказать задачу и задать вопросыпо ответу видно, понял ли он её
4. Записывайте итог каждого созвона10 минут в тот же день
5. Принимайте работу по критериям «готово»руками, на телефоне, по списку

Как понять, что хватит готового сервиса или конструктора?

Главное: если сценарий типовой — запись, магазин, лендинг, опрос, рассылка, — сначала потратьте вечер на готовые сервисы. Своя разработка оправдана, когда главный сценарий в готовое не помещается или именно он и есть ваше отличие.

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

Готового, скорее всего, хватит, если:

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

Своя разработка оправдана, если:

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

Проверка за вечер: пройдите главный сценарий (как его описать — ниже) в двух-трёх готовых сервисах на пробном периоде и отметьте шаг, где не получается. Проходит целиком — начните с готового. Ломается на одном-двух шагах — спросите исполнителя, нельзя ли доработать готовое вместо разработки с нуля. Вопрос «что здесь можно взять готовым, а что придётся писать?» стоит задать в любом случае. Если прототип уже собран в конструкторе или с ИИ, читайте статью про прототип с ИИ.

Что написать на одной странице?

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

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

1. Зачем. Какую проблему бизнеса решаем и как поймём, что получилось. Это главный блок: зная цель, исполнитель может предложить решение проще и дешевле вашего.
2. Кто пользователь. Кто, в какой ситуации и с какого устройства. Если ролей несколько — клиент, администратор, курьер, — опишите каждую.
3. Главный сценарий по шагам. Путь пользователя от входа до результата, 5–10 шагов.
4. Что входит в первую версию и что нет. Второй список, «не сейчас», важнее первого: на нём заканчиваются споры «а мы думали, это тоже будет».
5. Примеры и референсы — с пояснением, что именно в каждом нравится и что нет.
6. Ограничения. Бюджет (хотя бы вилка), срок и его причина, платформа (сайт, iOS и Android, Telegram), интеграции (оплата, CRM, учётная система), данные (откуда берутся, кто их меняет, есть ли персональные).
7. Что уже есть. Тексты, логотип, домен, старый сайт, таблицы, аккаунты.
8. Как поймём, что готово. 3–7 проверок, по которым вы примете работу.

Как описать референсы, чтобы «как у X» стало задачей

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

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

Как описать сценарий и критерии «готово» простыми словами?

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

Сценарий: шаги, а не кнопки

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

• Мест нет, товар закончился, время уже занято.
• Оплата не прошла или человек закрыл страницу на середине.
• Человек передумал и хочет отменить или изменить заказ.
• Что-то пошло не так — что в этот момент видит администратор?

Знать ответы не нужно, достаточно перечислить: хороший исполнитель предложит варианты, а вы выберете.

Критерии «готово»: то, что можно проверить руками

Удобная формула: «когда такой-то пользователь делает то-то, он видит или получает вот это». Хороший критерий проверяется на вашем телефоне без программиста, и о нём нельзя спорить: либо работает, либо нет.

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

«Удобно», «быстро», «современно» — не критерии: каждый понимает их по-своему. Переводите их в действие или число.

Какие вопросы должен задать хороший исполнитель?

Главное: вопросы исполнителя — бесплатная проверка и вашей задачи, и его самого. Хороший исполнитель спрашивает о бизнесе и пользователях раньше, чем о технологиях.

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

• Зачем это бизнесу и как вы поймёте, что получилось?
• Кто пользователи и как они решают эту задачу сейчас?
• Что должно произойти, если… — и дальше «что если», о которых вы не подумали.
• Что можно не делать в первой версии? Нельзя ли проверить идею проще?
• Что важнее, если не уложимся: срок, бюджет или объём?
• Кто будет менять тексты и цены после запуска?
• Сколько будет стоить содержание после запуска: сервер, платные сервисы?

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

Что значит, если вопросов нет

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

И не бойтесь отвечать «не знаю». Хороший исполнитель предложит варианты и объяснит, чем они отличаются по цене и срокам. Как ещё проверить исполнителя до оплаты — в статье как выбрать подрядчика для разработки.

Как не терять устные договорённости?

Главное: после каждого созвона в тот же день отправляйте короткий письменный итог. Чего нет в записи, того для исполнителя, по сути, нет, даже если он кивал.

Через месяц каждый помнит разговор по-своему, и спор «мы же это обсуждали» не выиграть: доказательств нет ни у кого. Итог — это 5–10 строк, а не протокол:

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

Последней строкой допишите: «Если я что-то записал не так, поправьте до завтрашнего вечера». Хорошо, если итог присылает сам исполнитель — так видно, как он понял разговор; если нет, пишите сами. Храните итоги в одном месте, например в конце той же страницы задачи, а не в трёх чатах и голосовых.

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

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

Частые ошибки

• Описывать решение вместо задачи: «нужно приложение с базой данных» вместо «клиенты должны записываться сами».
• Уместить в первую версию всё. Без списка «не сейчас» она растягивается на месяцы.
• «Как у X» без пояснений. Каждый поймёт по-своему.
• Слова-оценки вместо проверок: «удобно», «быстро», «современно».
• Скрывать бюджет. Без вилки исполнитель оценивает идеальную версию, а не решение под ваши рамки. На мой взгляд, честная вилка экономит время обеим сторонам.
• Менять задачу по ходу и не записывать, что это меняет в сроке и цене.
• Путать подробность с длиной. Сорок страниц общих слов хуже одной страницы с конкретным сценарием и критериями.

Что делать, если работа уже идёт, а задачи на бумаге нет?

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

1. Опишите задачу так, как понимаете её сегодня, по тому же шаблону.
2. Отправьте исполнителю с просьбой отметить, где он понимает иначе и что уже сделано.
3. Договоритесь о показе работающего результата хотя бы раз в неделю-две — по ссылке, на вашем телефоне, а не скриншотами и отчётами о часах.

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

Если исполнитель пропал или проект нужно передать другой команде, начните с доступов и копий — об этом статья что делать, если разработка дорогая или подрядчик пропал.

Чек-лист перед отправкой исполнителю

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

Читайте также

• Как выбрать подрядчика для разработки и не потерять предоплату — как проверить исполнителя до оплаты.
• Как принять работу у разработчика, если вы не разбираетесь в коде — что делать с критериями «готово» на сдаче.
• Сколько стоит разработка приложения и почему сметы отличаются в разы — почему одна и та же задача стоит по-разному.
• Словарь заказчика: MVP, ТЗ, деплой и другие слова простым языком