Как наполнять бэклог на поддержке — откуда брать фичи?

Стадия поддержки — неотъемлемая часть жизненного цикла разработки программного обеспечения (SDLC). Она гарантирует стабильность, функциональность и удовлетворение потребностей пользователей после выпуска продукта на рынок.

В посте про фичлист мы рассмотрели роль аналитика и ожидаемый результат его работы на этом этапе. Один из них — сформированный бэклог продукта, в котором задачи будут оценены и приоритезированы. А о том, как правильно его наполнить и где искать фичи, расскажем сейчас.

Продукт уже реализован. Откуда же опять берутся задачи для бэклога? Почему он никогда не пустеет?

Стадия сопровождения даёт нам четыре основных источника задач:

🟠 Новые пользовательские истории

Они поступают от стейкхолдеров. Конечно, важным источником задач для бэклога становится и экспертиза бизнес-аналитика. Он вовлечён в процесс поиска новых задач и определения их приоритетности.

Например, в процессе использования обучающей платформы, пользователи оставляют отзывы, что хотели бы смотреть лекции в записи. Так и появляется новая пользовательская история:

«Как студент, я хотел бы иметь возможность смотреть видео лекций в записях, чтобы проще адаптировать график под обучение»

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

— Сможет ли пользователь получить ожидаемую выгоду от этого решения?
— Будет ли это решение способствовать улучшению целевых метрик?
— Приблизит ли нас это решение к достижению бизнес-целей?

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

И всё же, даже ответив на все эти вопросы положительно, можно реализовать решение, которое будет иметь плохую обратную связь от конечных пользователей. К примеру, Яндекс.Маркет отменил «Рейтинг доверия продавца», внедренный в 2019 году. Причиной стали манипуляции с рейтингом и со стороны самих магазинов, и со стороны конкурентов.

🟠 Изменения в существующих требованиях

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

Важно добавлять идеи, даже если они кажутся непрактичными или несущественными. Продукт развивается и то, что кажется нереальным сейчас, может стать отправной точкой для новой функциональности в будущем.

Помним и об уважении к творческому процессу всех участников команды — добавление вообще всех идей в бэклог может стимулировать появление новых идей.

🟠 Исправление ошибок

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

🟠 Низкоприоритетная функциональность

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

Что в итоге

Стадия поддержки обеспечивает стабильность и функционирование продукта после его выпуска на рынок. И разумеется, даёт ряд источников задач для бэклога.

Таким образом, стадия поддержки — непрерывный и не ограниченный во времени процесс, который поддерживает работоспособность продукта и его соответствие требованиям рынка и ожиданиям пользователей.

#surf_analyst