Залог плодотворной работы в течение квартала - эффективное планирование. В квартальном планировании участвуют все члены продуктовой команды, техлиды и заинтересованные лица. Основными этапами каждого планирования являются:
- постановка целей и задач на квартал, обзор задач прошлого квартала
- анализ причин задержки поставки или невыполнения задач прошлого квартала
- распределение задач на квартал по спринтам и исполнителям
- выявление и фиксация рисков
Ключевую роль при подготовке к планированию играет аналитик команды, т.к. ему необходимо описать задачи команде разработки в таком объёме, чтобы команда разработки смогла оценить трудовые и временные затраты, необходимые на их реализацию. Для этого аналитику предстоит:
- определить вместе в командой Discovery (1) задачи, которые следует взять в планируемом квартале
- понять, какова пользовательская и бизнес-ценность фичи
- выделить среди них те, по которым необходимо провести UX-исследование
- определить зависимости
- определить метод декомпозиции фичи
- проработать пользовательский путь
- сформулировать функциональные/нефункциональные требования
- определить потенциальные риски
Каждый из этих аспектов представляет собой отдельную тему для изучения, но давайте попробуем выделить главное.
(1) Discovery Team - команда, которая занимается поиском точек роста в продукте, наполнением бэклога смыслом, проверкой гипотез, созданием MVP, выпуском или перестройкой продукта.
Выбор задач
На старте планирования квартала необходимо определить, какие задачи имеют наивысший приоритет. Основываясь на оценке команды Discovery следует выделить N задач с наивысшим приоритетом.
Для оценки приоритета могут быть использованы различные методы, такие как MoSCoW, Кано, Story Mapping, Feature Buckets, KJ, ICE/RICE и т.д. Выбор метода представляет собой отдельную тему, поэтому не будем останавливаться на этом.
Более интересным является то, каким образом следует выбрать количество задач, отбираемых для дальнейшей проработки (N). Здесь следует руководствоваться емкостью команды в предыдущие кварталы и собственным опытом, т.к. новые задачи на текущем этапе еще не оценены. Из личного опыта могу посоветовать брать с запасом две-три задачи, чтобы не пришлось в последний момент прорабатывать новые фичи.
Определение ценности
Перед тем, как приступать к анализу фичи, необходимо в первую очередь определить, какова её пользовательская и бизнес-ценность, т.е. что данная реализация принесет стейкхолдерам и конечным пользователям. Для получения ответа на эти вопросы идеально подходит написание пользовательских историй (User Story, US). Таким образом вы сразу определяете действующие лица (роли). И для каждого из них определяете получаемую выгоду от реализации рассматриваемой фичи.
А нужен ли эксперимент?
После того, как определен список потенциальных задач, необходимо определить, для каких задач следует проводить UX-эксперимент. Это целесообразно делать в том случае, если в рамках задачи планируется вносить изменения в пользовательский путь. UX-исследование позволит определить, насколько новый путь будет понятен пользователю, будет ли востребована планируемая фича.
От кого мы зависим?
Немаловажным фактором при подготовке к планированию является определение зависимостей от внешних команд, изменений в законодательстве, изменений в составе команды и т.д.. Если в следующем квартале потенциально имеются задачи, реализация которых зависит от закрытия связанных задач, то необходимо учесть следующие аспекты:
- Когда связанная задача должна быть взята в работу смежной командой?
- Насколько сильно мы зависим от выполнения связанной задачи? Мы можем проводить подготовительные работы до выхода в прод связанной задачи? Например, можем ли договориться со смежной командой о контрактах, чтобы реализовать свою часть работ независимо от коллег?
- Каков приоритет у зависимой задачи? Можем ли мы взять в работу задачу только после того, как связанная задача будет готова?
И ещё один немаловажный вопрос, который стоит иметь в виду - “Какова вероятность, что задача будет взята в срок?”.
Вам, как аналитику, в первую очередь нужно иметь ответы на эти вопросы перед началом планирования, чтобы учесть все риски и избежать сдвига запланированных вашей командой сроков.
Декомпозиция
После того, как вы вместе с владельцем продукта определили пользовательскую и бизнес-ценность фичи, следует рассмотреть её на предмет возможной декомпозиции. Разумная декомпозиция позволит:
- уменьшить размер каждой отдельной задачи, а, значит, снизить Total Time, Lead Time и SLA команды;
- распараллелить работу в рамках одного эпика между несколькими разработчиками - следовательно, Пользователь получит бизнес-ценность всего эпика гораздо быстрее;
- заранее подготовить некоторые функции, провести интеграцию с внешними системами, что также сократит общее время реализации эпика.
Для декомпозиции эпика существует много разных известных методов. Среди наиболее популярных можно выделить особо полюбившиеся мне карты пользовательских историй (User Story Map), декомпозицию на основании критериев приемки, разделение историй по различным типам операций (CRUDL) и т.д.
Самое главное - в процессе декомпозиции не забыть, что каждая составляющая разделенного процесса должна представлять собой законченный функционал, который уже можно использовать и который отвечает критериям Definition of Done (2).
(2) Definition of Done - согласованный командой разработки список критериев, которые должны быть соблюдены, чтобы признать элемент бэклога выполненным, т.е. реализованным так, как предполагалось изначально.
Проработка сценария
Итак, мы определили, зачем нам нужна эта фича, провели её декомпозицию, если и насколько это было возможно. Теперь необходимо проработать пользовательский путь. Во-первых, стоит определиться с отправной точкой, т.е. на каком шаге карты пользовательского пути (Customer Journey Map, CJM) будет находиться Пользователь, когда соприкоснется с новой фичей. Затем нужно определиться, какие шаги будет проходить Пользователь для получения своей пользовательской ценности. При этом необходимо учитывать все альтернативные сценарии. На данном этапе для детальной проработки UX вы можете подключить к работе дизайнера.
Формулировка функциональных/нефункциональных требований
Здесь мы не говорим о детальном описании требований, но сформулировать основные моменты уже нужно. Для чего? Чтобы команда разработки могла представлять масштабы реализации и дать свою оценку. Следует сразу учесть нужно ли будет разрабатывать новые методы API, вносить изменения в текущие, придется ли вносить изменения в архитектуру или БД и т.д.
Подробно описывать требования мы будем при подготовке отдельных задач к разработке.
Что нам может помешать реализовать наши планы?
Для того, чтобы планирование было максимально эффективным, на этапе подготовки необходимо максимально определить возможные риски. Это могут быть, как внешние, так и внутренние риски. Они могут иметь различные масштабы влияния. Для определения критичности каждого из них следует построить матрицу рисков, на основе которой будет определен план управления рисками.
Вывод
Для того, чтобы планирование прошло максимально эффективно, аналитик должен собрать информацию о функциональности, которую мы планируем реализовать, в том объеме, который позволит команде разработки оценить, сколько усилий потребуется для вывода фичи в продакшн.
Остаётся только один вопрос: когда стоит начинать подготовку, чтобы всё успеть? Для определения сроков очень рекомендую воспользоваться диаграммой Ганта, например, в таком исполнении (здесь Вы можете подставить свои данные в таблицу и построить на их основе диаграмму):
В завершение хочу пожелать Вам удачи и напомнить, чтобы при планировании Вы не забыли составить список задач по аналитике!
Текст: Ольга Макарова
Редактор: Татьяна Курсина
Фото: найдены на просторах Сети
