How-We-Managed-Huge-Number-of-User-Requests-on-One-Project-ru

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

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

В этой статье я расскажу, как мы решали эти проблемы на одном из наших проектов.

  • Проект заключался в (дальнейшей) разработке аналитической платформы, которая:
  • Позволяла общаться и создавать контент 21 тысяче авторов из разных стран
  • Обеспечивала аналитику на сайте компании и интеграцию с соцсетями и блогами
  • Охватывала аудиторию в 160 миллионов пользователей
  • Помогала сотням брендов и рекламных агентств проводить маркетинговые кампании, в которых активно участвовали десятки тысяч пользователей соцсетей и тысячи блогеров

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

Несколько слов о состоянии системы на момент начала работы:

 

Много модулей и функций Использовались в ежедневной работе более двадцати сотрудников отдела партнёрских отношений, редакционного и юридического отделов
Интеграция со сторонними системами
  • LifeFyre для управления пользовательским контентом
  • Gigya для управления идентификацией пользователей
  • KitchenSink для управления пользовательскими статьями
  • Piwik для аналитики
  • PubOps и Netsuite для управления финансами
Потребность в интеграции с новыми системами
  • PactSafe для управления контрактами
  • PredictionIO для аналитического прогнозирования
  • Google Analytics
Потребности пользователей в новой функциональности
  • Расширенный пользовательский поиск
  • Генерация рекламы и контента
  • Отслеживание платежей по кампаниям
  • Нотификации пользователей
  • Дашборды со статистикой по кампаниям для клиентов
Несоответствие системы бизнес процессам, которые изменились в результате новой бизнес стратегии клиента
  • Утверждение участников кампаний клиентами
  • Утверждение спонсируемых материалов клиентами
  • Новые требования к процессу регистрации членов сообщества
  • Автоматизация платежей
  • Проведение опросов потенциальных участников кампаний
Дефекты Минимум по 2-3 дефекта находили пользователи еженедельно

 

В результате всего этого появлялось множество запросов разной сложности и срочности от пользователей нескольких отделов:

 

Дефекты
В разных частях системы
Запросы о новых функциях
Для разных частей системы, в среднем по 4-5 заявок в неделю
Запросы о новых модулях

  • Запросы об изменении или добавлении целых новых модулей или процессов
  • На момент начала нашей работы на проекте таких запросов было около 20

 

Некоторые вещи уже были структурированы и запланированы в разработку, имелся также план разработки новых модулей:

 

Планируемые улучшения Новые модули
Улучшение управления публикациями в блогах Дашборд кампании для клиентов
Улучшение процессов опроса пользователей Утверждение участников кампании клиентами
Изменения в управлении электронными уведомлениями Утверждение контента клиентами
Изменения в настройках кампаний Унифицированный пользовательский поиск
Ребрэндинг

 

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

Запросов было так много, что сразу же создавать для каждого тикет в JIRA было бы неудобно — бэклог бы разросся и стал неуправляемым. А если бы стэйкхолдеры/пользователи присылали все свои запросы по почте (как они делали это раньше), слишком велик риск, что что-нибудь потеряется или забудется. Нам нужно было отдельное место для регистрации всех запросов, их обсуждения и хранения всех сопутствующих материалов по каждому из них.

Решено было использовать Trello для управления запросами пользователей до того как они «заслужат» стать задачами в JIRA. Мы создали несколько досок в Trello для основных групп пользователей из разных отделов:

Trello boards

Пример персональных досок в Trello

Запросы на создание новых модулей и значительные изменения существующих

Мы выслали приглашения  в Trello всем заинтересованным лицам и создали несколько списков с карточками для каждой доски. Больше всего помогли с обработкой запросов  следующие:

Lists on the Trello board

Списки для управления запросами на новые модули и значительные изменения существующих на доске в Trello

Big Initiatives

Это список глобальных, концептуальных изменений в системе; управлял им Product Owner. Карточки в этом списке содержали высокоуровневые описания функциональности, цели, известные блокеры и ограничения, фазы разработки, открытые вопросы, KPI, списки запланированных дел и комментарии.

Roadmap

Карточки из Big initiatives перемещались в этот список, чтобы показать, что и когда планируется отправлять в разработку. В карточки могли добавляться ключевые этапы реализации, план действий и другие необходимые вещи, а сами карточки можно было выстраивать в нужном порядке, например, по приоритетам для разработки. Мы также использовали метки со статусом каждой задачи в списке: «выполняется», «сбор требований» и т. д. — так наш roadmap оставался актуальным для всех, включая стэйкхолдеров.

Product Requirements

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

На данном этапе нам нужно было понять объём работ по задаче, основные компоненты новой функциональности и шаги по реализации необходимых изменений в системе. В результате мы могли разбить все требования на user stories и создать для них задачи в JIRA с соответствующим детальным описанием. После создания задачи вся коммуникация с пользователем по ней происходила в JIRA. При этом мы также могли использовать Trello, например, чтобы получить информацию от пользователей, которые не имели доступа к JIRA. После того как задачи утверждались стэйкхолдерами, они приоритезировались Product Owner-ом и постепенно добавлялись в разработку (в спринты).

Go to market

