Если вы не работали с такими требованиями, то можно сказать, и не работали в IT.
Бизнес иногда приносит ТАКОЕ, от чего вполне может развиться выгорание или ПТСР.
Конечно, можно смириться и делать что скажут
Но задача аналитика не просто принять требования и оформить, а разобраться — точно ли нужно делать именно так? И если нет, донести это без скандала.
Вот как можно разложить это по шагам:
1. Сначала идентифицируй требование🧐
Прежде чем паниковать, задай себе три вопроса:
⏺Если это не реализовать, бизнес-потребность всё равно закроется?
⏺Можно закрыть это имеющейся функциональностью или сделать проще?
⏺Есть ли риски в реализации этого требования?
Часто уже на этом шаге становится понятно, что требование можно упростить или вообще выкинуть.
2. Выяви истинную потребность🔍
Бизнес часто говорит что хочет, но не всегда понимает что ему на самом деле нужно.
Копай глубже:
💬Какую задачу он пытается решить?
💬Что произойдёт, если это не сделать?
💬Есть ли ограничения, которые не дают рассматривать другие варианты?
Если ограничения есть и альтернатив нет, то сразу переходи к шагу 4.
3. Предложи альтернативы 💡
Не просто скажи «это плохо/делать не будем/вы не шарите», а покажи варианты:
➡️ Вариант 1 — что хочет бизнес.
Опиши честно, какие трудности это создаст. Без субъективного «это тупо/сложно/некрасиво», только сухие факты. Обычно после оценки и сроков этот вариант сам отметается 🙂
➡️ Вариант 2 — некий костыль.
Может, можно сделать небольшую доработку уже существующего функционала? Обычно это самый дешёвый и быстрый вариант. Но не всегда самый правильный, тут важно обсудить его с архитектурой, потому что иногда костыль это очень плохо!!!!!!!
➡️ Вариант 3 — самый трушный.
Решение, которое закрывает потребность бизнеса с минимальными рисками. Да, может быть дороже, но в долгосрок все выигрывают и переделывать точно не придётся.
4. Зафиксируй ограничения и риски 📝
Бывает, бизнес хочет эту зелёную кнопку «ну вот тока тут». Не всегда получается переубедить, такое иногда бывает.
Да ты че? Базару нет
Но перед тем как брать в работу, обязательно зафиксируй все риски и ограничения письменно. Пропиши возможные последствия и способы их устранения.
Если на демо или ПСИ кинут предъяву, сможешь уверенно и без задней мысли сказать: «А Я ВАМ ГОВОРИЛ!!!!!!!!!!!!!!!»
5. Полный газ👍
Всё согласовано, риски зафиксированы, спокойно приступаешь к аналитике.
Главное помни: твоя задача не просто выполнить требование, а помочь бизнесу получить качественный результат. Иногда это значит задать неудобный вопрос:
"Подождите, коллеги. Я вас правильно понял? Вы хотите сделать какую-то х*ету?
А вам часто прилетают плохие требования? Как справляетесь? 👇
IT АНАЛитика | Подписаться