Как поставить задачу, которую выполнят: техника для руководителя

Эта статья — часть цикла: Управление исполнением: полное руководство

TL;DR. Задача не выполняется не потому что сотрудник ленив, а потому что руководитель не дал достаточно контекста, критериев успеха и промежуточных точек контроля. Правильная постановка задачи — это навык, который снижает переделки на 60–80%. Проверьте зрелость вашей системы постановки задач с помощью бесплатной диагностики RuForge.

Руководитель ставит задачу. Сотрудник уходит её делать. Через неделю выясняется: результат не тот, сроки сорваны, нужно переделывать. Или хуже — сотрудник молча делает что-то другое, потому что не понял, а переспросить постеснялся. Знакомо? Дело почти никогда не в лени или некомпетентности — дело в самой постановке задачи. По данным исследований McKinsey, менеджеры тратят до 20% рабочего времени на прояснение задач и исправление последствий неверного их понимания. Разберём, как этот процент снизить.

Почему задачи не выполняются: 5 реальных причин

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

1. Размытый результат. «Сделай хороший отчёт» — это не задача, это пожелание. Что значит «хороший»? Для кого? В каком формате? На сколько страниц? Сотрудник угадывает — и угадывает неправильно. Руководитель считает, что всё очевидно, потому что картинка у него в голове уже есть. Сотруднику эта картинка недоступна.

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

3. Конкурирующие приоритеты. У сотрудника одновременно три «срочных» задачи от разных руководителей. Без явного приоритета он берётся за ту, которая проще, или за ту, от которой громче кричат. Это не выбор между хорошим и плохим — это выбор между двумя неудобными вариантами, и он делается без достаточной информации.

4. Ресурсы не выделены. Задача поставлена, но доступа к нужным данным нет, бюджет не согласован, смежный отдел не предупреждён. Сотрудник тратит половину времени на организационные вопросы и пробивание стен вместо выполнения работы. Руководитель воспринимает это как медлительность.

5. Нет точки проверки. Дедлайн — через две недели, промежуточных check-in нет. Сотрудник может двигаться в неверном направлении всё это время, и руководитель узнает об этом только в конце. К тому моменту переделывать поздно или дорого. Отсутствие промежуточных точек — это не доверие к сотруднику, это управленческая халатность.

SMART vs CLEAR: что работает сейчас

SMART (Specific, Measurable, Achievable, Relevant, Time-bound) — стандарт с 1981 года. Он до сих пор рабочий, но у него есть слепое пятно: он описывает задачу как статичный объект и игнорирует контекст взаимодействия между людьми и динамику изменений.

CLEAR появился как ответ на реалии современных команд, где задачи меняются быстрее, чем раньше:

• C — Collaborative (совместность). Задача учитывает, кто ещё вовлечён и как координируются усилия.
• L — Limited (ограниченная). Чёткие границы по времени и масштабу — без «заодно сделай ещё вот это».
• E — Emotional (эмоциональная). Сотрудник понимает, почему это важно для него, команды или клиента.
• A — Appreciable (разбиваемая). Большая задача делится на части, каждая из которых выполнима за один подход.
• R — Refinable (уточняемая). Задача может корректироваться по ходу при изменении условий — и это нормально, а не признак слабости планирования.

На практике лучший подход — гибридный. SMART закрывает техническую сторону (что, когда, как измерить), CLEAR добавляет человеческую (зачем, с кем, что делать, если что-то изменилось). Используйте оба фрейма как чеклист, а не как религию. Не каждая задача требует всех десяти элементов — небольшая задача на час не нуждается в двухстраничном ТЗ.

7 элементов правильной постановки задачи

Каждый из этих элементов отвечает на конкретный вопрос, который возникает у сотрудника. Пропустите один — получите либо переспросы в процессе, либо переделку в конце.

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

2. Результат. Конкретный, измеримый выход — что именно должно быть сделано. Не «проанализировать», а «подготовить таблицу с динамикой выручки по трём сегментам за 12 месяцев в формате Excel с итоговым слайдом для презентации».

3. Дедлайн. Не «к концу недели», а «в пятницу до 17:00». Если задача большая — промежуточные точки с конкретным временем. «Черновик — в среду до 12:00, финальная версия — в пятницу до 17:00». Время суток убирает разночтения.

4. Ресурсы. Что уже есть: доступы, данные, бюджет, помощь смежных команд. Если чего-то нет — укажите, как это получить и к кому обратиться. Это избавляет от ситуации, когда сотрудник тратит день на то, чтобы найти нужный контакт.

5. Приоритет. Явно скажите, на каком месте эта задача среди остальных в очереди. «Это приоритет №1 на эту неделю, остальное — в сторону» или «это можно делать в фоне между более срочными вещами». Без этого человек сам расставляет приоритеты — и часто не так, как вам нужно.

6. Обратная связь. Как и когда вы готовы отвечать на вопросы. «Пиши в Slack — отвечу в течение часа. Если что-то блокирует работу — звони сразу». Это снижает тревогу и устраняет ситуацию, когда сотрудник боится побеспокоить и молча зависает на одном месте несколько часов.

7. Автономия. Что сотрудник может решать сам, а что требует согласования с вами или другими. Это предотвращает как микроменеджмент, так и выход за рамки полномочий. «Структуру таблицы и источники выбираешь сам, но перед отправкой директорам — покажи мне финальную версию».

Плохая постановка vs хорошая: разбор примера

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