Карточки передвигались в Go to market, когда соответствующая функциональность была доставлена пользователям, а значит, все задачи в JIRA были выполнены. Поскольку это были полностью новые модули или значительные изменения в процессах и пользовательском интерфейсе, функциональность всех задач (user stories) должна была быть доставлена пользователям в одно время. Через несколько дней после запуска наши стэйкхолдеры могли оценить, как нововведения работают в реальном окружении— для обратной связи мы и использовали список Go to market.

Текущие запросы на изменения

Чтобы управлять регулярно поступающими запросами об изменениях, мы использовали такие списки:

Feature requests

Этот список использовался для управления запросами на мелкие изменения и новые функции. Мы научили пользователей создавать карточки с запросами и описывать проблему максимально ясно, упоминать Product Owner-а и бизнес-аналитика в карточках, прикреплять скриншоты, добавлять ссылки и другие материалы и быстро отвечать на уточняющие вопросы в карточках. После создания задачи в JIRA, я добавляла её ID в название карточки, чтобы задачу случайно не создали дважды. Вот пример реального запроса от пользователя:

Пользователю нужна была возможность прикреплять файлы к письмам, которые она создавала в системе и отправляла участникам маркетинговой кампании. Эта возможность была доступна при работе с другими типами кампаний, но отсутствовала в письмах, создаваемых для «экспертных» кампаний, с которыми работала пользователь.Ниже представлен скриншот созданной ей карточки: название, описание и приложенный скриншот кампании другого типа с нужной ей функцией. Мы задали несколько дополнительных вопросов, она получила оповещение и быстро ответила. Вся наша коммуникация — в секции Activity в карточке:

example of a small issue

В секции Activity хранится вся история коммуникации с пользователем

Bugs

Этот список похож на Feature requests, только здесь регистрировали найденные дефекты. Мы научили пользователей правильно описывать их — со скриншотами, ссылками и характеристиками  окружения, в котором найден баг – чтобы можно было  легко воспроизвести дефект у себя.

Example of a bug

Пример описания дефекта

Priority queue

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

Jira

Чтобы стэйкхолдеры понимали, что запрос уже в разработке, мы создали лист “Jira” — туда попадали карточки, добавленные в спринт. В название карточки в Trello мы добавляли ID задачи в JIRA.

Demo

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

UAT Done

После демонстрации пользователи проводили приёмочное тестирование (UAT) демонстрируемой функциональности, и соответствующие карточки переходили в список UAT Done. Через 1-2 недели мы отправляли карточки в архив, поддерживая таким образом список UAT Done коротким и актуальным.

Lists on the Trello board

Списки регулярных заявок об изменениях и дефектах

Диаграмма ниже показывает жизненный цикл карточки (карточки в Trello всегда перемещались вручную):

scheme

Советы, чтобы всё заработало

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

Убедиться, что все участники понимают процессы и свою роль в них

Всех заинтересованных лиц нужно научить пользоваться JIRA и Trello и объяснить, что происходит с их запросами на каждом этапе. Они должны знать, что делать, если им нужен новый модуль или функция, если они нашли дефект или когда возникли вопросы. Мы даже создали карточку «Как использовать доску» с инструкциями. Важно донести до всех участников процесса необходимость использования Trello и JIRA вместо электронной переписки, ведь тогда любому из них будет легко найти всю информацию об интересующем запросе.

“How to use the board” Trello training card

Проводить регулярные встречи со стэйкхолдерами/пользователями

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

  • Что было доставлено пользователям? Демо и обратная связь.
  • Что готовится к выпуску? Уточнение статусов задач и планов, пересмотр приоритетов при необходимости.
  • Вопросы к пользователям по их запросам.
  • Новые запросы и потребности пользователей.

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

Проводить предварительное планирование с Product Owner-ами (pre-planning)

За несколько дней до планирования следующего спринта мы встречались с Product Owner-м,чтобы пересмотреть бэклог и приоритеты задач в нём и убедиться, что самые важные задачи попадут в следующий спринт.

Демонстрировать новый функционал и собирать фидбэк

Фидбэк мы обычно собирали в форме чеклиста в соответствующей карточке Trello, и заполняли его прямо по ходу демонстрации, так что все участники могли видеть, что мы пишем. А так как участники были подписаны на обновления в Trello, они ещё и получали уведомления о результатах демонстрации, добавленных в карточку.

Example of demo feedback

В дополнение к коммуникационному аспекту, стоит отметить ещё одну вещь для организации эффективного процесса:

Для разных частей системы, разных аспектов проекта и типов стейкхолдеров удобно использовать разные доски. Мы, например, завели даже отдельную доску для управления задачами по дизайну системы.

В нашем случае, мы начали использовать доски Trello для управления запросами, до создания epics и user stories в JIRA. В итоге на проекте:

 

Уменьшился бэклог
  • Со временем, бэклог в JIRA уменьшился примерно на 15-20%, и работать с ним стало проще.
  • В JIRA попадали уже запланированные для разработки запросы с чёткими требованиями; до этого момента они хранились в Trello
Запросы не терялись
  • Запросы стэйкхолдеров перестали теряться
  • Вопросы к стэйкхолдерам теперь тоже не терялись — не нужно было искать письма и отвечать на них, пользователи просто шли в Trello, открывали созданную ими карточку и видели все обновления
  • Регулярные встречи с обзором досок Trello помогали убедиться, что мы не упускаем ничего важного.
Запросы стали обрабатываться быстрее Четко организованный порядок работы с запросами, понимаемый и соблюдаемый всеми вовлечёнными людьми, позволил сэкономить массу времени.