UXR Пилоты
Правила пилотирования
| Тип задачи | Формат пилотирования | Ответственный за пилот |
|
Важные новые штуки — меняют значительную часть функционала или весь полностью |
1. Исполнитель ставит статус "Пилот", но не раскатывает таску. Определяется [тестовая группа с поимённым списком](https://bookstack.ally.software/books/uxr-piloty/page/ucastniki-testovyx-grupp "title")
3. Пользователи пилотной группы получают функционал (выкладывает релизный менеджер)
4. Исследователь и Продакт смотрят вебвизор, проводят сбор фидбэка, мониторят обращения в горячку |
UX-исследователь и Продакт |
|
Фичи и флоу — затрагивают UI — затрагивают привычный путь — связаны с данными (в т.ч. метрики для пользователей) |
0. Если считаются какие-то данные, они заранее проверены на этапе тестирования в каком-то визуальном преставлении, например — на графике в Retool.
1. Исполнитель формирует список ролей, которых затронет изменение и формирует неслучайную выборку — представители этих ролей в размере 10% от общего количества таких пользователей. Выборка формируется по id или алфавиту (например, для фичи 1 — все сотрудники с фамилиями на А или с id от 000001 до 000099). Важно, чтобы для каждой такой фичи это всегда были разные пользователи. |
UX-исследователь и Продакт |
|
Бизнес-логика — Добавление и изменение ролей — Изменение правил, ограничения |
1. Исполнитель формирует список ролей, которых затронет изменение и формирует неслучайную выборку — представители этих ролей в размере 10% от общего количества таких пользователей. Выборка формируется по id или алфавиту (например, для фичи 1 — все сотрудники с фамилиями на А или с id от 000001 до 000099). Важно, чтобы для каждой такой фичи это всегда были разные пользователи.
2. Фиксирует правила формирования такой выборки в шапке задачи и курирует раздачу изменений на проде.
4. Производит мониторинг обращения в ГЛ по темам, связанным с изменениями. |
Исполнитель основной + QA-спец из его команды |
|
Техтаски — Техдолг — Техулушения |
1. Исполнитель эмулирует на аналогах машин пользователей поведение, связанной с технической задачей
2. После — курирует раздачу изменений на проде, но только на роль Разработчик
3. Предупреждает об этом в чате Ally, чтобы все понаблюдали. Просит тестировщиков уделить этому побольше внимания |
Исполнитель основной + QA-спец из его команды |
|
Метрики для команды Внутренние данные для команды |
|
По завершении: собираем фидбэк и только если всё ок — раскатываем на всех.
Срок сборки фидбэка зависит от того, насколько часто используется функционал, которого касаются тех. изменения:
— Для частых — достаточно 1-2 дней
— Для использованных раз в 1-2 недели — ждём пару недель
— Для ежемесячных — ждём хотябы одной итерации использования
Исполнитель основной:
- не меняется, если просто подключается релиз менеджер для доставки функционала пользователям
- меняется, если подключается другой исполнитель по задаче, чтобы внести в нее какие-то существенные доработки для пользователя