Хард-скилл, который недооценивают 90% аналитиков: работа с изменениями требований

Я уже как-то поднимала эту тему ранее и чувствую что еще ни раз буду к ней возвращаться 😡

Знаете, какая ошибка встречается у аналитиков чаще всего?
Даже у опытных.

💥 Они считают, что изменение требований — это исключение.
А на самом деле — это норма жизни продукта.
И если нет грамотной работы с изменениями, то начинается то, что видели многие:
➡️ «а мы думали, что это уже учли»
➡️ «это же так очевидно, разве нет?»
➡️ «почему это не вошло в релиз?»
➡️ «давайте срочно перепишем»
➡️ «ой, а оказалось, что бизнес имел в виду другое»
И вот тут аналитик становится пожарным 🚒.

🔍 Почему так происходит?
Потому что многие аналитики делают одну и ту же ошибку:
✖️ получают запрос → ✖️ сразу идут писать ТЗ.
Но запрос ≠ требование.
Требование ≠ финальная формулировка.
Финальная формулировка ≠ незаменяемая истина.

☑️ Так как же правильно?
Вот минимальный, но рабочий алгоритм, который спасает от хаоса:

1️⃣ Фильтр/приём запроса
Задаём 5 обязательных вопросов:
➡️зачем это нужно бизнесу?
➡️кому это принесёт ценность?
➡️что будет, если не делать?
➡️что меняется в уже согласованных требованиях?
➡️какие системы задеты?
2️⃣ Выявление и уточнение (а не “сделаем так”)
Аналитик обязан показать зависимые процессы, ограничения, влияние на текущую архитектуру.
3️⃣ Фиксация изменения (всегда!)
Даже если кажется, что «ерунда, 2 строчки».
4️⃣ Оценка влияния
На сроки, на стоимость, на риски, на уже согласованный объём.
5️⃣ Согласование новой версии требования
Это то, что почти никто не делает корректно.

‼️ И вот момент, когда аналитик должен сказать «СТОП»
Когда запрос звучит так:
«Давайте просто чуть-чуть поменяем…»
и при этом: неизвестно влияние, нет понимания бизнес-цели, нет согласования с командой, не рассмотрены риски.

СТОП здесь — это не «нет».
СТОП — это «давайте проверим».

❤️ Почему это важно для карьеры
От качества работы с изменениями зависит репутация аналитика. Не навык строить BPMN, не красивое ТЗ — а именно способность управлять изменениями. И это один из тех навыков, который отличает джуна от мидла, а мидла от сеньора.

Если вам интересно прокачать этот навык глубоко, на реальных кейсах — это как раз то, что мы регулярно делаем в Клубе IThumanWork.
Но это уже для тех, кто готов расти системно 💜

#ITHumanWork #BusinessAnalysis