Голоса вместо бэклога

Мы никогда всё это не закончим.

У нас готова презентация, что с ней происходит дальше? Прежде всего, она не попадает в очередь задач (бэклог).

Никакого бэклога

Мы считаем бэклог лишним грузом. В нём копятся десятки (иногда сотни) задач, на которые никогда не найдётся достаточно времени. Растущий бэклог создаёт ложное ощущение, что команды не успевают, даже когда это фактически не так. Не имеет смысла снова и снова натыкаться на задачу только потому, что несколько месяцев назад она показалась кому-то важной.

Бэклоги также сжирают невероятное количество времени. Вместо того, чтобы идти вперёд, посвящая время актуальным делам, вам приходится постоянно приводить в порядок устаревающие задачи.

Голосование

Если не бэклог, то что? Перед началом каждого 6-недельного цикла мы встречаемся и проводим голосование, на котором принимаем решения о том, чем заниматься в этом цикле. В обсуждение и голосование берутся презентации, созданные или переработанные в течение предыдущего цикла.

Больше ничего не обсуждается. Никаких бесконечных списков идей. Только несколько презентаций — хорошо сформированных, с продуманными рисками. Авторы «делают ставки» — выносят свои презентации на голосование.

Встречи получаются нечастыми, короткими и невероятно продуктивными. Если за презентацию голосуют, она передаётся в работу на следующем цикле. Если нет — работа над ней прекращается. И всё, никакого управления задачами.

Что если презентация всем понравилась, но время брать её в работу по каким-то причинам неподходящее? В этом случае автор (или любой желающий) может выставить её на следующее голосование через 6 недель.

Независимые списки дел

Если нет общего бэклога, неужели нужно держать всё в голове (а следовательно, всё время что-нибудь забывать)? Нет, каждый член команды ведёт учёт своих дел — презентаций, багов, запросов — так, как ему удобно, без централизации.

Например, у команды поддержки может быть собственный список типичных проблем. Продуктовая команда ведёт список идей, из которых формируются новые проекты. У разработчиков есть список багов. Нет единого списка, и никакие из этих списков не влияют на голосование и передачу проектов в работу.

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

Таким образом у каждой команды есть независимость (а значит, ответственность) в управлении своими приоритетами. Люди из разных команд могут и должны доносить до других команд то, что считают важным — любым удобным способом.

Ещё один плюс — разговоры становятся более своевременными. Конкретный человек выносит на обсуждение тему, важную для него именно сейчас по определённой причине (а не просто «разобрать бэклог»).

Важные идеи никуда не денутся

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

То, что действительно важно, вернётся к вам снова и снова. Во-первых, вам будет труднее про это забыть. Во-вторых, даже если это что-то не очень увлекательное (например, сообщение об ошибке), вам не дадут об этом забыть (например, жалобы будут продолжаться). Если идея всплыла в разговоре только однажды — вероятно, не такое уж это важное дело. А если вы продолжаете слышать о ней со всех сторон — явно стоит взять её в работу и сформировать проект.