Что такое бэклог и как его уменьшить

Писать про сложные вещи всегда легче, чем про простые. В первую очередь потому, что про простые вещи ты всегда думаешь “ну это же элементарно, это все знают, что тут вообще можно рассказать?”. А потом посмотришь как это “элементарное” кто-нибудь применяет – и сразу вспоминается вот эта картинка:

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

Возможно, какие-то моменты в тексте покажутся вам гипертрофированными, но, честное слово, я со всем этим сталкивалась на практике, иначе этого поста не было бы.

Что такое бэклог

Бэклог – это структурированный список актуальных задач, которые вам или вашей команде необходимо сделать, будь это функции в продукте, который вы разрабатываете, или обращения в техподдержку, которые вам необходимо выполнить. Ключевое слово тут – “актуальных”, а это значит, что бэклог регулярно пересматривается, изменяется и дополняется, чтобы соответствовать потребностям компании в текущий момент. Если упрощать еще больше, то бэклог – это просто аккуратно заполненная табличка с вменяемым и понятным всем членам команды описанием задач, статусом на текущий момент и выставленным приоритетом, которую команда регулярно отсматривает, выбрасывает оттуда то, что устарело, неактуально или несет слишком мало ценности относительно затрат времени или денег, отмечает то, что выполнено, и добавляет вновь появившиеся задачи.

Я против обобщений типа “бэклог – это только при разработке по SCRUM” или “бэклог нужен только в продуктовой разработке”. Бэклог – универсальная штука, необходимая не только в ИТ или в проектной деятельности, это инструмент упорядочивания и превращения в систему того, что “влетает” в вас и вашу команду из внешнего мира.

Правильный бэклог – бэклог, который управляется по определенному процессу, например, пришел запрос от пользователя -> добавили его в бэклог -> сделали экспресс-оценку (может ждать 3 недели до следующего ревью бэклога или шеф-все-пропало-делаем-ночью?) -> если может ждать, то забыли о нем до следующего ревью либо поставили задачу кому-то на прояснение деталей -> на регулярном ревью оценили и обсудили одновременно с остальными новыми (и старыми элементами) и выставили срок и приоритет.

Это, конечно, пример, процесс может выглядеть как угодно. Важно, что систематизированный подход позволяет как ничего не потерять из бэклога, так и оптимизировать трудозатраты, делая оценку для новых элементов с определенной регулярностью, а не по мере их поступления. Плюс элементы бэклога имеют свойство “отлежаться и стать неактуальными”, и вот это “время тишины” между поступлением и оценкой позволяет рассматривать их уже на холодную голову. А еще при просмотре полного бэклога уже сложнее начать истерить на тему “этот элемент надо сделать срочно”, так как перед глазами одновременно еще десятки или даже сотни таких же элементов, конкурирующих за время и ресурс команды.

У меня вот есть отдельные бэклоги рабочих и личных задач, из которого я “надергиваю” себе задач на спринт (рабочий спринт у меня – неделя, личный – месяц, причем личный связан с бэклогом мужа через чат-бот в телеграме). Но это прямо тема для отдельного большого поста про практики личной эффективности.

Бэклог можно вести в Excel или в специализированном ПО типа той же JIRA, главное – чтобы была возможность структурирования и минимального анализа элементов в этом бэклоге. Из чего следует, что бэклог в Word – это очень, очень, очень плохая практика, даже если элементы этого бэклога раскрашивать текстовыделетелем или делать в Word табличку. Хотя после недавно виденного бэклога большой корпоративной аналитической системы в Outlook меня уже сложно чем-то удивить, наверное.

Какие бэклоги бывают?

Как уже было упомянуто выше, бэклог как инструмент используется много где. Самые популярные бэклоги, которые можно встретить:

• Бэклог продукта – по-моему, само понятие бэклога в целом пришло из продуктовой разработки, это список всех “хотелок” пользователей, полученных из разных источников, например, от владельца продукта, через формы обратной связи, от самих разработчиков при наличии технического долга и проч. Часто именно про этот бэклог говорят, упоминая “бэклог SCRUM”.
• Бэклог спринта – те задачи, которая команда взяла и обязуется сделать или сделала в конкретный спринт.  Фактически – “большой” бэклог, отфильтрованный по текущему спринту. Номер спринта – обязательное поле для бэклога при разработке по SCRUM или чему-то скрамоподобному.
• Бэклог гипотез – чисто продуктовая история, когда на основе интервью, статистики, лучших практик и т.д. продакт-менеджер строит гипотезы, которые нужно проверить, например “добавим в авито кадастровый номер квартиры – и люди будут покупать их на авито охотнее, так как смогут убедиться, что эта квартира существует”. Количество гипотез в большом продукте может идти на десятки, и бэклог – единственный способ ими хоть как-то управлять.
• Бэклог команды – с момента, как я стала руководить проектными офисами и портфелями проектов, это стало моим самым популярным типом бэклога. Собственно, это бэклог, в который “сваливаются” все запросы, которые должна решить ваша команда, и неважно, что у вас за отдел – проектный офис, управление внутреннего аудита или направление финансовой отчетности.
• Бэклог обращений – типичная история техподдержки. Причем если инциденты все хоть как-то, но научились учитывать в ITSM-системах, то для запросов на изменение систем на поддержке у многих до сих пор старый добрый Excel.

Какая информация должна быть в бэклоге?

Программа минимум, чтобы бэклог можно было использовать без дергающегося глаза:

1. ID – часто уникальный номер элемента бэклога не добавляют, полагаясь на нумерацию строк в экселе. Но бэклог – штука живая, его дополняют, сортируют, меняют, и начинается “ну это вот тот пункт, где описана синяя кнопка” или “я же в письме номера перечислял три месяца назад, а здесь совсем другие”. В общем, ID – must have, сэкономит кучу времени и нервов.
2. Инициатор добавления элемента в бэклог – через месяц, максимум два, вы точно забудете, от кого пришел 52й элемент бэклога из 100 элементов, и при необходимости уточнить какие-то детали будете перерывать почту или тратить энергию на поиск каким-то другим образом. Лучше просто с самого начала указывать, от кого пришел элемент, это не раз вас выручит.
3. Дата добавления элемента в бэклог – то же самое, что в предыдущем пункт. Must have.
4. Краткое наименование – даже если тот, кто добавлял элемент в бэклог, все очень детально расписал (за что ему большое спасибо, конечно), то нужно все-таки описать пункт простой короткой фразой, например, “Просмотр оставшихся дней отпуска”. Дальше в работе ссылаться на нее будет намного проще, чем на многострочный текст. Кстати, сюда же хорошая практика – в начале этой короткой фразы указывать типа элемента, например “Добавить тот-то”, “Изменить то-то”, “Удалить то-то”. При груминге сэкономит вам время, так как сразу будет понятно, что делать и не придется лишний раз сверяться с подробным описанием.
5. Детальное описание – без комментариев. Если оно есть – отлично, если нет – значит, появится позже, но к моменту реализации оно точно должно быть.
6. Статус – крайне желательно, чтобы статус не писался “от фонаря”, а хотя бы выбирался из выпадающего списка. При большом количестве элементов в бэклоге эта практика очень пригодится вам при фильтрации, построении сводных таблиц и прочей простенькой аналитики. Кстати, правило про список универсально для любых условно-постоянных полей бэклога, например, номера спринта, в котором планируется реализация, ФИО инициатора (если таких инициаторов ограниченное количество) и т.д.
7. Срочность/критичность – что-то, что позволит сказать, брать этот элемент на рассмотрение в первую очередь или нет. Вот тут крайне желательно на соседней вкладке прописать, что же такое “Высокая” срочность, а что такое – “Критическая”, чтобы потом не оказалось, что это определяется по принципу “кто громче орет”, и чтобы не начали плодиться новые сущности типа “Сверхкритическая” или “Очень высокая”, в которых вы очень быстро утонете.
8. Комментарий – поле, в которое можно написать все, для чего нет отдельный полей. Пригождается всегда.

