Когда аналитик — один, а задач двадцать
Ситуация банальная: аналитик в проекте один, задач — много, всё горит, все кричат «очень срочно», но только ты знаешь, что «очень срочно» ≠ «хоть как-то успеем».
Аналитик в таких проектах быстро превращается в узкое горлышко:
— ТЗ надо? Надо.
— Процессы описать? Да.
— Согласовать с тремя отделами? Конечно.
— Прототипы показать, API обсудить, участвовать в демо, всё задокументировать и ещё на встречах не молчать? Легко, ты же системный.
🙃 Только вот это физически невозможно. И чем дальше — тем больше компромиссов:
— «Ну, это пока устно договорились…»
— «Это без схемы, но понятно же...»
— «Да, это не финальное ТЗ — но в релиз уже уехало».
А потом:
— «Почему не учли это сразу?»
— «А где написано, что должно быть так?»
— «Почему у нас опять доработка, а не сразу как надо?»
Ответ один: аналитик не должен быть единственным и последним. Особенно в сложных проектах, где задачи идут параллельно, а не последовательно.
🔸 Поднимать вопрос о ресурсах нужно не тогда, когда всё срывается, а сразу, когда понимаешь масштаб.
🔸 Расставлять приоритеты — не стыдно. Делать всё — невозможно.
🔸 Если тебе ставят 20 задач, спроси: какие 3 критичны, а что точно можно отложить?
Иначе потом спросят всё равно с тебя. Даже если ты в одиночку держал фронт.
Хочешь, чтобы аналитик был эффективным, а не горелым? Слушай, когда он говорит «не вывезу». Это не нытьё — это здравый расчёт.
Школа проектного специалиста | @techit
