UXR Пилоты

Правила пилотирования

Тип задачи Формат пилотирования Ответственный за пилот

Важные новые штуки

— меняют значительную часть функционала или весь полностью

1. Исполнитель ставит статус "Пилот", но не раскатывает таску. Определяется [тестовая группа с поимённым списком](https://bookstack.ally.software/books/uxr-piloty/page/ucastniki-testovyx-grupp "title") 
   
2. Исследователь и Продакт информируют участиников тестовой группы и только потом сообщают о готовности раскатки 

 

3. Пользователи пилотной группы получают функционал (выкладывает релизный менеджер)

 

4. Исследователь и Продакт смотрят вебвизор, проводят сбор фидбэка, мониторят обращения в горячку

UX-исследователь и Продакт

Фичи и флоу

— затрагивают UI

— затрагивают привычный путь

— связаны с данными (в т.ч. метрики для пользователей)




0. Если считаются какие-то данные, они заранее проверены на этапе тестирования в каком-то визуальном преставлении, например — на графике в Retool.

 

1. Исполнитель формирует список ролей, которых затронет изменение и формирует неслучайную выборку — представители этих ролей в размере 10% от общего количества таких пользователей. Выборка формируется по id или алфавиту (например, для фичи 1 — все сотрудники с фамилиями на А или с id от 000001 до 000099). Важно, чтобы для каждой такой фичи это всегда были разные пользователи.
   
2. Фиксирует правила формирования такой выборки в шапке задачи и курирует раздачу изменений на проде.
      
3. Исследователь и Продакт смотрят вебвизор,  мониторят обращения в горячку

UX-исследователь и Продакт

Бизнес-логика

— Добавление и изменение ролей

— Изменение правил, ограничения

1. Исполнитель формирует список ролей, которых затронет изменение и формирует неслучайную выборку — представители этих ролей в размере 10% от общего количества таких пользователей. Выборка формируется по id или алфавиту (например, для фичи 1 — все сотрудники с фамилиями на А или с id от 000001 до 000099). Важно, чтобы для каждой такой фичи это всегда были разные пользователи.

 

2. Фиксирует правила формирования такой выборки в шапке задачи и курирует раздачу изменений на проде.
   
3. Предупреждает в чате эксплуатации и опционально ГЛ о том, что на часть пользователей пилотно раскатан определённый функционал, просит понаблюдать.

 

4. Производит мониторинг обращения в ГЛ по темам, связанным с изменениями.

Исполнитель основной + QA-спец из его команды

Техтаски

— Техдолг

— Техулушения

1. Исполнитель эмулирует на аналогах машин пользователей поведение, связанной с технической задачей 

 

2. После — курирует раздачу изменений на проде, но только на роль Разработчик

 

3. Предупреждает об этом в чате Ally, чтобы все понаблюдали. Просит тестировщиков уделить этому побольше внимания

Исполнитель основной + QA-спец из его команды

Метрики для команды

Внутренние данные для команды



По завершении: собираем фидбэк и только если всё ок — раскатываем на всех.

Срок сборки фидбэка зависит от того, насколько часто используется функционал, которого касаются тех. изменения:
— Для частых — достаточно 1-2 дней
— Для использованных раз в 1-2 недели — ждём пару недель
— Для ежемесячных — ждём хотябы одной итерации использования

Исполнитель основной: