В разработке программного обеспечения важно не только создать хороший продукт, но и правильно организовать работу команды. Процессы должны быть выстроены таким образом, чтобы задачи закрывались стабильно и своевременно. Помочь выстроить командную работу помогает список задач (бэклог).
В этой статье подробно разбираемся в том, что представляет собой этот список, в чем его польза и как правильно с этим инструментом работать, чтобы достичь высот в управлении проектами.
Бэклог
Говоря простыми словами, бэклог (от англ. backlog) — это список задач или требований, которые нужно выполнить в рамках проекта или разработки программного обеспечения. Он широко используется в различных методологиях управления проектами — от каскадной модели до метода Канбан (Kanban).
Изначально сам термин возник в производственной сфере. «Бэклогом» называли накопившийся запас невыполненных заданий или заказов — примерно то же самое, что сейчас называется «техническим долгом». С распространением практик проектного управления в IT-сфере бэклогом стали называть список задач и возможностей, которые нужно реализовать в продукте.
В отличие от производственной сферы, список задач в IT отличается динамикой. В течение жизни проекта список требований постоянно обновляется и меняется в зависимости от потребностей заказчика и изменений внешних условий. Какие-то задачи теряют актуальность и покидают список, а на их место могут приходить новые или не приходить вовсе.
Значение списка задач для проекта
По факту список задач (backlog) — это не просто конкретный перечень задач, а настоящее сердце вашего проекта. Он отличается рядом важных особенностей:
- Список помогает команде четко планировать свою работу. В нем собраны все задачи и требования. Поэтому команде проще выбрать, на чем сосредоточиться в настоящий момент, а также спланировать свою работу на день, неделю или месяц.
- Список способствует прозрачной коммуникации в команде. Доступ к нему у команды общий. Соответственно, каждый участник команды знает, чем кто занимается. Это помогает избежать недопониманий в работе. Например, выполнения одной задачи разными людьми.
- Еще одна особенность списка — его гибкость и динамичность. В традиционных методиках планирования все задачи, а также их исполнители и методы решения определяются заранее. В свою очередь, перечень задач (backlog) постоянно обновляется и адаптируется к изменяющимся условиям и потребностям заказчика. Поэтому команда быстро реагирует на изменения — переключает фокус на новые направления работы или отказывается от некоторых планов.
Чем список (бэклог) отличается от плана проекта?
Основное различие между ними заключается в их функциональности. Как уже замечено ранее, бэклог (backlog) — документ динамический, и в процессе разработки продукта он меняется. В нем уже заложена вероятность изменения требований клиента/заказчика.
План проекта чаще всего создается на начальном этапе и меняется только в экстренных случаях. Как правило, в этот документ включают конкретные сроки работ, количество ресурсов, а также бюджет проекта.
Еще одно важное отличие — цель этих документов. Список создается для непосредственной работы с ним и ведется непрерывно. А вот план проекта чаще всего пишется для дальнейшего согласования. Например, с клиентом или руководством.
Список задач (backlog) в контексте Agile
В гибких методологиях список требований — это ключевой документ, с помощью которого владелец продукта контролирует разработку. Этот список служит фундаментом для планирования и управления работой команды.
Основные компоненты списка
Список задач и требований это сущность комплексная. Она состоит из множества элементов, которыми команда постепенно наполняет список. Как правило, выделяют 3 разновидности элементов:
- Пользовательские истории — краткие описания функционала продукта с точки зрения конечного пользователя. Отвечает на вопрос «что должно быть в продукте».
- Задачи — это конкретные шаги, действия или операции, которые нужны для реализации пользовательских историй. Кратко — «что нужно сделать».
- Ошибки — какие-либо проблемы, которые обнаружились в процессе работы над продуктом и требуют исправления. В контексте разработки софта под ошибками чаще всего подразумеваются баги. Проще говоря, «так быть не должно».
Это наиболее распространенные типы элементов списка, которые используются в разработке ПО. Важно иметь в виду, что подойдут они далеко не для всех проектов.
В некоторых командах граница между «Задачами» и «Ошибками» может носить условный характер. Например, если верстальщику для правки достаточно будет отредактировать пару строчек кода, то ошибка на серверной части уже может потребовать отдельной задачи на несколько часов работы.
В зависимости от сферы бизнеса или рода деятельности команды, вы можете создавать свои типы элементов — будь то всевозможные разновидности «ошибок» или даже сделки.
Как вести список (backlog)?
Каким бы простым не казалось формирование списка, нельзя просто взять и добавить в него все задачи и требования заказчика. Опять же перечень требует постоянного взаимодействия команды — не только между собой, но и с заказчиком. Чтобы корректно сформировать список (backlog), следует придерживаться нескольких простых принципов.
Понимание потребностей пользователей
Если речь идет о разработке продукта, список должен отражать реальные потребности пользователя и решать его проблемы. Для этого необходимо активно вовлекать заказчиков и конечных пользователей в процесс формирования перечня. Например, собирать с потенциальных пользователей обратную связь, проводить продуктовые исследования или глубинные интервью.
Приоритизация задач
Задачам в списке нужно периодически расставлять приоритеты в соответствии с их важностью и ценностью для достижения целей проекта. Это помогает команде сосредоточиться на выполнении наиболее важных задач.
Для приоритизации задач существуют разные методики — например, матрица Эйзенхауэра или модель «Влияние — Уверенность — Простота» (ICE Scoring). Подробнее о способах приоритизации задач мы рассказываем в этой статье.
Декомпозиция
Задачи должны быть понятными и выполнимыми. Для этого крупные задания следует декомпозировать — разбивать на маленькие. Так вы упростите работу над проектом для исполнителей задач и увеличите прозрачность работы. Участники команды смогут быстрее понять, что нужно делать, а руководитель — увидит и поймет, чем заняты его подчиненные.
В идеале задачи лучше формулировать по системе SMART. Это методика постановки целей, которая помогает максимально упростить и в то же время конкретизировать задачу для исполнителя. Задача по SMART должна быть:
- конкретной — заключаться в конкретном действии;
- измеримой — иметь конкретный результат;
- достижимой — проще говоря, выполнимой;
- значимой — приближать к выполнению цели проекта;
- ограниченной во времени — чтобы не потерять актуальность.
Основные правила управления бэклогом
Регулярное обновление
Требования к продукту могут меняться — из-за новых тенденций рынка, изменения позиционирования продукта или поведения конкурентов. Поэтому, чтобы список не терял свою актуальность, его нужно регулярно обновлять и корректировать.
Новые задачи могут появляться хоть ежедневно. Например, если небольшая ошибка раскрыла команде некую фундаментальную проблему внутри продукта.
Прозрачность и доступность
Список должен быть доступен всем участникам команды для просмотра и обсуждения. Чем он прозрачнее, тем лучше команда будет понимать цели проекта, и тем выше будет уровень ее вовлеченности.
На практике это правило заключается в следующих моментах:
- любой из участников проекта может в любой момент посмотреть, какие задачи взяты в работу, а какие ждут своего часа;
- исполнители похожих или взаимосвязанных заданий могут работать вместе;
- снижается риск двойной работы — задачу не возьмут в работу, если ей кто-то уже занимается.
Коллективное принятие решений
Решения о расстановке приоритетов и изменениях в бэклоге должны производиться коллективно — при участии заказчика и разработчиков. Это помогает обеспечить:
- баланс интересов заказчика и команды;
- актуальность бэклога и его соответствие целям проекта.
Чтобы обсудить и пересмотреть содержимое бэклога, команда проводит соответствующие мероприятия. Например, в модели Скрам (Scrum) по окончании каждой итерации проводится обзор спринта. В методе Канбан (Kanban) для этих целей используются каденции — периодические встречи, в рамках которых команда определяет, на каком типе задач следует сосредоточиться.
Обратная связь
Чтобы корректировать и дополнять бэклог в соответствии с изменяющимися требованиями и ожиданиями, команда поддерживает постоянную связь с заказчиком и/или конечными пользователями.
Например, если заказчик заметил, что конкуренты изменили позиционирование продукта, он сообщает об этом команде. Далее участники разработки совместно решают, отразится ли это на их собственном продукте, следует ли взять в работу новые задачи с учетом этих изменений.
Итеративный подход
Лучше всего бэклог работает в сочетании с итеративным подходом. Например, в моделях управления Скрам (Scrum) и Скрамбан (Scrumban), где используются спринты. За счет планирования следующих итераций команда пересматривает и обновляет список на основе текущих приоритетов и полученных результатов.
Например, владелец продукта учитывает, каких результатов добилась команда в предыдущем спринте, достигла ли она поставленных целей. Если же последние не были достигнуты, то команда оценивает, сколько задач ей досталось «в наследство» в качестве техдолга. На основе этой информации команда решает, сколько времени следует заложить в следующей итерации, чтобы и закрыть техдолг, и достичь актуальных целей в срок.
Анализ данных и метрик
Использование данных и метрик процесса разработки помогает оценивать эффективность работы над задачами в бэклоге и принимать взвешенные решения о его дальнейшем развитии.
Этапы формирования списка
- Определение целей проекта. Фактически этот этап начинается с постановки ТЗ и плана проекта. Будущая команда уже должна четко понимать цели и ожидания заказчика.
- Сбор требований. На этом этапе собираются все «хотелки» от заказчика, пользователей и других заинтересованных сторон. Это могут быть пользовательские истории, функциональные и нефункциональные требования или конкретные задачи. На этом этапе проводятся также продуктовые исследования.
- Приоритизация. Полученные требования приоритизируются по значимости. Из требований и пользовательских историй начинают формироваться задачи. Наиболее важные из них распределяются по первым итерациям проекта.
- Декомпозиция. Большие и сложные задачи разбиваются на мелкие и управляемые подзадачи. Ими уже наполняют первые спринты.
- Оценка и присвоение баллов сложности. Каждой задаче или требованию стоит присвоить оценку сложности или объем работы. Например, в часах, человеко-часах или оценке сложности. Это поможет разработчикам понять, сколько времени и усилий потребуется на ту или иную задачу, а также планировать свой рабочий день.
- Обновление и актуализация. Список должен постоянно обновляться, чтобы соответствовать меняющимся требованиям и другим условиям проекта. Команде надлежит регулярно проводить соответствующие обзорные мероприятия. В рамках этого мероприятия добавляются новые задачи, уточняются требования и изменяются приоритеты.
Типичные ошибки ведения списка (и как их избежать)
- Непонятные или неоднозначные требования. Как говорится, «каков бриф — таков и креатив». Непонимание требований — это некорректные ТЗ по задачам, неверные результаты, бесконечные правки и ошибки в продукте. Все это стоит проекту времени и ресурсов. Убедитесь в том, что вы говорите с заказчиком на одном языке, а команда понимает, что от нее ожидают.
- Переполненный список. Раздутый список задач может затянуть процесс разработки и сбить фокус команды. Проверьте, все ли элементы списка актуальны — устаревшие или ненужные можно удалить.
- Недостаточная приоритизация. Если задачи в списке не имеют четких приоритетов, команда будет просто терять время. Проводите регулярные обсуждения с заказчиком, чтобы уточнить приоритеты проекта.
- Отсутствие обновлений. Если список не обновляется или обновляется редко, он быстро устаревает и уже не соотносится с реалиями проекта. Избежать этой ошибки помогут периодически обзоры списка и обсуждения с заказчиком.
Инструменты для ведения перечня задач
Список задач должен быть доступен для всей команды. А для прозрачности рабочих процессов список обычно используется в связке с доской для задач. Ведь именно оттуда на на нее попадают элементы списка.
Держать весь объем требований к проекту можно в уме или в рабочих документах. Но лучше использовать специальные инструменты для ведения бэклога.
Физическая доска с карточками
Наиболее простой и архаичный способ ведения списка задач. Это может пробковая доска со стикерами на кнопках или маркерная доска, на которой команда пишет названия задач и этапы их выполнения. Способ не самый удобный — нужно много канцелярских принадлежностей, кнопки теряются, а бумажные карточки быстро приходят в негодность.
Таблицы Excel или Google Sheets
Пользовательские истории и задачи с оценками можно хранить в электронном виде — с помощью простых таблиц. Удобство этих инструментов заключается в том, что можно использовать формулы для подсчета продуктивности команды. Увы, на этом удобства таблиц заканчиваются.
Менеджеры задач
Это специальное ПО для управления проектами. Наиболее известные менеджеры задач — Jira и Trello. К ним также относится и наш сервис — Аспро.Agile.
В Аспро.Agile есть целый набор инструментов для систематизации списка (backlog):
- спринты для итеративной работы над проектов;
- вехи для крупных задач, выполнение которых требует нескольких итераций;
- метки для поиска задач и других элементов в списке;
- настраиваемые типы элементов списка для создания своих разновидностей задач.
А также:
- удобная настраиваемая доска для задач;
- модуль отчетов о продуктивности команды и отдельных ее участников;
- встроенный мессенджер для коммуникации без перехода в сторонние сервисы.
Таким образом, менеджеры задач — это не просто наиболее удобный инструмент ведения списка, но и полноценная среда для работы над проектами вместе с командой.
В каких проектах нужен список задач (backlog)?
Мы много говорим о том, что список задач используется в сфере ИТ. Но эта сфера бизнеса — неоднородная. Внутри нее существуют разные направления, в которых может различаться специфика ведения бэклога:
- разработка ПО;
- управление продуктом;
- техническая поддержка продукта.
Поскольку список задач — это мощный инструмент проектного управления, использовать его можно и за пределами ИТ-сферы. Особое распространение он получил в отраслях, где применяются гибкие методологии управления:
- маркетинг и реклама;
- образование;
- дизайн;
- банковское дело;
- проектное управление.
как инструмент, списки также можно использовать и в отрыве от гибких методологий. Особенно если специфика рабочих процессов и бизнеса позволяет придерживаться правил ведения списка. Например:
- образование;
- издательское дело;
- частное строительство.
Подводим итоги
Список (backlog) — это больше, чем перечень задач или какой-то документ. Это сущность всего вашего проекта. Он не только дает команде понять, над чем она работает, но и помогает выстроить прозрачный рабочий процесс.
Чтобы от списка была польза для проекта, его нужно правильно вести:
- требования к продукту — регулярно актуализировать;
- содержимое — обновлять, все устаревшее — удалять;
- обеспечивать доступ к списку всей команде, а решения об изменениях в нем — принимать совместно;
- сочетать с итеративным подходом — с проведением соответствующих ритуалов и мероприятий;
- расставлять приоритеты для всех элементов;
- сложные задачи — декомпозировать.
Правильно составленный список — это инструмент, который превращает команду в отлаженный механизм. Он также помогает минимизировать множество рисков бизнеса, сохранить ресурсы команды и сэкономить время всех участников проекта.
