Comments 11
Спасибо за хороший анализ.
Интересно, что у вас достаточно сильно развилась система постановки задач, при этом в ней до сих пор не появилась оценка трудоемкости задач на этапе планирования — у вас оценка ставится только при начале работы над задачей. А это ведь базовый прием — тот же planning poker в Scrum и т.п.
Уверен, что вы не могли его не попробовать на более раннем этапе. Более вероятно, что попробовали и, не получив ожидаемого результата, отказались. Если так, то можете поделиться опытом — какие были результаты, почему отказались?
1. Кто входит в продуктовую команду кроме продуктовых менеджеров? Исследователи (какие?), маркетинг?
2. Как решаете проблемы, связанные с заморозкой задач (изменились приоритеты, продуктовая команда изменила после исследований / действий регулятора / etc.)? Due date в этом случае на время заморозки как-то обнуляется?
3. Почему не формируете кросс-функциональные инженерные команды вокруг продуктовых команд? Как я поняла из текста, у вас сейчас матричная структура и проблемы планирования возникают именно из-за этого размазывания продуктовых задач по функциональным отделам.
4. Когда применялась схема работы №3, как были приняты решения о распределении квот между командами? Вычислялась ли какая-то бизнес-составляющая (доходность, перспективность, важность для пользователя и т.п.) продукта, что влияло на приоритеты в выделении инженеров?
2. Неактуальные «на сейчас» задачи просто пропадают с «радаров» разработки. Технически это просто снятие определенного лейбла с тикета после чего он исчезает из фильтров.
3. Формируются, если необходимо. Я написал об этом в главе «Важное дополнение»
4. Не понял вопрос. Вы про квоты между командами разработки? Их не было. Если про квоты на вертикаль, то решение принималось на уровне Директора по Продукту.
Во-первых, спасибо за эту статью. А во-вторых, не могли бы вы рассказать больше о Jira, раз вы её применяете? У меня ощущение, что эта система только мешает в реальной работе, но похоже я не умею её готовить.
Если есть конкретные вопросы, задавайте.
Чем именно мешает?
В Jira версионность и спринты привязаны к проекту. В реальной жизни спринт это свойство скорее команды, чем проекта.
Получается, что есть у меня N проектов со своими версиями (например микросервисы), которые все входят в некий большой проект X, не обладающий версионностью (по факту). Каждый из N проектов обладает собственным множеством версий и чтобы это множество отобразить, мне надо использовать проекты. А реально разработка ведется на уровне большого проекта X. И спринты связанны с этим проектом и функционал в конечном счете относится к проекту X.
Получается, что вместо одной аджайл борды для X или нескольких борд для каждой команды, я получают N борд, каждая со своими спринтами. Методы объединения проектов через фильтры работают, но в целом коряво.
Единственное что работает, это отказ от трека версий чрез Jira. Т.е. просто забиваем на версионность. Но мне так делать нельзя: нужно четко понимать когда какая фича вошла в релиз.
Выстраиваем эффективное взаимодействие инженерной и продуктовой команд