Как происходит приоритизация и распределение задач аналитиков
Что проверяют
Понимаете ли вы, что аналитика идёт впереди разработки, и знаете ли, чем плохо закрепление людей за системами.
Как отвечать
Приоритизация. Бэклог аналитики формируется из продуктовых задач, запросов поддержки и технических изменений. Приоритет определяет владелец продукта вместе с аналитиком, потому что часть критериев видна только изнутри:
- блокирует ли задача разработку: без описанного требования команда не возьмёт задачу в спринт, поэтому такие идут вперёд;
- срочность и стоимость задержки: требование регулятора с датой отличается от улучшения;
- зависимости: описание общего справочника разблокирует три команды;
- объём неопределённости: задача с непонятной постановкой требует исследования заранее, иначе сорвёт спринт.
Ключевая особенность работы аналитика: он работает на спринт или два вперёд разработки. Поэтому его приоритеты сдвинуты относительно текущего спринта команды, и планировать их вместе с задачами разработки в одном списке неудобно.
Распределение. Варианты:
- по продукту или домену: аналитик закреплён за областью, глубоко её знает. Быстро, но создаёт узкое место: человек в отпуске, и область встала;
- по системам: похоже, с теми же рисками;
- общий пул: берут по готовности. Гибко, но каждый раз нужно погружение.
На практике берут середину: основная область есть, но обязательна страховка вторым аналитиком и обмен знаниями. Хорошая практика это ревью требований коллегой перед передачей в разработку: свежий взгляд ловит противоречия и незакрытые ветки лучше любого чек-листа.
Как встречный вопрос он информативен: если приоритеты аналитику приносят напрямую разработчики и менеджеры без единой очереди, работа превращается в реакцию на срочное.
Где спотыкаются
Не учитывают, что аналитика идёт с опережением.
Закрепляют одного человека за системой и получают единственную точку отказа.
Берут задачу в работу без критериев приёмки.
Не фиксируют, что осознанно не делается.