Подготовили чек-лист из пяти шагов, которые позволят разобраться во всех поступающих задачах и ничего не забыть:
Шаг 1. Классифицировать поток задач
Неважно, создаете вы массовый продукт или персонализированный, всегда поступает огромное количество пожеланий/задач/предложений/доработок, которые нужно учитывать.
Для продукта с массовым потреблением количество таких запросов может составлять тысячи в год. Они могут противоречить друг другу, вынуждая команду делать выбор в сторону того или иного решения.
Чтобы разбираться в этом потоке задач было легче, в AppEvent внедрили классификацию задач:
Ежегодно в нашей компании проводятся стратегические сессии. На основе результатов выстраивается стратегия развития компании и каждого отдела на ближайший год. Для IT-отдела прописывается список задач, которые обязательны к разработке. Список формируется на основе целей компании, анализа конкурентов и результатов предыдущего года.
- Задачи от клиентов. Эту категорию задач мы делим на две:
- Задачи от отдела технической поддержки. Приходят от клиентов, которые уже пользуются продуктом какое-то время. Обычно нужна доработка уже существующего функционала, реже — разработка нового, когда компании нужно поддержать новые бизнес-процессы.
- Задачи от отдела продаж. Приходят от клиентов, которые только тестируют продукт или начали использовать его совсем недавно. Здесь примерно 90% задач приходится на разработку нового функционала.
Реализация задач от технической поддержки направлена на удержание клиентов, а задачи от отдела продаж — на привлечение новых. Приоритет удержание/привлечение определяется в рамках стратегии.
- Задачи от отдела разработки или техдолг
Сложно представить ИТIT-проект, в котором отсутствует техдолг. Часто на задачи этой категории закрывают глаза, хотя это может привести к проблемам с масштабированием и ограничениям работы существующего функционала. Поэтому рекомендуем не хранить задачи техдолга вечно, а реализовывать их с некоторой периодичностью.
Шаг 2. Сделать бэклог для бэклога
В бэклог еженедельно падают десятки, даже сотни задач. Там действительно легко потерять что-то полезное, даже если внедрить ежедневную приоритезацию. Как же ничего не упускать?
Мы делаем регулярную ревизию бэклога, исследуя задачи, появившиеся с предыдущей ревизии. Но мало просто отсматривать их. Если задачи смотрит один аналитик, помнит все о них только он. Если в команде несколько аналитиков, то каждый знает только о части задач и не обладает полной картиной.
Чтобы решить эту проблему, мы создали второй бэклог. В первый, общий, попадают все созданные задачи, во второй, бэклог разработки,— важные задачи, которые мы выявляем в процессе ревью общего бэклога.
Кажется, что риск потерять какую-то из задач остается, но при работе с системой команда не путается. Это обусловлено тем, что в бэклоге разработки лежит в разы меньше задач. Их проще приоритезировать, всегда держать во внимании и вовремя отдавать в работу.
К основному бэклогу мы возвращаемся снова и снова. Достаем из него задачи, которые в момент создания были неактуальными, но сейчас их приоритетность изменилась. Все они также отправляются в разработку.
Шаг 3. Определить, чего на самом деле хотят клиенты в запросе
Компании, реализующие массовый продукт, получают огромное количество пожеланий от клиентов. Люди хотят удобства для себя, но не всегда понимают, что продуктом пользуются не только они. Некоторые из запросов противоречат друг другу, некоторые закрывают потребность одного клиента, но мешают другим, а некоторые противоречат законам логики.
Чтобы справиться с большим количеством задач по доработке, при любом запросе от клиента стоит выяснять его проблему и основную суть пожелания. Для начала нужно выяснить: действительно ли нужно решать ту проблему, с которой пришел клиент. Может быть ему нужен совсем другой функционал? Это задача ребят из технической поддержки. Для них мы провели ряд внутренних митапов, где разобрали особенности формулирования “правильных” вопросов для выявления потребности клиентов.
Внедрение этой практики закрыло сразу две проблемы. Во-первых, ушли задачи, возникающие из-за неполного знакомства клиента и системы. Во-вторых, теперь задача всегда сформулирована так, чтобы ее реализация в действительности закрыла проблему. При отсутствии уточняющих вопросов клиент самостоятельно не всегда может корректно сформулировать запрос.
Шаг 4. Объединить продажи, поддержку и разработку
Все пожелания и задачи от конечного клиента поступают в отдел аналитики либо от поддержки, либо от продаж.
Соответственно, наши коллеги из этих отделов требуют ответов о возможности и сроках реализации задач. Логика понятна: требует клиент — требуют они. Однако ощущение давления на разработку от этого не снижается.
С этой проблемой может помочь только хорошо выстроенный процесс коммуникации между отделами.
Мы ввели общие чаты и митапы отделов и аналитиков компании, что позволяет:
- держать в курсе работы все отделы
- рассказывать о предстоящих релизах
- не задавать одинаковые вопросы
- информировать аналитиков о пожеланиях клиентов
- прислушиваться к мнению всех отделов компании
- работать над отношениями в команде, ведь только вместе у нас получится сделать продукт лучше
Шаг 5. Подключается ИТ-отдел
Задачи приоритезированы, ТЗ написано, спринты сформированы. Только теперь за дело берется ИТ-отдел.
В начале каждого спринта проходит встреча, где обсуждаются приоритеты задач к выполнению. Рассматриваются только задачи, попавшие в текущий спринт. Мы учитываем общий приоритет задачи, срок ее выполнения и комментарии, поступающие от команды.
Далее начинается работа над задачами: разработка реализует, тестирование готовит документацию к тестам. В процессе закрываются вопросы по ТЗ. В середине спринта мы проводим еще одну встречу для анализа его выполнения и переприоритезации задач. Обе эти встречи проводятся scrum-мастером в рамках контроля за выполнением спринта.
Все взаимодействие с командой разработки мы ведем исключительно через отдел аналитики и scrum мастера. Это позволяет практически исключить изменение приоритетов реализации из-за того, что “кто-то попросил сделать быстрее”.
Чек-лист приоритезации
