Размытая цель вроде «ускорить согласование» звучит разумно, но не помогает команде решить, что делать сегодня. Непонятно, какой результат считать достаточным, от какой точки отталкиваться и кто отвечает за итог. SMART помогает проверить формулировку, а канбан-доска — перевести её в видимые этапы и задачи.
Ниже разберём пять критериев SMART, соберём рабочую формулу и проверим её на трёх сценариях. Затем покажем, что вынести в карточки, какие данные сохранить над доской и почему закрытые задачи ещё не доказывают достижение цели.
Какой результат вынести над доской
Начните не с расшифровки пяти букв, а с результата, который должен существовать после завершения работы. «Провести встречи», «написать регламент» и «настроить доску» — действия. Цель отвечает на другой вопрос: что изменится и по какому факту это можно будет подтвердить.
Хорошая проверка — представить утро после срока. Что именно команда сможет показать: отчёт, принятую версию документа, изменение времени цикла, работающий сценарий? Если ответ сводится к рассказу о проделанной работе, результат ещё не определён. Один и тот же набор действий может привести к разным итогам, поэтому сначала фиксируют факт завершения, а затем выбирают путь к нему.
Если направление ещё не выбрано, сначала стоит сравнить методы постановки. SMART проверяет уже выбранную формулировку, но не решает за команду, какой результат ей нужен.
Что считать завершением
У цели должен быть критерий завершения. Для количественного результата это значение метрики: срок согласования, число успешно пройденных проверок или доля заявок без возврата. Для качественного результата подойдёт бинарная приёмка: регламент согласован владельцем процесса, сценарий прошёл тест по чек-листу, документ опубликован в указанном разделе базы знаний.
Критерий нужен до старта. Если придумать его после выполнения задач, почти любой итог можно объявить успехом. Запишите рядом и защитное условие: что нельзя ухудшить ради красивого счётчика. Например, сокращение срока согласования не должно увеличивать число возвратов на доработку.
Откуда взять исходную точку
Целевое значение имеет смысл только рядом с базой. Зафиксируйте исходную точку, период и источник: отчёт за последние 30 дней, выгрузку из учётной системы, журнал дефектов или акт приёмки. Если база неизвестна, первым этапом становится измерение, а не обещание случайного процента.
Для проверки используйте тот же источник и сопоставимый период. Иначе команда может сравнить среднее значение с медианой, рабочие дни с календарными или спокойный месяц с пиковым — и получить удобный, но неверный вывод.
Современная трактовка SMART раскрывается как Specific, Measurable, Achievable, Relevant и Time-bound: конкретная, измеримая, достижимая, значимая и ограниченная сроком цель. В статье Джорджа Дорана 1981 года использовались другие варианты A, R и T, а автор отдельно отмечал, что не каждое управленческое утверждение обязано включать все пять букв. Поэтому SMART — способ проверить запись, а не гарантия результата.
Как собрать формулу цели
Рабочую цель можно собрать в одном предложении: «К сроку X получить результат Y относительно базы Z, проверить его по источнику N; за итог отвечает владелец V, при этом не ухудшается условие Q». Формула длинная, но заранее снимает основные вопросы.
Прочитайте формулировку человеку, который не участвовал в обсуждении. Он должен понять, какой факт искать, где его искать и в какой день принимать решение. Если приходится устно объяснять значение «улучшить», «повысить качество» или «внедрить», замените эти слова наблюдаемым результатом. Но не перегружайте цель перечнем всех действий: для них будет доска.
Перед запуском полезно проверить формулировку цели: нет ли конфликта с ограничениями, понятен ли владелец и существует ли первый проверяемый этап.
Как задать метрику со сроком
Specific называет конкретное изменение. Measurable задаёт проверяемый признак, но не требует искусственного процента: согласование владельцем процесса тоже измеримо, потому что ответ однозначен. Achievable означает, что команда сверила цель с ресурсами и ограничениями, а не просто выбрала скромное число. Relevant связывает результат с задачей бизнеса или команды. Time-bound фиксирует момент проверки.
Эти критерии работают вместе. «Сократить срок» конкретнее намерения «работать быстрее», но без базы, источника и даты остаётся пожеланием. «Снизить медиану согласования с фактического значения до целевого к концу квартала по отчёту системы» уже можно проверить — если целевое значение подтверждено данными, а не взято для красоты.
Кто отвечает за результат
Владелец цели отвечает за итоговую метрику и решение после срока. Исполнители карточек отвечают за назначенные действия: собрать данные, изменить шаблон, провести проверку, опубликовать документ. Это разные роли.
Если назначить одного человека на все карточки только потому, что он владелец цели, доска перестанет отражать реальную работу. Если владельца не назначить вовсе, задачи могут быть закрыты, а сравнить результат с базой окажется некому.
Как разложить цель на карточки
Формулировку цели не нужно копировать в десятки задач. Оставьте её в служебной карточке или описании доски вместе с базой, источником данных и датой проверки. Ниже расположите этапы, которые дают промежуточный проверяемый результат, а уже внутри этапов — конкретные действия.
Перед декомпозицией проведите простую границу. Если пункт можно назначить одному исполнителю и принять по понятному критерию, это карточка. Если он объединяет несколько действий и заканчивается новым состоянием процесса или продукта, это этап. Если же пункт описывает эффект для команды или бизнеса, он должен остаться на уровне цели.
Какие этапы нужны
Этап — не крупная папка, а промежуточный результат. Для переноса регламента это могут быть утверждённая структура, перенесённая версия, версия с проверенными ссылками и приёмка владельцем процесса. Для сокращения согласования — измеренная база, найденное узкое место, изменённый маршрут и повторный замер.
Не дробите план заранее до мельчайших шагов. Чем выше неопределённость, тем полезнее подробно описать ближайший этап и оставить следующие как проверяемые вехи. После получения нового факта состав задач можно обновить, не меняя сам критерий завершения без отдельного решения.
Какие действия вынести отдельно
Карточка должна описывать одно действие с понятным завершением: «выгрузить заявки за 30 дней», «согласовать структуру с владельцем процесса», «проверить 48 сценариев». Назначьте исполнителя и срок, добавьте чек-лист или вложение, если без них нельзя принять работу.
Связь выглядит так: цель задаёт результат, этап — промежуточный факт, карточка — действие. Перемещение карточки в «Готово» подтверждает выполнение действия, но не автоматически меняет итоговую метрику.
Как настроить доску без ложного прогресса
Для простой рабочей схемы достаточно колонок «Запланировано», «В работе», «На проверке» и «Готово». Этап можно обозначить меткой или группой карточек. Канбано позволяет создавать доски и задачи, назначать исполнителей и сроки, использовать метки, чек-листы и вложения, а также перемещать карточки между колонками.
Служебную карточку с целью лучше не двигать вместе с обычными задачами. Оставьте её в отдельной колонке или закрепите понятным способом внутри принятой командой структуры. В ней нужны формула, владелец результата, база, источник проверки и дата итоговой сверки. Служебная карточка сохраняет контекст цели отдельно от ежедневных задач.
Итоговую метрику проверяет человек по заранее выбранному внешнему источнику. На доске не нужно изображать автоматическую проверку цели, SMART-валидатор, расчёт прогресса или отчёт по KPI.
Какие данные нужны карточке
В названии укажите действие и объект: «Сверить ссылки в регламенте», а не «Регламент». В карточке сохраните исполнителя, дату, критерий готовности и материалы. Метки помогут отличить этап или тип работы, чек-лист — не потерять обязательные проверки.
Если над одной целью работает несколько человек, полезно заранее распределить задачи команды. На самой доске должен быть виден ответственный за каждое действие, а владелец цели — в служебной карточке с формулой и источником метрики.
Почему закрытые карточки не доказывают результат
Команда может выполнить весь план и не получить ожидаемого эффекта. Новый маршрут согласования внедрён, но медиана срока не изменилась. Релиз вышел вовремя, но число серьёзных дефектов выросло. Регламент опубликован, но владелец процесса не принял его.
Число закрытых карточек показывает ход работы, но не достижение цели. На доске это два разных контура: задачи контролируют исполнение, итоговая проверка сравнивает факт с базой.
Как проверить формулу на трёх сценариях
Ниже — учебные примеры. Числа, даты и объёмы в них показывают устройство формулы, а не норматив. В реальной цели их заменяют фактической базой команды и данными из названного источника.
Обратите внимание на четыре перехода в каждом сценарии: размытое намерение становится проверяемой формулой; формула распадается на действия; карточки получают исполнителей и сроки; итог сверяется вне доски по названному источнику. Именно последний переход защищает команду от ситуации, когда план выполнен, а ожидаемое изменение не произошло.
Как перенести регламент в базу знаний
Здесь не нужен искусственный процент готовности. Результат качественный: действующая версия находится в указанном разделе, ссылки работают, а владелец процесса принял документ по чек-листу. Срок ограничивает работу, критерий приёмки делает её измеримой.
Карточки описывают путь к результату, но последняя из них должна фиксировать реальную приёмку. Формулировка «перенести регламент» без названного владельца и проверки оставляет спор о завершении на потом.
Как сократить согласование закупки
Сначала нужна база. В учебном примере команда берёт выгрузку за август и считает медиану — 9 календарных дней. Цель на октябрь — 6 дней по тому же отчёту. Защитный показатель — число возвратов на доработку: ускорение не должно происходить за счёт неполных заявок.
Этапы здесь следуют за фактами: измерить маршрут, найти задержку, изменить одно правило, провести пилот и повторить замер. Если источник или способ расчёта поменялся, сравнение нужно пересобрать.
Как подготовить релиз без роста дефектов
Число пройденных проверок показывает объём работы, но не качество релиза. Поэтому в учебной формуле рядом стоят срок, 48 запланированных проверок и защитное условие — отсутствие дефектов высокой критичности в первые 7 дней.
Сценарий релиза показывает границу SMART: корректная запись не заменяет инженерную оценку рисков. Она лишь заранее сообщает, по каким фактам команда будет принимать результат.
Когда формулы недостаточно
SMART полезен, когда направление понятно и нужно сделать результат проверяемым. При высокой неопределённости точная цифра может создавать ложную уверенность. Для выбора подхода можно увидеть цепочку результата. WOOP помогает разобрать препятствия, а OKR — связать несколько результатов вокруг выбранного направления.
Что делать при высокой неопределённости
Если команда ещё не знает, какое решение сработает, сформулируйте цель как проверяемую гипотезу или результат обучения. Например: к выбранной дате провести пилот на одном маршруте, собрать данные по времени и возвратам и принять решение о масштабировании. Это честнее, чем обещать эффект без базы.
После пилота цель можно уточнить. Пересмотр не означает провал: он нужен, когда изменилась среда, обнаружилось новое ограничение или исходное предположение оказалось неверным.
Как защитить качество от счётчика
Любую количественную метрику проверьте вопросом: что команда может испортить, пытаясь увеличить это число? Больше закрытых заявок может означать больше ошибок; меньше дней согласования — больше возвратов; больше тестов — поверхностную проверку.
Добавьте один защитный показатель или бинарное условие качества. Он не должен превращать цель в сложную систему KPI. Его задача — не позволить считать успехом результат, который формально вырос, но стал хуже для пользователя или процесса.
Как сверить результат после срока
В день проверки откройте исходную запись и тот же источник данных. Сравните факт с базой, целевым значением и защитным условием. После этого зафиксируйте решение: цель достигнута, требуется дополнительный этап или формулировку нужно пересмотреть.
Какие данные сравнить
Сверьте период, единицы измерения и способ расчёта. Отдельно проверьте качество и факт приёмки. Незавершённые действия не стоит автоматически переносить в новую цель: сначала решите, влияют ли они на результат, а затем стоит упорядочить задачи в отдельном разборе очереди.
Итоговая проверка:
- база и дата исходного замера сохранены;
- источник факта тот же или изменение объяснено;
- целевой результат проверен, а не выведен из числа закрытых карточек;
- защитное условие качества выполнено;
- владелец цели зафиксировал решение;
- незавершённые действия пересмотрены перед возвратом в очередь.
Чек-лист не заменяет решение владельца. Он помогает собрать доказательства в одном порядке и не подменить результат активностью. Если часть данных недоступна, это нужно зафиксировать прямо: что именно не удалось измерить, почему и какое наблюдение будет использовано вместо него. Молчаливое изменение источника делает сравнение недостоверным.
Когда пересмотреть цель
Пересмотр нужен, если исчезла значимость результата, изменилась база, ресурсное ограничение сделало цель недостижимой или пилот опроверг исходную гипотезу. Не переписывайте срок задним числом, чтобы сохранить зелёный статус. Сохраните исходную формулу и отдельно запишите новое решение.
SMART делает договорённость проверяемой, доска помогает выполнить связанные действия, но итог всё равно определяется фактом. Когда эти уровни разделены, команда видит честный прогресс и понимает, что именно считать завершением.
После согласования формулы, базы и источника проверки можно создать доску цели и перенести в неё этапы и карточки.