Аналитик в спринте
Планирование, вторник. Команда открывает элемент «Подключить оплату частями» и за двадцать минут задаёт восемь вопросов, ответов на которые нет: кому доступно, что происходит при возврате, кто считает комиссию, что показываем при отказе банка. Элемент откладывают. Это не провал планирования - это провал прошлой недели, когда его надо было прорабатывать.
Стержень: основная работа аналитика идёт не на событиях, а в непрерывной подготовке бэклога на шаг впереди разработки.
// Формулировки: «чем занят на планировании?», «насколько вперёд прорабатываешь?», «разработчик нашёл дыру в требованиях»
Проработка идёт впереди разработки
Refinement - не встреча в календаре, а непрерывная работа: элементы уточняются, делятся на куски поменьше, обрастают критериями приёмки и макетами. Цель одна - чтобы к планированию у команды не осталось вопросов, блокирующих старт.
Разумный горизонт - один-два спринта. Короче - команда упирается в неготовые элементы и половину планирования выясняет вместо того, чтобы брать в работу. Длиннее - детальная проработка успевает протухнуть: приоритеты сменились, часть элементов отменили, и время ушло в стол.
// На самом планировании аналитик не раздаёт задачи и не оценивает за команду. Его работа там - снимать неоднозначности: уточнять поведение, показывать макеты, отвечать на вопросы, записывать принятые решения прямо в элемент.
Градиент глубины
Прорабатывать всё одинаково подробно - верный способ потратить время зря. Глубина зависит от того, насколько элемент близко к работе.
Ближайший спринт: критерии приёмки, макеты, разобранные исключения, согласованные с бизнесом решения. Следующий: понятная формулировка задачи, известные ограничения, грубая оценка. Дальше: одна строчка и владелец вопроса. Такой градиент даёт команде не простаивать и вам не работать в стол.
// Полезный признак: если элемент в ближайшем спринте всё ещё вызывает вопрос «а как оно должно себя вести вот тут», проработка не закончена, сколько бы страниц ни было написано. Объём документа и готовность элемента - разные вещи.
Пробел в требованиях: короткий цикл
Разработчик находит дыру в середине задачи - это нормально и неизбежно, требования не бывают полными. Плохо другое: когда решение принимается молча. Тогда оно не попадает ни в критерии приёмки, ни в тесты, ни в документацию, и всплывает на приёмке как сюрприз для бизнеса.
Правильный цикл короткий: уточнили, решили, записали в элемент. Останавливать задачу целиком обычно избыточно, вопрос решается за час, а вот запись обязательна - именно она отличает решение от договорённости, о которой через месяц никто не вспомнит.
// Отдельный риск - стать единственным каналом между бизнесом и командой. Любой посредник интерпретирует, и без прямого контакта ошибка интерпретации живёт до приёмки. Задача аналитика - сокращать расстояние между людьми, а не быть на нём узким местом.
Как измерить свою пользу
Число написанных документов и проведённых встреч - это затраты, а не результат. Их рост может означать что угодно, включая плохо организованную работу и лишние согласования.
Честные показатели неудобны, потому что могут показать плохое. Доля переделок из-за неверно понятых требований: если из 40 задач спринта переделывались 5, это 12 процентов, и вот с этим числом уже можно работать. Число вопросов, заблокировавших разработку. Доля приёмок, прошедших без сюрпризов. Данные для первого обычно есть в трекере, надо лишь помечать причину переделки.
// Ещё один признак здоровья, который видно со стороны: меняется ли бэклог после обзора спринта. Если неделя за неделей не меняется, обратная связь никуда не идёт, и все события проводятся вхолостую.
Как отвечать: «Насколько вперёд прорабатываешь бэклог?»
Держу задел примерно на спринт-полтора. Меньше - команда на планировании упирается в неготовые элементы, и часть спринта уходит на выяснение вместо работы. Больше - детальная проработка успевает устареть: приоритеты меняются, часть элементов отменяется, и время потрачено в стол. При этом глубина разная, и это важнее самого горизонта: ближайшие элементы доведены до критериев приёмки, макетов и разобранных исключений, следующие существуют как понятная формулировка задачи с грубой оценкой, дальние - одной строчкой. Такой градиент позволяет и не простаивать, и не писать документы для того, что никогда не сделают. Готовность элемента я проверяю не объёмом текста, а тем, остались ли у команды вопросы, блокирующие старт.
Кандидат называет число, обосновывает границы с обеих сторон, добавляет градиент глубины и критерий готовности - признаки реальной практики.
На чём валятся
- −− Прорабатывают всё на квартал вперёд в деталях и работают в стол.
- −− Приносят на планирование элементы, к которым у команды сразу восемь вопросов.
- −− Становятся единственным каналом между бизнесом и командой.
- −− Позволяют разработчику молча закрыть пробел в требованиях, не записав решение.
- −− Оценивают свою пользу числом документов и встреч.
- −− Путают объём написанного с готовностью элемента к работе.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.
- Насколько вперёд аналитику разумно прорабатывать бэклог?A)На один-два спринта вперёдB)На весь квартал целикомC)Ровно на текущий спринтD)До конца проекта заранее
показать ответ и разбор
+A)На один-два спринта вперёд// разбор: Слишком короткий горизонт оставляет команду без готовых элементов и рождает простои. Слишком длинный — это работа, которая устареет: приоритеты сменятся, а детальная проработка отменённых элементов пропадёт зря. Один-два спринта обычно дают буфер, не создавая большого запаса протухающего анализа.
- Разработчик по ходу задачи нашёл незакрытый случай в требованиях. Как правильно поступить?A)Реализовать на своё усмотрение и сообщить потомB)Остановить задачу до конца спринтаC)Уточнить у аналитика и зафиксировать решениеD)Отложить случай до этапа тестирования
показать ответ и разбор
+C)Уточнить у аналитика и зафиксировать решение// разбор: Пробелы в требованиях находятся именно в разработке — это нормально. Плохо, когда решение принимается молча: тогда оно не попадает ни в критерии приёмки, ни в тесты, ни в документацию, и всплывает как расхождение позже. Правильный цикл короткий: уточнили, решили, записали в элемент.
- Аналитик — единственный, кто общается с бизнесом, и команда видит только его формулировки. Чем это рискованно?A)Аналитик станет незаменимым сотрудникомB)Искажения смысла никто не заметитC)Вырастет объём документацииD)Замедлится согласование требований
показать ответ и разбор
+B)Искажения смысла никто не заметит// разбор: Любой посредник неизбежно интерпретирует, и без обратного канала ошибка интерпретации не обнаруживается до приёмки. Лечится не заменой аналитика, а прямым контактом: разработчики присутствуют на демонстрациях, заказчик приходит на обзор, критерии приёмки читаются вслух с обеих сторон.
- Что должно случиться с результатом обзора спринта в работе аналитика?A)Он превращается в изменения бэклогаB)Он передаётся владельцу продукта без измененийC)Он фиксируется в протоколе для архиваD)Он учитывается при следующем крупном релизе
показать ответ и разбор
+A)Он превращается в изменения бэклога// разбор: Обратная связь имеет ценность, только если меняет план: появляются новые элементы, уточняются существующие, отменяются потерявшие смысл. Если после обзора бэклог остаётся прежним неделя за неделей, событие превращается в отчётный ритуал, а команда учится не слушать пользователей.
- В команде нет выделенного аналитика. Что происходит с его работой?A)Она исчезает вместе с должностьюB)Её целиком берёт владелец продуктаC)Расходится по команде неявноD)Её выполняет внешний подрядчик
показать ответ и разбор
+C)Расходится по команде неявно// разбор: Требования всё равно кто-то выясняет, описывает и согласует: владелец продукта, тимлид, сам разработчик в переписке. Работа не исчезает, она становится невидимой и неравномерной. Риск в том, что при этом никто не отвечает за целостность картины, и противоречия между областями всплывают поздно.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.