И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».
![](https://habrastorage.org/r/w1560/webt/ib/yo/i1/ibyoi1o4o_tw9vzmq0blmbtoqtg.png)
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
![](https://habrastorage.org/r/w1560/webt/td/gy/ya/tdgyya2z1tb83owi12obeiklupo.png)
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
![](https://habrastorage.org/r/w1560/webt/vf/he/hj/vfhehjrnj8e4vr6flcx9xhiirs8.png)
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
![](https://habrastorage.org/webt/ib/yo/i1/ibyoi1o4o_tw9vzmq0blmbtoqtg.png)
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
![](https://habrastorage.org/webt/td/gy/ya/tdgyya2z1tb83owi12obeiklupo.png)
Где умирают пользовательские истории
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
![](https://habrastorage.org/webt/vf/he/hj/vfhehjrnj8e4vr6flcx9xhiirs8.png)
Как воскресить бэклог продукта, чтобы он стал идеальным?
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
- Начните с сокращения бэклога, если в нем уже более 20 пользовательских историй. Двадцать – это волшебное число, потому что оно способствует правильному режиму. Вы когда-нибудь смотрели ту серию Hoarders, где человек, по жизни очень успешный, не мог расстаться с тысячей банок из-под попкорна, которые он собирал десятилетиями? То же самое происходит и с бэклогом продукта по мере его роста. Мы эмоционально привязываемся к пользовательским историями, когда тратим свое время на их проработку, и нам уже становится трудно отпустить их. Для этого даже есть специальный термин «FOTO», который означает страх выбрасывания. Если вы сможете преодолеть этот страх, то ваше видение продукта станет более ясным, а ваша команда сможет сосредоточиться на будущем. Да и просто помните о том, что выбрасывать что-то на самом деле очень приятно.
- Добавьте свою дорожную карту и видение в бэклог продукта. По моему опыту, команды, которые не видят ничего дальше следующего спринта, чувствуют себя потерянными, лишенными мотивации, они тратят больше времени на переживания о том, стабильна ли их работа в целом, чем на проработку новых функций.
- Объедините все дорожные карты и бэклог вашего продукта в один список. Закон Конвея наводит нас на мысль о том, что использование разных инструментов для управления работой и стратегией, таких как JIRA для бэклога (ага!) и для дорожный карт – это плохая идея. Такой подход превращает бизнесы и организации, специализирующиеся на разработке, в подобие амбаров. Так сломайте эти амбары, увеличьте прозрачность и предоставьте своей команде контекст, который ей нужен для создания отличных продуктов. Чтобы это сделать – положите один единственный бэклог на видное место, и позаботьтесь о том, чтобы в нем было не больше 20 пользовательских историй.
- Используйте время, оставленное на доработку для создание идеального бэклога продукта, а не на создание пользовательских историй для следующего спринта.
- Рассказывайте об актуальном продуктовом бэклоге при обсуждении прогресса, например, при ревью спринта, чтобы ваши клиенты и руководители чувствовали себя комфортнее, и точно знали, где его можно найти.
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.