Что такое SMART: объяснение на человеческом языке
Метод SMART — это инструмент, который помогает понять: о чём задача на самом деле, как оценить результат, когда ее можно закрыть и зачем она вообще существует. Особенно это важно в IT, где работа часто абстрактна, а ценность нужно доказывать не количеством коммитов, а эффектом.
SMART — способ ставить задачи так, чтобы их можно было выполнять в реальности, а не вдохновенно обсуждать на созвонах.
Аббревиатура расшифровывается следующим образом:
- S — Specific (конкретная): задача описывает, что именно нужно сделать.
- M — Measurable (измеримая): есть понятный критерий того, что работа закончена.
- A — Achievable (достижимая): задачу можно выполнить с текущими ресурсами и навыками.
- R — Relevant (релевантная): задача имеет смысл в контексте проекта, продукта или бизнеса.
- T — Time-bound (ограниченная по времени): есть срок, а не «когда-нибудь».
Кажется, что у хорошей SMART-задачи будет длинная формулировка, но она может быть короткой и точной. Главное, чтобы вы и ваша команда одинаково понимали, что именно делать, когда это будет готово и зачем.
Примеры SMART-задач по ролям в IT
Прежде чем будем разбираться детальнее, покажу на примерах, как SMART-задачи выглядят в жизни. Ниже — сравнение «как обычно» и «по уму» для разных IT-ролей.
Frontend
- Плохо: «Сделать адаптив»
- Хорошо: «Реализовать адаптивность для всех экранов от 360px до 1440px на главной странице до 15 мая»
Backend
- Плохо: «Пофиксить API»
- Хорошо: «Снизить среднее время ответа /orders API с 1.2s до 500ms к 10 июня»
QA
- Плохо: «Проверить новый функционал»
- Хорошо: «Покрыть smoke-тестами новый модуль авторизации (100% happy path, 80% edge cases) до релиза 5.3»
BI-аналитик
- Плохо: «Посчитать метрики»
- Хорошо: «Построить дашборд по воронке продаж в Tableau с сегментацией по каналам до конца недели»
DevOps
- Плохо: «Настроить CI/CD»
- Хорошо: «Настроить пайплайн автотестов и деплоя staging-сервера в GitLab до 20 мая»
Хорошие задачи можно проверить, показать другим и уверенно зафиксировать как выполненные. И еще они точно не вызовут споров на ретроспективе о том, что именно имелось в виду.
Почему задачи без SMART как баги без логов
Хорошо, с примерами разобрались, но зачем вся эта бюрократия? Ведь главное — чтобы было сделано. Увы, в реальности задачи без SMART как баг-репорты без скриншотов: кто-то что-то заметил, но что именно — никто не знает.
Вот что обычно происходит с задачами, если они не проходят фильтр SMART:
- «Неясные задачи» — разработчик пишет код, тестировщик тестирует, менеджер нервничает. Никто не уверен, что задача решена, но все работают.
- «Невозможные задачи» — задача вроде бы конкретная, но ресурсов или времени на нее не хватит даже при поддержке магии.
- «Вечные задачи» — формально никто не виноват, но таска висит неделями, потому что ее невозможно завершить — нет точки Done.
Например, задача «Повысить производительность продукта» может означать всё что угодно: от оптимизации SQL-запросов до увольнения половины команды. Без конкретики это даже не задача, а способ сделать вид, что работа идет.
Как проверять свои задачи на SMART (и не выгореть по пути)
Хорошая новость: SMART — это еще и про заботу о себе. Метод не просто помогает понять задачу, он защищает от абстрактной «вечной занятости». А это, в свою очередь, довольно хорошо помогает не выгорать: вы всегда видите, какие задачи закрыли, а что еще предстоит сделать, и можете адекватно оценить нагрузку.
Вот простой чек-лист, чтобы проверить задачу на SMART:
Что делать, если вы не менеджер, но задачами всё равно приходится жить
Ну всё понятно, опять менеджеры тут менеджерят, статья не для меня, но нет… Вы можете быть middle backend-разработчиком, UI-дизайнером или веб-аналитиком. И при этом ежедневно сталкиваться с задачами, которые либо вы ставите себе сами, либо получаете от кого-то «на доработку». Удивительно, как часто они приходят в формате «ну просто посмотри» или «там надо немного поправить».
Вот что можно делать, даже если вы не отвечаете формально за постановку задач:
- Уточняйте. «Что именно нужно поправить? Где увидим, что всё работает?» — два простых вопроса, которые спасают часы.
- Переформулируйте. Возьмите неясную задачу и превратите ее в SMART-версию — хотя бы для себя.
- Ищите связи. Задача может быть технически ясной, но непонятной по смыслу. «А зачем?» — не праздный вопрос, а ключ к тому, как сделать результат действительно ценным.
- Обозначайте риски. Не бойтесь говорить, что задачу нельзя выполнить в срок или с текущими ресурсами — это не слабость, а зрелость.
- Обсуждайте критерий готовности. Кто принимает результат? Что значит «готово» — выкладка в staging или релиз в прод?
Таким образом, даже не будучи менеджером, вы можете строить задачи, в которых есть смысл и меньше сюрпризов.
Как внедрять SMART в команду, не становясь занудой
Почти в любой команде есть человек, который однажды говорит: «А давайте ставить задачи по SMART». После этого кто-то тихо закатывает глаза, кто-то делает вид, что это и так очевидно, а кто-то путает SMART с KPI и уходит наливать кофе. Но на самом деле всё не так уж страшно.
Внедрение SMART — это про то, чтобы последовательно улучшать практику задач. Вот несколько способов:
- Подавайте пример. Начните писать свои задачи по SMART. Даже если остальным всё равно — через пару недель внезапно обнаружится, что именно к вашим таскам меньше вопросов.
- Помогайте переформулировать. Вместо «так не работает» — «давай конкретизируем: какой результат ожидается?».
- Не продавливайте, а показывайте выгоды. Обсудите, сколько часов уходит на переделки, когда задача неполная. Это аргумент, который понимают и менеджеры, и разработчики.
- Используйте шаблоны. Сделайте 2–3 варианта типовых задач (например, баг-фикс, фича, исследование) и раскладывайте их по SMART. Это снижает сопротивление, потому что не нужно думать над формулировками — можно просто скопировать.
- Заводите привычку Definition of Done. Удобно начинать с конца — с критериев выполнения задач. Даже если в остальном формулировка будет не по SMART, у вас уже появится внятная финальная точка, к которой гораздо проще идти.
Как видите, то, о чём я говорю, — просто здравый смысл, обернутый в аббревиатуру. И если использовать его мягко, но последовательно, со временем команда сама начнет его применять — даже не называя это SMART.
Типовые ошибки применения SMART и как их избежать
Если вы попробуете внедрить SMART с понедельника, велика вероятность, что к среде вы встретите первые грабли. Чтобы не было больно, вот список распространенных ошибок, а заодно и как их обойти:
Ошибка 1. «Всё должно быть суперконкретно, иначе никак»
Реальность. Иногда задача — это исследование или прототип. Не всё можно сразу измерить или привязать ко времени. Если цель «понять, можно ли вообще решить задачу» — так и пишите.
Как быть. Добавляйте ясность в процессе, но не бойтесь начинать с допущений и гипотез.
Ошибка 2. «SMART — только для продуктовых задач»
Реальность. Даже задача по обновлению библиотек может быть по SMART: «Обновить библиотеку X до версии 5.2, проверить на staging, убедиться, что не ломает интеграции».
Как быть. Формулируйте любые задачи так, чтобы понятно было, что делаем и когда «готово».
Ошибка 3. «Мы всё равно всё переделаем — зачем тратить время на постановку»
Реальность. Переработки и итерации — нормальная часть жизни в IT. Но они становятся в несколько раз болезненнее, когда никто толком не помнит, что вообще хотели сделать.
Как быть. Лучше переформулировать задачу в процессе, чем с самого начала идти в туман.
Ошибка 4. «SMART про контроль, а не про результат»
Реальность. Удивительно, но хороший SMART защищает исполнителя. Когда есть критерии, проще говорить «готово» и уходить спать спокойно.
Как быть. Показывайте, как SMART помогает не только менеджменту, но и разработчикам, тестировщикам, аналитикам — тем, кто реально работает.
Что в итоге?
SMART, конечно, неидеальный инструмент. Но попробуйте следовать ему, постарайтесь избежать типичных ошибок и затем предложите коллегам тоже попробовать. Если это поможет вам избежать хаоса, сфокусироваться и увидеть больше выполненных задач — это уже станет хорошим результатом. А в мире, где таск-трекер компании иногда выглядит как бездонная яма, это уже хорошо.
