«Нужен фильтр в каталоге». «Давайте добавим отзывы». «Покупатель не понимает, есть ли товар в наличии». Три предложения могут касаться одного сайта, но за ними стоят разные потребности. Если просто записать их друг за другом, разработчик увидит перечень пожеланий. Почему сначала нужно заниматься наличием, что именно изменить и когда возвращаться к отзывам, из такого списка непонятно.
В Гуси-Лебеди мы предлагаем начать с этих вопросов. Бэклог помогает собрать будущие изменения в одном месте и установить понятный порядок работы. Он нужен не для того, чтобы красиво оформить все идеи, а чтобы команда могла выбрать следующую задачу и объяснить свой выбор.
Бэклог (backlog) в продуктовой разработке представляет собой упорядоченный список работы, необходимой для развития продукта. В него могут входить новые функции, исправления ошибок, технические улучшения и исследования. Содержание меняется: появляются новые сведения, часть предложений теряет актуальность, а крупные пункты уточняют по мере приближения к реализации.
При этом запись в бэклоге ещё не означает обещание сделать её к определённой дате. Предложение может ждать исследования, оценки или решения. Для согласованного объёма работ и сроков нужны отдельные договорённости. Это особенно важно, когда заказчик видит свою идею в общем списке и считает, что её уже включили в ближайший выпуск.
Представим интернет-магазин, в котором команда обсуждает три изменения: отображение наличия товара, фильтр каталога и отзывы. На этом условном примере разберём, как превратить пожелание в задачу, сравнить его с остальными и проверить результат.
Бэклог продукта и бэклог спринта отвечают на разные вопросы. Первый показывает, какая работа нужна продукту. В Scrum за его управление и порядок элементов отвечает Product Owner, владелец продукта. Sprint Backlog включает цель спринта, выбранные элементы и план их выполнения; этот план создают и уточняют Developers. Эти определения закреплены в Scrum Guide. Назначать каждой идее исполнителя и подробный план сразу после её появления для этого не требуется.
Если команда работает без Scrum, можно вести обычную очередь доработок и отдельно фиксировать выбранную работу. Важно согласовать, кто принимает решения о приоритете, кто помогает уточнять требования и что означает каждый статус. Одно название колонки «спринт» не задаёт процесс всей команды.
Если вы ещё выбираете правила выполнения работы, начните с сравнения Scrum и Kanban. Здесь сосредоточимся на самих задачах: что записать, как выбрать следующую и как поддерживать очередь в актуальном состоянии.
Владелец продукта может поручить другим участникам описание и уточнение элементов, сохраняя ответственность за управление бэклогом. Это позволяет собирать технические вопросы вместе с разработчиками. А бэклог спринта не нужно замораживать до последней строки: план уточняют по мере появления новых сведений, сохраняя цель спринта. Если меняется объём выбранной работы, разработчики обсуждают его с владельцем продукта.
Дорожная карта, или roadmap, показывает направления и цели развития на более крупном уровне. Бэклог помогает разложить нужную работу на элементы. Например, направление «сделать выбор товара понятнее» может включать несколько разных изменений каталога. Даже если они связаны с одной целью, их не обязательно выполнять одновременно и с одинаковой подробностью описывать заранее.
Как превратить пожелание в понятную задачу
В нашем примере пожелание звучит так: «Показывать наличие понятнее». Сразу рисовать новый значок рано. Сначала нужно выяснить, где покупатель принимает решение, что сейчас видит и откуда сайт получает сведения об остатках. Возможно, проблема в подписи. Возможно, состояние вообще не приходит из учётной системы. Это разные работы.
Первую запись можно оформить как вопрос исследования: «Выяснить, какие состояния наличия получает карточка товара и как они отображаются покупателю». Результатом будет описание обнаруженных состояний, источника данных и возможных изменений. Такая задача не обещает исправление до того, как понятна причина.
После уточнения появляется задача реализации. Например: «Показывать доступность выбранного варианта товара перед добавлением в корзину». Название становится конкретнее, но для работы всё ещё нужны условия. Что показывать при нулевом остатке? Что делать, если ответ системы не пришёл? Меняется ли доступность при выборе другого размера? Ответы должны быть рядом с задачей, а не только в памяти человека, который её предложил.
Карточку ближайшего изменения удобно построить вокруг пяти вопросов:
- Для кого и зачем? Покупатель выбирает вариант товара и хочет понять, может ли его заказать.
- На каком основании? Ссылка на обращение, запись наблюдения или согласованное требование. Если основание только идея, так и обозначьте.
- Что должно измениться? Нужное поведение карточки в согласованных состояниях.
- Что связано с задачей? Источник остатков, варианты товара, корзина и ограничения обновления данных.
- Как принять результат? Проверяемые действия и ожидаемые ответы для каждого выбранного состояния.
Это пример полей, а не обязательная форма для любой команды. Для далёкой идеи хватит краткого описания и источника. Для изменения, которое скоро возьмут в работу, потребуется больше подробностей. Если одинаково подробно расписывать весь список, можно потратить время на решение, от которого позже откажутся.
Пользовательская история, или User Story, помогает выразить потребность: «Как покупатель, я хочу видеть доступность выбранного варианта, чтобы решить, можно ли его заказать». Но эта фраза не заменяет требования к состояниям и приёмку. Разобраться с потребностью глубже можно через Jobs to Be Done, а в карточке задачи сохранить конкретный результат этого разбора.
Как обсуждать приоритет без выдуманной точности
Теперь вернёмся к трём предложениям: наличие, фильтр и отзывы. Нельзя заранее объявить первое самым важным только потому, что мы выбрали его для примера. Нужны основания. Если проверено, что покупатель может оформить недоступный вариант, это один аргумент. Если речь лишь о более заметном значке, это другой. У фильтра тоже может быть сильное основание: без него человек не находит нужный товар в большом каталоге.
На обсуждении задавайте вопросы о результате и последствиях переноса. Какое действие пользователя затронуто? Есть ли обязательное условие запуска? Что уже подтверждено, а что предполагается? Какие другие задачи зависят от этого изменения? Как исполнители оценивают объём работы и неизвестные? Так сравнивать предложения полезнее, чем ставить всем отметку «высокий приоритет».
Отдельно запишите решение. Например: «Сначала исследуем обработку наличия, поскольку без проверки источника данных нельзя согласовать изменение карточки. Задачу фильтра готовим к оценке параллельно. Для отзывов уточняем цель и требования к модерации». Рядом сохраните основания выбора: тогда при новых сведениях команда сможет пересмотреть порядок, а заказчик поймёт, почему он изменился.
Приоритет не отменяет зависимостей. Важная задача может ждать доступа к данным или решения заказчика. Вместо молчаливого переноса укажите, что именно мешает, кто может снять ограничение и какую работу можно выполнить до этого. Иначе высокое место в очереди создаст ожидание быстрого выпуска, хотя начать реализацию ещё невозможно.
Числовая оценка помогает только при понятных исходных данных. Если неизвестно, сколько покупателей затронет изменение, не заменяйте это красивым баллом. Запишите неизвестное и способ его выяснить. Ожидаемый рост продаж также остаётся гипотезой, пока результат не измерен. Сам порядок строк не доказывает ни экономию, ни будущую выручку.
Для согласования состава ближайшего выпуска можно использовать MoSCoW. Разделите требования на обязательные для выбранного периода, важные, желательные и те, которые в этот период не включаете. Последняя группа не означает отказ навсегда. У обязательного требования должно быть объяснение: почему без него согласованный результат нельзя использовать. Эти категории описаны в руководстве Agile Business Consortium. Если всё объявлено обязательным, разговор о выборе ещё не состоялся.
Для сравнения улучшений с доступными данными подойдёт RICE, описанный Intercom. Метод учитывает охват за выбранный период, влияние на цель, уверенность в оценках и суммарные трудозатраты команды. Оценку получают, умножая первые три величины и деля результат на трудозатраты. Сравнивайте одинаковые периоды и единицы. В нашем примере сначала нужны сведения о том, сколько покупателей сталкивается с каждым сценарием. Без них расчёт лишь маскирует неизвестность. И даже высокий балл не отменяет работы, от которой зависит реализация.
Как готовить задачу к работе и проверять зависимости
Задача о наличии поднялась в очереди. Теперь важно проверить, сможет ли команда действительно её выполнить. Есть ли описание ответа учётной системы, макет состояний карточки и разрешённая среда для испытаний? Согласовано ли поведение при недоступном источнике данных? Кто ответит на вопрос, который возникнет во время разработки? Фраза «всё понятно» без этих материалов не помогает планированию.
Для нашего примера полезно заранее согласовать приёмку. Что увидит покупатель, выбрав доступный вариант? Сможет ли заказать отсутствующий? Обновится ли наличие при смене размера? Что покажет карточка, если учётная система не ответит? Для каждого случая запишите ожидаемое поведение и проверьте его отдельно. Так обсуждение «наличие должно работать» превращается в условия, по которым можно принять результат.
Крупное изменение можно разделить, сохранив связь частей. Исследование источника остатков, согласование состояний и реализация карточки дают разные результаты. Если разбить работу только на «написать код», «добавить стиль» и «проверить», отдельные строки мало расскажут заказчику о том, что он получит. Объясните общий результат и зависимости между частями.
Во время разработки веб-сервиса такой разбор помогает согласовать ближайший объём работ. Сама оценка остаётся за исполнителями, которые знают условия задачи. Не переводите относительный балл сложности в часы по произвольному коэффициенту и не считайте предварительную оценку обещанным сроком.
Уточнение элементов часто называют refinement, встречается и название grooming. Для очереди доработок это работа с формулировкой, размером задачи, вопросами и зависимостями. Не обязательно ждать отдельного совещания, чтобы приложить найденный документ или уточнить условие. При этом важные изменения требований и порядка должны быть видны участникам, а не оставаться в личной переписке.
Инструмент выбирайте по работе команды. Он должен позволять найти актуальную запись, увидеть порядок, связанные материалы, статус и историю решений. Таблица может подойти для простого процесса; при большом количестве связей стоит проверить возможности рабочего трекера. Проверяйте также доступы, экспорт и то, как команда будет поддерживать информацию. Название программы само по себе не делает задачу подготовленной.
Как пересматривать бэклог и закрывать выполненные задачи
Допустим, изменение карточки готово на тестовом стенде. Это ещё не означает, что его видит покупатель рабочего магазина. Разделите состояния, которые имеют значение для вашего процесса: подготовлено, прошло согласованную проверку, выпущено. Названия могут отличаться, но участники должны понимать, какой факт стоит за каждой отметкой.
Для завершённой работы сохраните связь с версией и результатом приёмки. В нашем примере это проверенные состояния наличия и существенные ограничения: например, проверка проводилась на тестовых данных. После выпуска нужна проверка в рабочих условиях в разрешённом объёме. Если обнаружена ошибка, заведите связанную запись с описанием фактического поведения, а не стирайте историю первоначального решения.
При пересмотре очереди сначала спросите, сохранилась ли потребность. Идея отзывов могла ждать решения о модерации; теперь оно принято, и задачу можно уточнять. Предложение фильтра могло стать частью другой инициативы. А два пункта о наличии могут оказаться дублем или описывать разные проблемы. Сравните их содержание, прежде чем объединять.
Устаревшее предложение можно архивировать с короткой причиной. «Отказались от этого сценария» объясняет решение; просто исчезнувшая строка его не объясняет. Для отложенной важной задачи укажите основание переноса и условие возвращения. Долгий возраст записи сам по себе не доказывает, что она бесполезна.
Задачи поддержки и технических улучшений также должны участвовать в обсуждении. У них может не быть заметного нового экрана, но должна быть понятна цель: устранить подтверждённую ошибку, обновить зависимость или подготовить дальнейшее изменение. Квоту времени и оплату таких работ согласуют в конкретном проекте. Универсального процента для всех сайтов нет.
При планировании доработок и сопровождения сайта держите рядом очередь предложений и выбранный объём ближайшей работы. Тогда можно объяснить заказчику, что обсуждается, что подготовлено, что выпущено и почему изменился порядок. Для оценки процесса фиксируйте причины блокировок, время ожидания решений и случаи возврата задач на уточнение. Сравнивайте сопоставимые условия, а не количество закрытых строк разного размера.
Начать можно с ближайшего изменения. Описать потребность, проверить источник, согласовать результат и поставить его в понятную очередь. В Гуси-Лебеди мы предлагаем именно такую проверку качества бэклога: следующий участник должен разобраться в задаче без восстановления всей истории из чатов. Когда это получается, список становится рабочим инструментом команды.