Аналитик живёт в мире противоречий. С одной стороны - методологии, которые обещают навести порядок: SMART, INVEST, MoSCoW. С другой - реальность: брифы, скользкие бизнес-цели и коммуникации в духе “Ну тыжаналитик! Разберись!”
Инструменты вроде SMART, INVEST и MoSCoW помогают систематизировать хаос, структурировать требования, сделать их понятными, оценимыми, удобными для команды. Но если применять их бездумно, то становятся просто декорацией.
Как и где эти подходы могут применяться аналитиком не по учебнику, а по боли, где они действительно полезны, где вредны или просто неуместны. Щас выскажусь!
SMART: Когда конкретика становится ограничением
SMART - это аббревиатура, описывающая характеристики “хорошего” требования:
Specific — конкретное
Measurable — измеримое
Achievable — достижимое
Relevant — релевантное
Time-bound — ограниченное по времени
Отлично работает, когда цели четко определены и предсказуемы. Однако в сложных проектах, где требования часто меняются, жесткая привязка к SMART может привести к проблемам.
Пример: В одном проекте команда сформулировала требование: "Увеличить конверсию на 15% за три месяца." Однако через месяц рынок изменился, и цель стала недостижимой. Команда продолжала пытаться достичь изначальной цели, игнорируя новые бизнес-приоритеты.
Когда лучше не использовать SMART
В условиях высокой неопределенности: Если проект находится на стадии исследования или прототипирования, SMART может ограничить гибкость.
В Agile-проектах: Жесткая привязка к временным рамкам может ограничить гибкость.
При работе с субъективными метриками: Например, если цель связана с улучшением пользовательского опыта, ее сложно формализовать через SMART.
INVEST: Когда гибкость превращается в хаос
Это набор критериев, используемых для написания качественных пользовательских историй (User Stories). Этот подход помогает аналитикам создавать требования, которые легко реализовать, тестировать и интегрировать в процесс разработки.
Independent : Истории должны быть независимыми друг от друга, чтобы их можно было реализовать в любом порядке.
Negotiable : Истории должны быть гибкими и допускать обсуждение деталей.
Valuable : Каждая история должна приносить пользу пользователю или бизнесу.
Estimable : История должна быть достаточно ясной, чтобы команда могла оценить объем работ.
Small : Размер истории должен быть таким, чтобы она могла быть завершена в течение одного спринта.
Testable : История должна быть проверяемой через тестирование.
INVEST идеально подходит для Agile-проектов, но его использование без учета контекста может привести к проблемам:
Пример: Команда попыталась сделать все пользовательские истории "независимыми" (Independent). Это привело к тому, что сложные функциональные блоки были разбиты на множество мелких историй, которые теряли смысл вне контекста.
Когда лучше не использовать INVEST
В проектах с высокой степенью зависимости между требованиями: Если требования тесно связаны друг с другом, разделение их на независимые истории может усложнить процесс.
В документоцентричных проектах: Если требования должны быть подробно описаны и согласованы заранее, INVEST может оказаться недостаточно формализованным.
MoSCoW: Головная боль приоретизации
Это метод приоритизации требований, который помогает аналитикам и заинтересованным сторонам определить, какие функции являются наиболее важными для проекта, а какие можно отложить или исключить:
Must have : Без этих требований проект считается неудачным.
Should have : Эти требования важны, но их можно отложить.
Could have : Желательные, но не критичные требования.
Won't have : Неприоритетные требования, которые исключаются из текущего релиза.
MoSCoW отлично подходит для управления ожиданиями и приоритизации требований. Однако он не предоставляет инструментов для оценки выполнимости или измеримости требований, что может быть проблемой в долгосрочных проектах.
Пример: Команда столкнулась с тем, что все требования были помечены как "обязательные". Это привело к перегрузке команды и задержкам. После внедрения MoSCoW удалось четко определить ключевые функции и сфокусироваться на них, что позволило выпустить MVP в срок.
Когда лучше не использовать MoSCoW
В проектах с большим количеством заинтересованных сторон: Если нет единого лица, принимающего решения, MoSCoW может привести к конфликтам.
При работе с новыми продуктами: На этапе исследования трудно определить, какие требования действительно являются "Must have."
В проектах с ограниченным бюджетом: Если ресурсов недостаточно для реализации Must have, MoSCoW может создать ложное ощущение управляемости.
Что в итоге
Каждый из подходов - SMART, INVEST и MoSCoW - имеет свои преимущества и ограничения. Чтобы избежать ошибок, важно учитывать контекст проекта:
SMART подходит для проектов с четкими целями, но может быть контрпродуктивным в условиях высокой неопределенности.
INVEST помогает в Agile-проектах, но требует внимательного подхода при работе с зависимыми требованиями.
MoSCoW полезен для приоритизации, но может вызвать конфликты в проектах с множеством заинтересованных сторон.
Это инструменты, а не догмы. "Правда" заключается не в том, чтобы следовать методологии слепо, а в том, чтобы использовать ее как инструмент, который помогает достичь бизнес-целей, и адаптировать под свои нужды.
Я веду свой блог #ЯЖАНАЛИТИК, в котором рассказываю о буднях системного аналитика, околоITшной жизни, описываю рабочие кейсы и лайфхаки доступным языком. Без нудятины и духоты.
