За восемь лет разработки я видел десятки способов, которыми заказчики формулируют задачи - от голосового сообщения на сорок секунд до подробного ТЗ на три страницы с макетами. Как ставить задачи разработчику так, чтобы результат совпал с ожиданием с первого раза, а не после третьей итерации правок - вопрос, который экономит деньги и нервы обеим сторонам. Разница между «сделай кнопку красивее» и «увеличь кнопку добавления в корзину до 48px по высоте, замени цвет на #FF6B35 как в логотипе» - это разница между часом работы и днём переписки в мессенджере.
Почему нечёткая формулировка обходится дороже доработки
Когда задача описана в одно предложение без контекста, разработчик достраивает недостающие детали своим воображением. Иногда угадывает, чаще нет. Я делал бота на aiogram для доставки цветов, где заказчик написал «нужен бот для приёма заказов» - я собрал стандартную воронку с корзиной и оплатой, а оказалось, что заказы принимают только на конкретные даты и с привязкой к флористу. Переделка логики заняла почти столько же времени, сколько первая версия.
По моим наблюдениям, доработка после нечёткой постановки в среднем занимает в полтора-два раза больше времени, чем заняла бы работа при точном ТЗ с самого начала - потому что приходится не только дописывать, но и разбирать уже готовый код, чтобы понять, что можно оставить, а что переписать с нуля. При почасовой оплате это прямые лишние расходы, при фиксированной цене за проект - испорченные сроки и нервы с обеих сторон.
Из чего состоит рабочая постановка задачи для разработчика
Хорошая формулировка задачи закрывает пять вопросов ещё до того, как разработчик открыл редактор кода:
- Зачем это нужно - какую проблему решает задача, а не только что нужно сделать
- Текущее состояние - что уже есть, на чём строится доработка (ссылка на сайт, репозиторий, скриншот админки)
- Критерии приёмки - по каким признакам понятно, что задача выполнена
- Ограничения - бюджет, срок, технологии, с которыми должно быть совместимо решение
- Примеры и референсы - как выглядит похожее решение у других, если оно есть
Формулируйте результат, а не решение
Заказчики часто предлагают готовое техническое решение вместо описания проблемы: «добавь всплывающее окно с формой». А на деле цель - собрать телефон посетителя, который уходит со страницы. Всплывающее окно - только один из способов. Иногда более уместна форма в шапке или чат-виджет. Когда я получаю формулировку через цель, а не через готовый рецепт, часто получается предложить решение быстрее и дешевле того, что заказчик придумал сам.
Прикладывайте примеры и референсы
Одна ссылка на сайт конкурента с пометкой «вот так должен работать калькулятор доставки» экономит полчаса переписки. Когда делал интеграцию с СДЭК на Tilda, заказчик прислал скрин чужого сайта с расчётом стоимости по индексу - сразу стало понятно, какие поля нужны в форме и какой формат ответа ожидается на фронте.
Примеры удачных формулировок задач
Вот как выглядит разница между плохой и рабочей постановкой на реальных типах задач, с которыми я работаю чаще всего.
| Плохая формулировка | Чего не хватает | Рабочая формулировка |
|---|---|---|
| «Нужен бот для заказов» | Нет сценария, шагов, интеграций | «Бот на aiogram: /start - меню из 3 кнопок (Каталог, Мой заказ, Поддержка). Каталог подтягивается из Google Таблицы по расписанию раз в час. Оплата - через ЮKassa, после оплаты статус меняется в таблице» |
| «Интегрируй СДЭК, разберёшься» | Не указано, что именно нужно: расчёт стоимости, трек-номер, личный кабинет | «На странице оформления заказа - расчёт стоимости доставки СДЭК по индексу получателя через виджет, после оплаты автоматически создаётся заказ в личном кабинете СДЭК и трек-номер уходит клиенту на почту» |
| «Сделай сайт красивее» | Нет критериев «красиво», нет референсов | «Обнови главную страницу по референсу [ссылка], сохрани текущую структуру блоков, поменяй шрифт на Inter, добавь анимацию появления карточек при скролле» |
| «Почини баг с оплатой» | Нет шагов воспроизведения и ожидаемого поведения | «При оплате картой через Т‑Банк в WooCommerce у части заказов статус остаётся «Ожидает оплаты», хотя деньги списаны - воспроизводится на заказах дороже 15 000 ₽, нужно разобраться и починить webhook» |
Во всех рабочих формулировках справа - конкретика: числа, названия сервисов, ожидаемое поведение системы. Разработчик тратит время на код, а не на угадывание.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Провальные формулировки: разбор реальных случаев
Чаще всего проблемы возникают не из злого умысла, а из того, что заказчик сам ещё не до конца понимает, чего хочет. «Сделай бота как у конкурента» - я такое слышу регулярно. У конкурента может быть десяток скрытых сценариев: рассылки, реферальная программа, интеграция с CRM. Без доступа к его боту и без описания конкретных функций разработчик либо переспрашивает несколько раз, либо делает по своему усмотрению - и не угадывает.
Ещё один частый случай - задача через отрицание: «не хочу, чтобы было как у все». Это не постановка задачи, а эмоция. Полезно превращать такие фразы в конкретику вопросом «а как именно должно быть по-другому» - и фиксировать ответ письменно, а не держать в голове.
Отдельно упомяну задачи «на слух» - голосовые сообщения на минуту-полторы без письменного резюме. Проблема не в формате, а в том, что важные детали (число, дата, название сервиса) на слух легко упускаются и с той, и с другой стороны. Если ставите задачу голосом, продублируйте ключевые цифры и названия текстом следом.
Как ставить задачи в разных каналах связи
Таск-трекер (Jira, Trello, Notion)
Лучший вариант для задач длиннее одного дня работы. В карточке фиксируется контекст, критерии приёмки, вложения - и не теряется в ленте переписки через неделю. Для небольших правок на Tilda или WordPress хватает пары абзацев с пунктами и скриншотом. Готовые примеры оформленных задач и результата по ним можно посмотреть в библиотеке готовых скриптов - там видно, как формулировка превращается в рабочий код.
Мессенджер (Telegram, WhatsApp)
Удобен для быстрых правок и уточнений по уже согласованной задаче, но плохо подходит для постановки новой большой задачи - сообщения теряются в потоке, сложно сослаться на «то самое сообщение от вторника». Если ставите задачу в чат, оформляйте её отдельным сообщением с заголовком и списком пунктов, а не растягивайте на пять реплик подряд.
Голосовое сообщение и созвон
Хорошо работают для обсуждения идеи и контекста, плохо - как единственный источник технических деталей. После созвона отправляю заказчику короткое резюме письменно: что понял, что буду делать, какие вопросы остались открытыми. Это занимает пять минут и снимает большую часть недопониманий на старте.
Что делать, если задача меняется по ходу работы
Задача редко остаётся неизменной от начала до конца, особенно в проектах вроде автоматизации в n8n или доработки CRM - по мере работы всплывают детали, которые не были очевидны на старте. Это нормально, но важно фиксировать изменения так же письменно, как и исходную задачу, а не молча менять требования в переписке.
Я фиксирую любое новое требование отдельным пунктом с пометкой, входит оно в исходную оценку или нет. Если правка меняет объём работы - например, вместо простой доработки скрипта на Tilda (от 3 000 ₽) заказчик просит добавить полноценную интеграцию с эквайрингом и складским учётом (это уже комплексная интеграция от 40 000 ₽) - я сразу проговариваю новую оценку, а не подстраиваю её задним числом. Для задач, где заранее сложно оценить объём - например, сложная логика бота или нестандартная автоматизация в n8n - есть смысл начать с короткой консультации, чтобы разбить работу на этапы и заранее понять реальную стоимость.
Разобраться перед стартом
Консультация
от 3 000 ₽
Подробнее →Частые вопросы
Нужно ли писать техническое задание для маленькой доработки на сайте?
Полноценное ТЗ на страницу с диаграммами - нет, но пара абзацев с описанием, что должно измениться, и скриншот текущего состояния экономят время обеим сторонам. Для доработки на Tilda или WordPress этого обычно достаточно, чтобы разработчик не угадывал детали.
Как ставить задачу, если сам не разбираюсь в технологиях?
Описывайте результат и контекст своими словами, а не пытайтесь угадать техническую формулировку - «на сайте должна появиться корзина, которая считает скидку от суммы заказа» понятнее любого набора терминов, вставленных не к месту. Разработчик сам переведёт это в техническую задачу и уточнит детали вопросами.
Что делать, если разработчик сделал не то, что я имел в виду?
Сначала стоит проверить, было ли зафиксировано письменно то, что вы имели в виду, или всё держалось в голове и обсуждалось устно. Если формулировка была письменной и конкретной, а результат ей не соответствует - это повод для правок за счёт исполнителя. Если задача была расплывчатой, разумнее договориться о доработке как о дополнительном этапе с новой чёткой формулировкой.
Сколько времени в среднем занимает нормальная постановка задачи?
На задачу среднего объёма - доработку скрипта, простую интеграцию, бота - обычно хватает 15-20 минут на то, чтобы структурированно описать цель, контекст и критерии приёмки. Это в разы меньше, чем время на переписку и переделки, если задача поставлена в одно расплывчатое предложение.