Выстраиваем эффективное взаимодействие инженерной и продуктовой команд

[Steed]

Спасибо за хороший анализ.
Интересно, что у вас достаточно сильно развилась система постановки задач, при этом в ней до сих пор не появилась оценка трудоемкости задач на этапе планирования — у вас оценка ставится только при начале работы над задачей. А это ведь базовый прием — тот же planning poker в Scrum и т.п.
Уверен, что вы не могли его не попробовать на более раннем этапе. Более вероятно, что попробовали и, не получив ожидаемого результата, отказались. Если так, то можете поделиться опытом — какие были результаты, почему отказались?

[dsemenikhin]

Как я и написал в статье, предварительная оценка задач планируется в каком-то виде. Что нам мешает сделать это сейчас? То, что перед тем как мы приступаем к задаче, она должна пройти этап декомпозиции командой системных архитекторов. Там решается какая часть функционала будет реализована на сервере, а какая на клиенте. Также решается какой API будет необходим. Только после этого мы можем оценить затраты на разработку бекенда. Но у нас нет запаса уже декомпозированных задач для предварительной оценки, так как декомпозированная задача — почти наверняка приоритетная, и мы должны ее начать как можно скорее. Поэтому мы почти всегда пропускаем этап предварительной оценки и этим занимается разработчик перед началом работы над задачей. Если мы понимаем, что затраты на разработку явно превышают выхлоп от фичи, мы сообщаем об этом продукту. После этого принимается решение: делать как есть, не делать, делать, но с измененными требованиями. Т.е. у нас затраты времени на предварительную оценку перекочевали во время дополнительных согласований по задаче в момент старта работы над ней.

[KarinaTsar]

Спасибо за статью!
1. Кто входит в продуктовую команду кроме продуктовых менеджеров? Исследователи (какие?), маркетинг?
2. Как решаете проблемы, связанные с заморозкой задач (изменились приоритеты, продуктовая команда изменила после исследований / действий регулятора / etc.)? Due date в этом случае на время заморозки как-то обнуляется?
3. Почему не формируете кросс-функциональные инженерные команды вокруг продуктовых команд? Как я поняла из текста, у вас сейчас матричная структура и проблемы планирования возникают именно из-за этого размазывания продуктовых задач по функциональным отделам.
4. Когда применялась схема работы №3, как были приняты решения о распределении квот между командами? Вычислялась ли какая-то бизнес-составляющая (доходность, перспективность, важность для пользователя и т.п.) продукта, что влияло на приоритеты в выделении инженеров?

[dsemenikhin]

1. В продуктовую команду также входят также аналитики, дизайнеры и поддержка пользователей (это важно, потому что пользовательский фидбек — одна из основ для принятия правильных продуктовых решений). Команда маркетинга рядом, но отдельно.
2. Неактуальные «на сейчас» задачи просто пропадают с «радаров» разработки. Технически это просто снятие определенного лейбла с тикета после чего он исчезает из фильтров.
3. Формируются, если необходимо. Я написал об этом в главе «Важное дополнение»
4. Не понял вопрос. Вы про квоты между командами разработки? Их не было. Если про квоты на вертикаль, то решение принималось на уровне Директора по Продукту.

[mickvav]

Кстати, как соотносится количество ушедших более-менее навсегда в «неактуальное» состояние тикетов с количеством сделанных?

[acmnu]

Во-первых, спасибо за эту статью. А во-вторых, не могли бы вы рассказать больше о Jira, раз вы её применяете? У меня ощущение, что эта система только мешает в реальной работе, но похоже я не умею её готовить.

[dsemenikhin]

Пожалуй, это тема для отдельной статьи :)
Если есть конкретные вопросы, задавайте.
Чем именно мешает?

[acmnu]

В Jira версионность и спринты привязаны к проекту. В реальной жизни спринт это свойство скорее команды, чем проекта.

Получается, что есть у меня N проектов со своими версиями (например микросервисы), которые все входят в некий большой проект X, не обладающий версионностью (по факту). Каждый из N проектов обладает собственным множеством версий и чтобы это множество отобразить, мне надо использовать проекты. А реально разработка ведется на уровне большого проекта X. И спринты связанны с этим проектом и функционал в конечном счете относится к проекту X.

Получается, что вместо одной аджайл борды для X или нескольких борд для каждой команды, я получают N борд, каждая со своими спринтами. Методы объединения проектов через фильтры работают, но в целом коряво.

Единственное что работает, это отказ от трека версий чрез Jira. Т.е. просто забиваем на версионность. Но мне так делать нельзя: нужно четко понимать когда какая фича вошла в релиз.

[dsemenikhin]

У нас монолит в части php кода. И все тикеты соответственно в рамках одного Jira проекта. Версии мы не используем. Проблем с формированием спринтов и их ведением не испытываем. Спринт делается для всей команды, а дальше он фильтрами дробится на каждую рабочую группу.

[FlipWho]

интересненько