Расплывчатая постановка задачи редко выглядит опасной в моменте. Обычно она кажется просто «быстрой»: написал в чат, созвонился на ходу, переслал кусок контекста — и работа как будто пошла. Но потом начинаются уточнения, сдвиги, лишние согласования и переделки, потому что разные люди изначально поняли задачу по-разному.
Проблема не в том, что команда «не умеет читать мысли» и не в том, что всем срочно нужен очередной универсальный фреймворк. Чаще всего потери возникают в точке передачи работы: постановщик знает, что хочет получить, но описывает не результат, а действие. Исполнитель видит формулировку, но не видит замысел, ограничения и критерии, по которым работу будут принимать.
Почему хорошие специалисты все равно получают плохие задачи
Во многих командах задача начинается с формулировок вроде «поправить форму», «сделать баннер», «подготовить рассылку», «обновить страницу». Это описание активности, а не ожидаемого выхода. В такой записи есть глагол, но нет ответа на главный вопрос: что должно измениться в результате этой работы и как мы поймем, что задача решена.
Дальше включается вторая типичная проблема: важная часть контекста остается в голове у постановщика. Он знает, что форма ломается только на мобильных, что баннер нужен под конкретную акцию, что рассылка идет по холодной базе, а страницу нельзя менять из-за зависимости от другого релиза. Но в саму задачу это не попадает, потому что «это и так понятно». На практике понятно это только автору.
Отсюда появляется ложная экономия времени. Кажется, что быстрее поставить задачу коротко и договорить детали потом. Но «потом» обычно наступает в самый дорогой момент: когда исполнитель уже начал работу, выбрал решение, потратил часы и теперь выясняет, что ожидание было другим.
Отдельный источник потерь — разные словари между отделами. Для маркетинга «срочно сделать баннер» может означать макет для запуска кампании сегодня до 16:00. Для дизайнера это может означать, что нужен один визуал в произвольном формате. Для performance-команды баннер без размеров, площадки и цели вообще не является поставленной задачей. Формально все используют одни и те же слова, но вкладывают в них разный смысл.
Еще одна причина — смешение проблемы и решения. Вместо «падает конверсия на шаге отправки формы, нужно убрать барьер в сценарии мобильных пользователей» в задачу попадает «добавить еще одно поле» или «переделать форму». Исполнитель получает уже чье-то предположение о решении, хотя исходная проблема не зафиксирована. В результате команда может качественно выполнить не ту работу.
Как это выглядит в реальной работе
У разработчика в бэклоге появляется задача: «поправить форму заявки». Без сценария ошибки, без окружения, без описания ожидаемого поведения. Разработчик находит визуальный дефект, чинит его и отдает в тест. Потом выясняется, что проблема была не во внешнем виде, а в том, что форма не отправляется на iOS при определенной маске телефона.
Дизайнер получает сообщение: «Нужен баннер срочно, сегодня». Он делает аккуратный визуал в стандартном размере. Через пару часов приходит обратная связь: нужен был не один баннер, а набор под три площадки, с ограничением по весу файла, с юридическим дисклеймером и под конкретный CTA. Срок тот же, работа начинается заново.
В операционной команде задача передается устно: «Подключите нового подрядчика на этой неделе». Не указан ответственный согласующий, нет дедлайна на отдельные этапы, не зафиксирован список документов. Исполнитель делает свою часть, затем задача зависает между юристами, финансами и закупками, потому что никто заранее не описал зависимости.
Во всех трех примерах причина одна и та же: работа была передана как намерение, а не как управляемый результат.
Что менять в постановке задачи
Хорошая постановка начинается не с объема текста, а с правильной структуры мысли. В задаче полезно зафиксировать не все подряд, а тот минимум, без которого другой человек не сможет воспроизвести ваше ожидание.
Описывать выход, а не действие
Вместо «сделать баннер» лучше писать, какой артефакт должен появиться на выходе, для чего он нужен и в каком виде его будут использовать. В разработке вместо «поправить форму» — какое поведение считается корректным и в каком сценарии.
Это снижает риск, что исполнитель выберет локально разумное, но неверное решение.
Выносить контекст из головы в задачу
Если на результат влияют аудитория, канал, ограничения релиза, приоритет клиента, прошлые ошибки или внешние зависимости, это нужно фиксировать явно. Не в длинном эссе, а коротко и предметно.
Полезный минимум контекста обычно включает:
зачем возникла задача;
где именно проявляется проблема;
что уже известно или проверено;
какие ограничения нельзя нарушать;
от кого зависит приемка.
В командах, где такие вводные часто теряются между функциями, полезно заранее разделять поток работ по направлениям. Например, в Scorework можно вести задачи по work areas — дизайн, разработка, маркетинг, операции. Это не заменяет хорошую формулировку, но помогает сразу видеть, для какого типа работы ставится задача и какой контекст для нее критичен. За счет этого меньше шансов, что запрос «срочно сделать баннер» попадет в работу без размеров, площадок и условий использования, а задача на разработку — без сценария ошибки и окружения.
Отделять проблему от предполагаемого решения
Когда постановщик сразу диктует способ выполнения, команда теряет шанс выбрать лучшее решение. Если вы уверены в конкретном подходе, это можно указать как гипотезу или ограничение, но сначала стоит зафиксировать саму проблему.
Формулировка «нужно добавить поле» хуже, чем «нужно снизить число некорректных заявок; если нет более простого способа, рассматриваем дополнительное поле как один из вариантов».
Добавлять критерии готовности
Критерии приемки — это не бюрократия, а способ синхронизировать ожидания до начала работы. Они отвечают на вопрос, что именно должен увидеть заказчик на выходе.
Для разных типов задач это может быть разное:
для дизайна — форматы, размеры, носители, версия текста, исходники;
для разработки — сценарий, в котором ошибка устранена, окружение, условия проверки;
для операций — этапы, документы, согласующие, крайний срок по каждой точке.
Если критерии не названы, команда почти всегда подставит свои.
Использовать короткий шаблон для повторяемых задач
Не нужен тяжелый регламент на каждую мелочь. Но для типовых запросов полезен короткий шаблон в единой системе или рабочем контуре: результат, контекст, ограничения, срок, ответственный за приемку. Один и тот же каркас экономит время именно потому, что уменьшает число забытых вводных.
Шаблон особенно полезен на стыке функций, где чаще всего теряется смысл: маркетинг — дизайн, продукт — разработка, аккаунтинг — операционная команда.
Если команда работает в системе, где задача дополнительно связывается с оценкой по времени, это тоже дисциплинирует постановку. В Scorework оценка нужна не для давления на исполнителя, а для более честного планирования: чтобы перед стартом стало ясно, что именно мы просим сделать, какого это объема и насколько запрос вообще оформлен. Когда задачу невозможно даже примерно оценить, это часто хороший сигнал, что в ней не хватает результата, контекста или критериев готовности.
Проверять задачу до передачи одним вопросом
Простая проверка звучит так: что именно должен увидеть заказчик на выходе, чтобы сказать «да, это сделано правильно».
Если на этот вопрос нельзя ответить одной-двумя конкретными фразами, задача еще не поставлена. Она только инициирована.
Быстрая диагностика: где именно ломается постановка
Сигнал | Что это значит | Что делать |
|---|---|---|
Много уточнений после старта | Контекст не зафиксирован | Добавить исходные вводные в задачу |
Работа «не та, но качественная» | Описано действие, не результат | Переписать задачу через ожидаемый выход |
Срок есть, приемки нет | Срочность заменила ясность | Указать критерии готовности |
Задача зависает между людьми | Не видны зависимости и согласующие | Зафиксировать участников и этапы |
Одни и те же ошибки повторяются | Нет стандартного шаблона | Ввести короткий формат для типовых задач |
Дополнительно можно пройтись по короткому чек-листу перед передачей работы:
понятен ли ожидаемый результат, а не только действие;
есть ли контекст, без которого задачу поймут двояко;
указаны ли ограничения и зависимости;
ясно ли, кто принимает результат;
можно ли проверить готовность без устных пояснений автора.
Что меняется, когда задача поставлена правильно
Качественная постановка не делает процесс медленнее. Она переносит обсуждение в начало, когда изменения дешевы, и убирает лишние петли согласования потом. Команда меньше дергает постановщика, реже уходит в неверную реализацию и быстрее доводит работу до принятого результата.
Важно и другое: хорошая задача не обязана быть длинной. Она должна быть однозначной для человека, который не сидит у вас в голове. Если в команде регулярно появляются переделки, спор о том, «что имелось в виду», и зависания на приемке, проблема обычно не в дисциплине исполнителей, а в качестве передачи работы.
Правильная постановка — это не про красивую формулировку. Это про снижение потерь между намерением и результатом. А чтобы эти потери было видно не только по ощущениям, но и по факту, полезно смотреть на повторяющиеся отклонения после выполнения задач. Например, в Scorework сравнение plan vs actual помогает заметить, какие типы работ команда регулярно недооценивает или недоописывает на входе. Это дает повод не обвинять исполнителей, а улучшать саму постановку: где не хватает контекста, где критерии приемки слишком размыты, а где запросы из одних функций в другие стабильно приходят в полуготовом виде.
Слабая постановка кажется экономией только до первого круга переделок. Сильная — не требует длинных брифов на каждую мелочь, но отвечает на базовые вопросы: какой нужен результат, в каком контексте он делается, что ограничивает работу и по каким признакам ее примут. Именно эта ясность обычно и отделяет «быстро передали» от «действительно довели до нужного результата».
