Что общего у беклога продукта и испанской инквизиции?

Любителям “Monty Python” посвящается.

 

Nobody expects the Spanish Inquisition

 

Monty Python

 

Есть всего одна вещь, которая важна при работе с беклогом продукта: он должен быть.

 

Пожалуй, это ключевая вещь, которую можно сказать о беклоге продукта – или проще «списке работ по продукту», таком себе to-do-листе.


И ещё есть вторая вещь, которая важна, когда речь идет о беклоге продукта – это его доступность. Он должен быть, во-первых, написан понятным всем языком предметной области без лишней детализации и скрупулезности, а, во-вторых, должен быть физически доступен всем, кому с ним нужно работать: заказчикам, стейкхолдерам, команде. Он должен быть олицетворением прозрачности процесса.

Итак, есть всего две вещи, которые важны в беклоге: его наличие и его доступность.

Коллективность. Вот пожалуй еще одна самая важная третья вещь. Три вещи важны, когда мы говорим о беклоге: коллективность, наличие и доступность.

Под коллективностью я понимаю то, что содержимое беклога должно рождаться во время коллективных сессий-штурмов.

 

Основными инструментами для такой работы могут служить:

а) карты пользовательских историй (user story mapping), построенные заказчиками на досуге;

б) карты влияния (impact mapping) – инструмент принятия бизнес решений заказчиками;

в) менее формальные описания целей и идей продукта.

 

Но, независимо от того, что послужило источником для составления беклога, важно, что написание элементов беклога (часто их называют "user stories", но, вы же помните, что Скрам не предписывает какого-то конкретного формата требований) должно проводиться совместно – заказчиками и командой. Конечно, заказчики в этом процессе играют лидирующую роль. Они ведут этот процесс. И за него отвечают.

Почему важна коллективность?

Потому, что беклог продукта – это не инструмент работы с требованиями.

Это, пожалуй, четвертая вещь, которую стоит знать о беклоге наряду с его наличием, доступностью и коллективностью. Четыре простые вещи.

Беклог – это не инструмент работы с требованиями (как многие думают), это инструмент планирования.

Работая с ним, во времени и пространстве проекта встречаются заказчики и команды – два полюса проекта, без одного из которых процесс становится однобоким и хромым.

 

Заказчики в этом процессе ответственны за привнесение бизнес фокуса продукта.

Они витают над нуждами пользователей и гипотезами о том, как их проблемы-нужды можно решить. И не просто решить, а превратить решения в бизнес.

 

Команды же в этот процесс привносят реальность.

Они помогают заказчикам понять: какие технические варианты решений существуют; что можно сделать очень быстро, а что потребует исследований; какие ограничения имеют те или иные варианты; что можно продемонстрировать за первые несколько дней, недель, месяцы. Команды помогают заказчикам понять очередность работ и горизонты выпуска версий.

 

Беклог, а вернее даже сессии работы над ним, становятся сессиями стратегического планирования проекта. И нельзя переоценить их пользу для успеха проекта!

Тактическое же планирование проходит во время запуска итераций (в итеративном процессе, как Скрам) или во время just-in-time сессий планирования и дизайна (в не-итеративном или слабо-итеративном процессах, как Канбан или Скрам-бан).

Итак, запомните: есть четыре вещи, которые стоит знать заказчикам и командам о беклогах продукта.

Их наличие.

Их доступность.

Их коллективность.

И то, что они являются инструментом планирования и взаимодействия.

Четыре простые вещи.

И ещё динамика. Это, наверное, одна из тех вещей, которые очень важны для понимания философии беклога. Она обеспечивает планирование проекта в стиле накатывающей волны (rolling wave planning) – инкрементальных и итеративных усилий прояснения требований.

Беклог неоднороден. В верхней части беклога находятся идеи функционала, проработанные до мелочей. Команда может начинать над ними работать уже сегодня, чтобы через пару дней (часов) показать первую пробу (или выпустить в тестовую среду). Ниже идут более крупные, еще не проработанные в деталях идеи. Перед тем, как заказчик будет готов дать их команде в работу, над их прояснением еще предстоит посидеть.

Кто, кстати, будет за ними сидеть? Согласно третьему правилу «коллективности беклога» за превращением фич (идей продукта) в мелкие слайсы будут сидеть заказчики вместе с командой. Это будет повторяющийся, волнообразный процесс. Он и будет придавать динамику работе над беклогом, тем самым обеспечивая все его важные атрибуты: наличие, доступность, коллективность и функцию планирования.

 

Но что же общего у беклога и испанской инквизиции? Как минимум пять вещей.

Статья переопубликована с http://scrumguides.com.ua


Write a comment

Comments: 2
  • #1

    Vitalii (Friday, 16 September 2016 23:25)

    Алексей, отличная статья, спасибо ;) Поправь плз очепятку - там где юзер стори в скобочках - у тебя получились магазины пользователей вместо пользовательских историй :) З.ы. Мне почему-то больше нравится общее определение - PBI - это ведь не обязательно должны быть US :)

  • #2

    Krivitsky (Saturday, 17 September 2016 08:47)

    Привет, Vitalii!

    Good catch! Спасибо, конечно же PBI, конечно же не "магазины".