Работа с командой, Agile-процессы и приоритизация

Как аналитик работает с разработкой и тестированием, что он делает на каждой Agile-церемонии и как приоритизирует — блок вопросов «на совместимость с командой».

Задача аналитика в команде — не «выдать документ и уйти», а обеспечить, чтобы разработчик и тестировщик одинаково поняли требование до того, как написан код.

Вопрос 1. Как строится ваша работа с командой разработки и тестирования?

Что проверяют. Совместимость. Интервьюер хочет понять, будете ли вы источником вопросов или источником ответов.

Работающая схема по этапам:

До разработки — груминг требования. Разбор истории командой до планирования: разработчик находит технические дыры, тестировщик — неописанные случаи. Правило: если тестировщик не может придумать проверку, требование недоделано.
Definition of Ready. Договорённость, что история берётся в работу только если у неё есть ценность, критерии приёмки, макеты (если нужны), описанные интеграции и оценённые зависимости.
Во время разработки — быстрый ответ. Аналитик доступен для вопросов; ответ фиксируется в задаче, а не остаётся в личном чате.
Приёмка. Аналитик проверяет соответствие критериям приёмки, но не подменяет тестирование.
После релиза. Смотрит, как фича используется, и возвращает выводы в бэклог.

Отдельно про тестировщика: лучшая практика — отдавать критерии приёмки на ревью тестировщику до начала разработки. Он находит дыры дешевле всех остальных.

Вопрос 2. Что вы делаете на Agile-церемониях?

Что проверяют. Не путаете ли вы Scrum-обряды с бюрократией и понимаете ли свою роль в каждом событии.

Событие	Роль аналитика
Груминг бэклога	приносит подготовленные истории, отвечает на вопросы, забирает уточнения
Планирование спринта	объясняет ценность и критерии приёмки, помогает разбить крупное
Ежедневная встреча	снимает блокеры по требованиям, ловит расхождения в понимании
Демо / обзор спринта	показывает результат в терминах бизнес-ценности, собирает обратную связь
Ретроспектива	работает над качеством требований как над процессом

Полезно отметить границу ролей: владелец продукта отвечает за «что важнее», аналитик — за «что именно и при каких условиях». Совмещение бывает, но подмена — нет.

Вопрос 3. Как вы приоритизируете и оцениваете задачи?

Что проверяют. Наличие метода. Ответ «как скажет владелец продукта» показывает пассивность; ответ «по важности» — отсутствие инструмента.

MoSCoW. Must / Should / Could / Won't. Прост, хорошо работает при фиксированном сроке. Ловушка: всё становится Must — вводите ограничение, например не более 60% объёма в Must.
RICE. Reach × Impact × Confidence ÷ Effort. Полезен, когда нужно сравнить разнородные инициативы числом и защитить приоритет перед бизнесом.
Kano. Разделяет обязательное, линейное и восхищающее. Помогает объяснить, почему «ещё одна настройка» не поднимет удовлетворённость.
Матрица «ценность / стоимость». Быстрый способ найти дешёвые ценные вещи для ближайшего спринта.
Cost of Delay. Что мы теряем за каждую неделю задержки — сильный аргумент для регуляторных и сезонных задач.

Пример расчёта RICE

Инициатива            Reach  Impact  Confid.  Effort   RICE
                      (польз/  (1-3)   (%)    (чел.-нед)
                       мес)
Оплата в один клик     8000    2.0     80%      4       3200
Экспорт отчётов в PDF   400    1.0     90%      1        360
Тёмная тема            5000    0.5     70%      3        583

RICE = Reach × Impact × Confidence / Effort
8000 × 2.0 × 0.8 / 4 = 3200

Вывод: оплата в один клик выигрывает с большим отрывом,
экспорт отчётов дешёв и может пойти «в довесок».

Про оценку скажите главное: аналитик не оценивает трудозатраты разработки — их оценивает команда. Аналитик отвечает за то, чтобы оценка была возможна: убрать неопределённость, разбить крупное, обозначить зависимости. И честно говорить о доверительном интервале: «от 2 до 5 дней, потому что не известна готовность внешнего API» — нормальный ответ, «5 дней» без оснований — нет.

Типичные ошибки кандидатов

Считают, что после передачи документа их работа закончена.
Не привлекают тестировщика до разработки и получают вопросы на этапе приёмки, когда всё дорого.
Отвечают на вопросы в личных сообщениях, и решение не попадает в задачу — через месяц никто не помнит договорённость.
Ставят всему приоритет Must и обесценивают приоритизацию.
Дают оценки за команду и потом объясняют срыв сроков.
Ругают Agile за «отсутствие документации», хотя в Agile документация ровно та, что нужна команде.

Как ответить кратко

Работаю с командой до кода, а не после: приношу историю на груминг, где разработчик находит технические дыры, а тестировщик — неописанные случаи; если тестировщик не может придумать проверку, требование недоделано. Держим Definition of Ready: ценность, критерии приёмки, интеграции, зависимости. Во время спринта быстро отвечаю на вопросы и фиксирую ответы в задаче, а не в личном чате. Приоритизирую методом под ситуацию: MoSCoW при фиксированном сроке с ограничением на долю Must, RICE — когда надо сравнить разнородные инициативы числом, Cost of Delay — для регуляторных задач. Трудозатраты оценивает команда, моя задача — снять неопределённость, разбить крупное и честно показать доверительный интервал.