Что такое SMART?

SMART: Методология постановки целей и требований

SMART — это аббревиатура, обозначающая критерии для формулирования эффективных целей и требований в проектном менеджменте и системном анализе. Этот подход был предложен Джорджем Доераном в 1981 году и с тех пор стал стандартом в управлении проектами.

Расшифровка SMART

S — Specific (Конкретность)

Требование должно быть четким, понятным и однозначно интерпретируемым. Избегаются общие фразы и расплывчатые формулировки.

• ❌ Неправильно: "Система должна быть быстрой"
• ✅ Правильно: "Время загрузки главной страницы должно быть менее 2 секунд"

Специфичность означает, что разработчик и заказчик одинаково понимают требование без дополнительных уточнений.

M — Measurable (Измеримость)

Должны существовать четкие критерии и метрики для оценки выполнения требования. Нельзя оставлять место для субъективного суждения.

• ❌ Неправильно: "Интерфейс должен быть удобным"
• ✅ Правильно: "90% пользователей должны найти необходимую функцию за 3 клика"

Измеримые требования позволяют:

• Объективно проверить выполнение
• Провести тестирование
• Оценить качество
• Использовать метрики для мониторинга

A — Achievable (Достижимость)

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

• ❌ Неправильно: "Обработка 1 млн запросов в секунду на одном сервере за $100"
• ✅ Правильно: "Обработка 100 тыс. запросов в секунду при инфраструктуре из 10 серверов с бюджетом $50 тыс."

Достижимость оценивается совместно:

• Архитектором (технически возможно?)
• Менеджером (в рамках бюджета?)
• Командой разработки (за отведенное время?)

R — Relevant (Релевантность)

Требование должно быть связано с бизнес-целями проекта и актуально для пользователей. Требования, которые "было бы хорошо иметь", отвлекают от главного.

• ❌ Неправильно: В E-commerce системе требование "Поддержка 20 редких валют" (если основной рынок — одна страна)
• ✅ Правильно: "Поддержка валют основных рынков доставки: EUR, USD, RUB"

Релевантность проверяется вопросом: "Приносит ли это требование ценность бизнесу или пользователю?"

T — Time-bound (Ограничение по времени)

Должны быть установлены четкие временные рамки для достижения требования. Это может быть дата завершения, версия релиза или фаза проекта.

• ❌ Неправильно: "Система должна быть масштабируемой"
• ✅ Правильно: "К Q3 2026 система должна масштабироваться до 1 млн пользователей"

Временные рамки помогают:

• Планировать работу
• Отслеживать прогресс
• Определить приоритеты
• Избежать бесконечного совершенствования

Примеры применения в системном анализе

Пример 1: Нефункциональное требование

❌ "Система должна быть надежной"

✅ "В течение производственного периода (12 месяцев) система должна обеспечивать минимум 99.9% доступности, с максимальным временем восстановления (RTO) не более 1 часа при критических сбоях"

Пример 2: Функциональное требование

❌ "Пользователь может загружать документы"

✅ "К версии 2.0 (июнь 2026) пользователь должен иметь возможность загружать PDF, DOC и XLSX документы размером до 50 МБ через веб-интерфейс, с индикатором прогресса и возможностью отмены"

Пример 3: Бизнес-требование

❌ "Увеличить конверсию"

✅ "К концу Q4 2026 увеличить коэффициент конверсии свободного пользователя в платного с 5% до 8%, путем внедрения A/B тестирования в процесс регистрации"

Процесс формулирования SMART-требований

1. Черновик: Напиши требование в свободной форме
2. Проверка S: Достаточно ли конкретно? Нет двусмысленности?
3. Проверка M: Как ты будешь измерять выполнение? Какие метрики?
4. Проверка A: Реалистично ли? Согласны ли архитектор и team lead?
5. Проверка R: Почему это важно? Какую ценность приносит?
6. Проверка T: Какой дедлайн? Какая версия/фаза?
7. Согласование: Обсуди с заказчиком и командой

Практическое значение для аналитика

Системный аналитик, использующий SMART-подход:

• Снижает риск неправильного понимания требований
• Упрощает тестирование — критерии приемки очевидны
• Улучшает коммуникацию — все говорят на одном языке
• Облегчает мониторинг — можно отслеживать прогресс
• Защищает проект — нет споров о выполнении требований

SMART — не просто методология, а вопрос профессионализма и ответственности перед заказчиком и командой разработки.