Аналитик живёт в мире противоречий. С одной стороны — методологии, которые обещают навести порядок: 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 — имеет свои преимущества и ограничения. Чтобы избежать ошибок, важно учитывать контекст проекта:

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

2. INVEST помогает в Agile-проектах, но требует внимательного подхода при работе с зависимыми требованиями.

3. MoSCoW полезен для приоритизации, но может вызвать конфликты в проектах с множеством заинтересованных сторон.

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

Я веду свой блог #ЯЖАНАЛИТИК, в котором рассказываю о буднях системного аналитика, околоITшной жизни, описываю рабочие кейсы и лайфхаки доступным языком. Без нудятины и духоты.