Как поставить задачу программисту, чтобы оценка совпала с итоговым счётом, а результат — с ожиданиями? Описать не «что сделать», а «зачем и как этим будут пользоваться»: цель, сценарий пользователя, макет или эскиз, откуда берутся данные, по каким признакам вы примете работу и что трогать нельзя. На такую постановку уходит час, а при доработке сайта она экономит недели переделок. Ниже — шаблон из семи блоков, пример техзадания на доработку и разбор типичных ошибок.
- Задача начинается с цели в цифрах или действиях, а не с названия функции.
- Сценарий пользователя по шагам важнее списка полей и кнопок.
- Критерии приёмки пишутся до разработки — по ним потом и принимают работу.
- Если функция сложная, дешевле показать её прототипом, чем описывать текстом.
Почему «сделайте фильтр как у конкурента» не работает
Короткая постановка оставляет программисту десятки решений, которые он примет сам. Какие характеристики попадут в фильтр? Что показывать, если ничего не найдено? Должен ли фильтр работать на телефоне так же, как на компьютере? Каждое такое решение — развилка, и если программист выбрал не тот вариант, переделка оплачивается заново.
Есть и вторая проблема: по неполному описанию нельзя точно оценить работу. Исполнитель либо закладывает запас на неизвестность, и оценка выходит дороже, либо считает по минимуму, и потом счёт растёт. Поэтому хорошая постановка задачи выгодна в первую очередь заказчику. О том, как программисты превращают задачу в часы и деньги, мы подробно писали в статье «Сколько стоит доработка сайта».
Шаблон постановки задачи разработчику: 7 блоков
- ЦельЗачем нужна доработка и как вы поймёте, что она работает: меньше звонков с вопросом о цене, больше заявок из каталога, менеджеры перестают вручную пересчитывать доставку.
- Кто пользуетсяПокупатель, оптовый клиент, менеджер, контент-менеджер. У каждого свой сценарий и свои права.
- Сценарий по шагамЧто делает пользователь и что в ответ делает сайт — от входа на страницу до результата.
- Макет или эскизХотя бы схема от руки или скриншот похожего решения с пометками. Для сложных функций — кликабельный прототип.
- ДанныеОткуда берутся и куда уходят: из админки, 1С, CRM, файла Excel. Кто их обновляет и как часто.
- Критерии приёмкиКонкретные проверки, по которым задача считается сделанной.
- ОграниченияЧто нельзя менять, к какому сроку нужно, на каких устройствах и браузерах должно работать, какие языковые версии затрагивает.
Пример ТЗ на доработку: плохо и хорошо
Возьмём частую задачу — калькулятор стоимости доставки на странице товара.
- «Нужен калькулятор доставки в карточке товара».
- «Чтобы считал по городам Казахстана».
- «Красиво, как на сайте конкурента».
- «Срочно».
- Цель: покупатели из регионов перестают звонить с вопросом о доставке, цена видна до корзины.
- Сценарий: покупатель открывает карточку, выбирает город из списка, видит стоимость и срок двух служб доставки.
- Данные: вес и габариты из 1С, тарифы — из API службы доставки, для Алматы — фиксированная курьерская ставка из админки.
- Приёмка: для 5 тестовых товаров и 3 городов цена совпадает с калькулятором службы, на iPhone и Android блок не ломает карточку.
- Ограничения: не менять текущее оформление заказа, работать на RU- и KZ-версиях.
Вторая постановка длиннее всего на несколько строк, но программист по ней сразу видит объём работы: интеграция с API службы доставки, данные из 1С, отдельная логика для одного города, две языковые версии. Оценка получится точной, а сюрпризов на приёмке не будет.
Одна задача — одна цель
Частая ловушка — собирать в одну постановку всё, что накопилось: «добавить калькулятор, а заодно поменять шапку, поправить форму в контактах и подключить новый способ оплаты». Такую задачу трудно оценить, невозможно принять по частям, и если одна из правок застрянет на согласовании, встанут все остальные.
Делите крупные пожелания на самостоятельные задачи, у каждой из которых своя цель и свои критерии приёмки. Мелкие правки удобно собирать в отдельный список и отдавать пакетом, а новую функцию — описывать отдельно и подробно. Так проще расставить приоритеты: что даст результат в этом месяце, а что может подождать. Бонус для бюджета — вы видите стоимость каждой задачи и можете отказаться от тех, которые не окупаются.
Как писать сценарий пользователя
Сценарий — это история в шагах «пользователь делает — система отвечает». Пишите его глазами клиента, а не программиста, и не забывайте об отклонениях: что если поле не заполнено, товара нет в наличии, город не найден, оплата не прошла.
Основной путь
Например: «Оптовый клиент входит в личный кабинет. Видит свои цены. Загружает файл Excel с артикулами и количеством. Сайт показывает, какие позиции найдены и сколько их на складе. Клиент нажимает “Оформить”, заказ уходит в 1С, менеджер получает задачу в CRM».
Альтернативные ветки
«Если артикул не найден — строка подсвечивается, клиент может её удалить или исправить. Если остатка не хватает — показываем доступное количество и предлагаем оформить остаток под заказ». Именно в ветках прячется большая часть работы, и именно их чаще всего забывают описать.
Описывать интерфейс вместо поведения: «добавить кнопку справа, синюю, с иконкой». Расположение и цвет дизайнер подберёт в стиле сайта. Программисту важнее знать, что происходит после нажатия и в каких случаях кнопка недоступна.
Критерии приёмки: как их сформулировать
Критерий приёмки — проверяемое утверждение, на которое можно ответить «да» или «нет». «Удобный фильтр» — не критерий. «Фильтр по цене, бренду и наличию; результаты обновляются без перезагрузки страницы; на телефоне фильтр открывается отдельной панелью; при пустом результате показывается сообщение и кнопка сброса» — критерии.
- Пишите критерии до начала разработки и согласуйте их с исполнителем.
- Включайте мобильную версию и нужные браузеры явно — иначе их проверят по остаточному принципу.
- Добавляйте проверку того, что не должно сломаться: корзина, оформление, обмен с 1С.
- Указывайте тестовые данные: конкретные товары, города, суммы.
ПРАВИЛОЕсли вы не знаете, как будете принимать задачу, программист не знает, что делать.
Когда вместо текста нужен прототип
Текстом хорошо описываются простые функции: новое поле в форме, раздел, блок на странице. Личный кабинет, многошаговый калькулятор, бронирование или B2B-раздел текстом описать сложно: десятки экранов, ролей и состояний, и каждый читатель представит их по-своему. Здесь дешевле сначала собрать кликабельный прототип и проверить его на пользователях.
Прототипирование интерфейсов занимает 1–2 недели: карта экранов, кликабельный прототип в Figma, UX-тест на 5–8 пользователях и описание логики и состояний для разработки. Для сайта — от 250 000 ₸. Главная выгода — точная смета: разработчики оценивают по прототипу, а не по пересказу задачи, а правка в прототипе стоит часа работы вместо недели в коде. Чем прототип отличается от макета, мы объясняли в статье «Вайрфрейм, прототип и макет».
Как мы работаем с вашей постановкой
Идеальное ТЗ от заказчика не требуется — на это есть этап проектирования. В рамках доработки сайта и разработки нового функционала мы сначала за 1 день смотрим код и задачу и присылаем смету по задаче, а не вилку «от и до». Затем 2–3 дня проектируем: описываем сценарий, данные и рисуем прототип интерфейса. Разработку начинаем только после того, как вы согласовали прототип.
Ваша постановка по шаблону сокращает этот путь: часть вопросов уже закрыта, оценка точнее с первого раза. Ориентиры по стоимости — функция от 80 000 ₸ и 1–2 недели, модуль от 350 000 ₸ и 3–4 недели, крупная доработка от 900 000 ₸ и 5–6 недель.
Пришлите задачу в свободной форме или по шаблону — оценим по коду за 1 день и предложим, как упростить первую версию.
Оценить доработкуЧек-лист перед отправкой задачи
- Указана цель и как измерить результат.
- Перечислены пользователи и их роли.
- Описан основной сценарий по шагам.
- Описаны альтернативные ветки: ошибки, пустые результаты, отсутствие данных.
- Приложен эскиз, скриншот-пример или прототип.
- Понятно, откуда берутся данные и куда уходят.
- Сформулированы проверяемые критерии приёмки с тестовыми данными.
- Указаны ограничения: срок, устройства, языковые версии, что нельзя трогать.
- Назначен один человек, который отвечает на вопросы и принимает работу.
Сохраните шаблон и используйте его для каждой новой задачи, даже маленькой. Через месяц у вас будет архив постановок, по которому легко понять, что и зачем менялось на сайте, — это пригодится и при смене подрядчика.
Нужно ли техническое задание на доработку сайта?
Подробное ТЗ на десятки страниц — нет. Нужна постановка по шаблону: цель, сценарий, данные, критерии приёмки и ограничения. Остальное уточняется на проектировании.
Кто должен писать ТЗ — заказчик или разработчик?
Заказчик описывает цель, сценарий и критерии приёмки, разработчик дополняет техническими деталями и прототипом. Итоговый документ согласуют обе стороны.
Что делать, если не знаю, как должна выглядеть функция?
Опишите задачу бизнеса и сценарий, приложите примеры с других сайтов. Интерфейс предложит дизайнер, а для сложных функций лучше заказать прототип.
Почему оценка по одной и той же задаче у разных подрядчиков отличается?
Каждый по-своему достраивает недостающие детали. Чем подробнее сценарий и критерии приёмки, тем ближе оценки и тем меньше сюрпризов в счёте.