Наверное, это минимальный набор обязательных полей. Разумеется, он недостаточный для полноценной работы, просто остальные поля будут зависеть от специфики бэклога – если вы работаете по скраму, то там будут отсылки на эпики или оценки в сторипоинтах, если это бэклог запросов в техподдержку – то информация о затронутой системе или части системы, если это бэклог проектных инициатив – ФИО сотрудника, занимающегося проработкой, потенциальный бюджет и сроки и т.д. Вариантов миллион и, как правило, поля бэклога дополняются и актуализируются в ходе работы с ним.

Если тема бэклога вам близка, то много романтических подробностей для продвинутых РМов есть в посте про definition of ready, definiton of done и acceptance criteria.

Груминг и рефаймент  бэклога

Если не вдаваться в разборки между адептами скрама и других методов разработки, то, по большому счету, оба термина – груминг бэклога (backlog grooming) или “зачистка” бэклога (backlog refinement) про одно и то же – это регулярный пересмотр бэклога, уточнение его элементов (причем какие-то элементы при этом могут быть объединены в один, а какие-то – разбиты на несколько), определение их ценности и трудоемкости и проч.

Каждая команда организует это так, как удобно ей, пример того, как может выглядеть этот процесс, я приводила выше. В SCRUM вроде бы есть условный пункт о том, что работа с бэклогом – это около 10% времени команды, но, на мой взгляд, цифра может отличаться в разы в любую сторону в зависимости от процесса.

Как разобрать бэклог? Что делать, если бэклог накопился на годы вперед?

Вообще очень большой активный бэклог – признак непрофессионализма и неумения приоритезировать. Да-да-да, а не признак недостатка ресурсов, как вы уже, наверное, подумали. Ну потому что у профессионала всегда есть опция эскалировать недостаток ресурсов с конкретными расчетами и договориться либо об урезании бэклога и дальнейшем контроле объема по определенным принципам либо о выделении новых людей в команду. А жевать на каждом ревью по 1000 строк бэклога, про которые даже инициаторы этих строка уже пару лет как забыли – ну такое себе, лучше уж сразу на hh.

Собственно, это и есть рецепт – если видите, что бэклог стал огромным неуправляемым монстром и теперь на ревью вам нужно по несколько часов каждый раз, или команда на ревью грустно вздыхает и говорит “ну а смысл обсуждать еще раз это все” – с этим нужно что-то делать.

Волшебной таблетки нет, все, что вы можете – это:

• Провалидировать актуальность – может, инициаторы уже не работают в компании, или им эта задача сто лет как не нужна.
• Проверить на дубли – может, каждый 5й запрос – про одно и то же?
• Посчитать трудоемкость и длительность выполнения всего бэклога с учетом динамики прироста новых задач – может, за полгода вы с командой с этим справитесь при грамотном планировании, хотя на первый взгляд кажется, что тут очень много? А, может, несколько овертаймов и работ в выходные вас спасут, и у вас как раз в команде есть Степан, который с удовольствием выйдет за двойную оплату? К слову о динамике прироста – с цифрами вообще сложно спорить, поэтому чем более подробная картина об источниках задач у вас есть – тем лучше. Может, 90% бэклога вам генерит условный административный отдел, и достаточно просто временно их забанить как неключевое подразделение?
• Определить критерии удаления из бэклога (например, принять волевое решение, что для разгребания этих авгиевых конюшен вы год не будете делать ничего, связанного с дизайном и эстетикой) – тут уже понадобится магия посильнее, так как придется объяснять заказчикам, а может и согласовывать с ними, почему цвет кнопок теперь не в приоритете, но менеджерская доля – она такая.
• Применить систему приоритезации типа MoSCoW, Kano или любую другую, подходящую для вас, и выпилить из бэклога все с низким приоритетом. В самом простом варианте –  хотя бы оценить Value/Effort и двигаться от этого.

В комплексе это обычно срабатывает.

Мой внутренний голос говорит, что лично мне комфортно с бэклогом на полгода вперед, но, думаю, тут у всех свои границы.

Пример бэклога

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

Вот и все, что я могу сказать про бэклог, если вы нашли хоть что-то новое – значит, пара часов на пост была потрачена не зря.

Полезно? Нужны еще такие посты про базовые вещи или нет? И, если нужны, то про что было бы интересно почитать?