Почему задачи срываются даже при SMART: где руководитель и сотрудник понимают результат по-разному

Почему задачи срываются, хотя руководитель назвал срок, объем и ответственного? Одна из частых причин в том, что стороны по-разному понимают готовый результат. Сотрудник выполняет формулировку буквально, а руководитель ждет бизнес-эффекта, который вслух не обозначил.

SMART помогает сделать задачу конкретной, измеримой, достижимой, значимой и ограниченной по времени. Но даже формально правильная постановка не гарантирует, что исполнитель и руководитель одинаково представляют итог. Между фразами «задача поставлена» и «задача понята» остается разрыв.

Кейс: руководитель ждал готовых клиентов, а получил список контактов

Владислав Евстратовский, руководитель филиала ООО «ОНИКС», рассказал о ситуации из коммерческого отдела. Компания расширяла ассортимент и готовилась вывести на рынок новый продукт. Руководитель отдела продаж поручил одному из лучших менеджеров до конца следующей недели подготовить список из 30 потенциальных клиентов, с которыми можно провести переговоры и представить новинку.

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

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

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

Почему задачи срываются даже при формально правильной постановке

По словам Евстратовского, в компании разобрали более 50 случаев, когда поручения выполнялись поверхностно, с задержкой или не доводились до результата. Повторялась одна закономерность: исполнитель интерпретировал задачу по-своему.

SMART описывает свойства цели, но сам по себе не отвечает на несколько практических вопросов: что именно нужно передать на выходе, какие действия входят в задачу, какие ресурсы доступны, кто согласует результат и по каким признакам работа будет принята.

Алексей Коломыц, основатель AI-платформы NadelAI, обращает внимание на разницу между действием и изменением процесса. Формулировки «внедрить CRM» или «подключить ИИ» называют инструмент, но не результат. Проверяемая задача должна описывать, что изменится: например, ни одно обращение не теряется, обязательные сведения собраны до передачи специалисту, а руководитель видит отклонения без ручного опроса команды.

Похожая ошибка возникает, когда работа фиксируется в системе только как выполненное действие. В редакционном разборе об ошибках в CRM мы показывали, почему статусы «написали» и «отправили» еще не означают, что контакт состоялся или процесс продвинулся.

Как действие подменяет результат

Анастасия Гулянина, директор по развитию FitBase, приводит пример из фитнес-бизнеса. Задача администратору «обработать новые заявки до конца дня» может означать разные вещи. Один сотрудник ответит клиенту в мессенджере, второй запросит телефон, третий постарается довести обращение до записи на пробное занятие. Действие выполнено во всех трех случаях, но результат для бизнеса разный.

Гулянина ссылается на исследование FitBase, проведенное летом 2026 года методом тайного покупателя среди 195 фитнес-клубов и студий из 51 города. Средняя оценка первого касания составила 26 баллов из 60. Контакт потенциального клиента запросили 28% объектов, конкретное время звонка предложили 6%. При этом сотрудники отвечали на вопросы клиентов, то есть формально коммуникация происходила.

Поэтому задачу лучше формулировать не как «ответить на все заявки», а как последовательность с проверяемым итогом: связаться с клиентом, зафиксировать контакт в CRM и предложить следующий шаг. Тогда руководитель оценивает не количество отправленных сообщений, а продвижение обращения.

TRAMS: пять вопросов со стороны исполнителя

После разбора срывов Евстратовский дополнил SMART внутренней проверкой со стороны исполнителя и назвал ее TRAMS. Это не общепринятый управленческий стандарт, а практический прием компании. Его задача в том, чтобы обнаружить неопределенность до начала работы.

Если хотя бы по одному пункту нет ясности, исполнитель задает вопросы до старта. В кейсе со списком клиентов проверка по TRAMS быстро обнаружила бы расхождение. По пункту Metrics & Acceptance пришлось бы уточнить, что считается готовым результатом: 30 записей в таблице или 30 компаний после первичного контакта. По пункту Actions стало бы понятно, входит ли обзвон в задачу.

В IT похожую функцию выполняют критерии Definition of Ready и Definition of Done. Коуч платформы корпоративного благополучия «Понимаю» Аля Васильева предлагает адаптировать их под другие сферы: заранее определить, когда задача готова к работе и по каким признакам ее можно считать завершенной. Название инструмента вторично. Важно, чтобы команда фиксировала требования до старта, а не восстанавливала их после переделки.

Вопрос «Все понятно?» не проверяет понимание

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

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

Гулянина советует проверять объемные задачи на небольшом фрагменте. Если сотруднику нужно обработать большую клиентскую базу, первые результаты можно посмотреть после 10-20 контактов. Ошибку в сценарии или понимании тогда исправят до того, как она повторится сто раз.

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

Когда дополнительная проверка нужна, а когда мешает

Евстратовский не предлагает прогонять через TRAMS каждое рутинное поручение. По его мнению, методика полезна в трех ситуациях:

• сотрудник получает нестандартную задачу;
• новый сотрудник впервые выполняет знакомую для команды работу;
• задачи этого типа уже срывались, затягивались или возвращались на переделку.

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

Что проверить до начала работы

После внедрения TRAMS, по словам Евстратовского, в компании существенно сократилось количество невыполненных и затянутых задач. Точный показатель он не приводит, поэтому оценивать эффект в процентах нельзя. Но управленческая логика инструмента понятна: несколько минут на синхронизацию до старта дешевле, чем неделя работы над результатом, который никто не собирался принимать.

SMART остается полезной основой. Проблема начинается не в самой модели, а в ожидании, что правильная формулировка автоматически создает одинаковое понимание. Задача действительно поставлена только тогда, когда руководитель и исполнитель могут одинаково описать результат, критерии приемки и следующий шаг.