Элемент	Плохо	Хорошо
Результат	«Сделай анализ конкурентов»	«Таблица: 5 конкурентов × 6 параметров (цена, функционал, UX, ЦА, каналы продаж, отзывы). Формат — Google Sheets с вводным слайдом»
Контекст	Не указан	«Готовимся к запуску нового тарифа — нужно понять позиционирование и где у нас пробелы»
Дедлайн	«Срочно»	«Четверг, 15:00 — нужно до встречи с продуктом. Черновик покажи во вторник»
Ресурсы	Не указаны	«Доступ к SimilarWeb — у Антона, список конкурентов — в Notion (ссылка в задаче), бюджет на платные инструменты не нужен»
Приоритет	Не указан	«Приоритет №1 до среды, остальные задачи отложи»
Автономия	Не определена	«Структуру и источники выбираешь сам, финальный вывод согласуй со мной до отправки»

Разница очевидна. Первый вариант занимает пять секунд на прочтение и рождает три дня вопросов. Второй занимает минуту на написание и экономит значительно больше. Хорошо сформулированная задача — это и есть краткий менеджерский документ, только без лишней бюрократии.

Как убедиться, что задача понята: 3 приёма без микроменеджмента

Задача поставлена — но это не значит, что она понята так, как вы имели в виду. Проверить это можно, не превращаясь в контролёра над каждым шагом.

Приём 1: Попросите пересказать результат. Не задание целиком, а именно конечный результат своими словами. «Скажи мне: что ты сдашь в четверг?» Если ответ совпадает с вашим образом — всё нормально. Если нет — вы узнали об этом сейчас, а не в четверг. Этот приём работает даже с опытными сотрудниками, если подать его как уточнение, а не как экзамен.

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

Приём 3: Договоритесь о промежуточной точке. Не «проверяй меня каждый день», а одна конкретная точка: «Во вторник в 11:00 покажешь черновик — я скажу, в том ли направлении движешься». Это снижает тревогу у сотрудника и даёт вам возможность скорректировать курс до того, как потрачено всё отведённое время. Для задач длиннее трёх дней — минимум одна такая точка.

Частые ошибки при постановке задач

Задача через мессенджер в 23:00. Технически задача поставлена. Но сотрудник либо не читает до утра и нервничает из-за непрочитанного, либо читает и не может отключиться. Используйте отложенную отправку или трекер задач — и тогда задача появляется у человека в рабочее время.

Смешение задачи и способа её выполнения. «Сделай через Excel» вместо «подготовь таблицу для анализа». Когда вы диктуете инструмент или метод, вы забираете у человека возможность сделать лучше или быстрее. Ставьте задачу через ожидаемый результат, а не через процесс его достижения.

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

Изменение задачи на ходу без уведомления. Приоритеты поменялись — это нормально. Но сотрудник должен знать об этом явно и оперативно, иначе он продолжает делать то, что уже не нужно, и тратит своё время впустую.

Постановка задачи сразу нескольким людям без назначения ответственного. «Команда, нужно подготовить X» — все ждут, что сделает кто-то другой. Один ответственный, остальные — поддержка. Диффузия ответственности — один из самых надёжных способов не получить результат вовремя.

Кейс: ИТ-команда 15 человек, стандарт постановки задач

Продуктовая ИТ-компания, 15 человек в команде разработки. Проблема: около 30% задач возвращались на доработку — результат не совпадал с ожиданиями руководителя или внутреннего заказчика. Переделки съедали до 20% рабочего времени разработчиков каждый спринт.

Диагностика. Провели ретроспективу по 20 задачам, которые вернулись на переделку за последние два месяца. В 17 из 20 случаев не было зафиксированного критерия готовности (Definition of Done) на старте. В 12 случаях задача передавалась устно без записи в трекер.

Что сделали. Ввели единый шаблон постановки задач в Jira: обязательные поля — контекст (1–2 предложения), критерии готовности, дедлайн, зависимости, приоритет. Добавили правило: задача без заполненного DoD не берётся в спринт. Шаблон занимает не больше пяти минут на заполнение.

Обучение. Два воркшопа по 1,5 часа — разбор реальных задач команды в формате «плохая версия vs переработанная». Руководитель первые три недели ревьюил все задачи перед добавлением в бэклог и давал письменную обратную связь прямо в комментарии к задаче.

Результат через 2 месяца. Доля задач на переделку снизилась с 30% до 11%. Среднее время выполнения задачи сократилось на 15% — разработчики перестали тратить время на выяснение деталей в процессе. Количество вопросов «а как это делать?» упало примерно вдвое. Побочный эффект: онбординг новых сотрудников ускорился, потому что шаблон задач сам по себе объяснял ожидания.

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

FAQ

Как часто нужно уточнять задачу в процессе выполнения?
Одна промежуточная точка на задачу длиннее трёх дней — достаточно в большинстве случаев. Если задача на день — одна проверка в конце. Главный принцип: лучше один запланированный check-in в удобное время, чем хаотичные пинги «как дела?» посреди рабочего дня.

Что делать, если сотрудник всё равно делает не то?
Сначала проверьте постановку: была ли задача зафиксирована письменно, был ли понят критерий готовности, был ли промежуточный check-in? Если всё это было сделано правильно — тогда вопрос действительно к сотруднику. Если нет — начните с изменения своей практики. В большинстве случаев первый аудит показывает проблему именно на стороне постановщика.

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