Переезд с Jira: как собрать требования пользователей и не утонуть в интервью. Ч3

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

Напомним, где мы находимся. Аудит для выбора системы состоит из 6 этапов:

1. Технический анализ — реальные цифры, а не хотелки пользователей ✓
2. Сбор требований бизнес-пользователей — и ещё надо понять с кого эти требования собирать ← мы здесь
3. Группировка и ранжирование требований и необходимого функционала
4. Проверка критичного функционала в системах-аналогах
5. Оценка миграции
6. Выбор системы

Технический аудит можно было сделать силами 2–3 администраторов. Здесь ситуация сложнее — нужно пообщаться с большим количеством людей и из нестройного рассказа получить реальные требования к системе.

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

Шаг 1. Выбираем проекты

Берём результаты технического аудита и смотрим на активность проектов. Нам нужны только живые — те, где работа идёт постоянно, а не раз в квартал.

Шаг 2. Категоризируем проекты

Группируем проекты по типу команды. В большинстве компаний, независимо от отрасли, есть типовые процессы. Например: разработка ведёт Scrum/Kanban и спринты, техподдержка работает с тикетами и SLA, управление проектами использует борды и Гантт, HR — кандидатов и онбординг, финансы и юристы — согласования и документы.

Смысл в том, что внутри каждого типа команды требования к системе управления проектами будут похожи — и не нужно опрашивать всех.

Шаг 3. Отбираем проекты для анализа

Из каждого кластера берём два проекта:

• Самый большой по активности — чтобы не упустить сложный функционал
• Один рядовой — для проверки, что мы правильно поняли портрет команды

Вместо 500 проектов получаем 8–12. Уже можно работать.

Шаг 4. Выбираем людей для интервью

Нам нужны не просто «те, кто работает в этих проектах», а люди с конкретной ролью. Интервью с пользователями при выборе системы — один из самых важных этапов, и от того кого вы позовёте, зависит качество требований.

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

Руководитель команды / тимлид — знает всё про отчётность, метрики и процессы команды.

Администратор проекта — знает настройки, воркфлоу, кастомные поля. Иногда совпадает с руководителем команды.

Шаг 5. Проводим интервью

Интервью — не больше 30–40 минут. У людей есть чем заняться.

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

Поэтому мы не спрашиваем «что вы хотите». Мы спрашиваем «что вы делаете каждый день» и «что вас бесит».

Назовите 3 сценария, которые вы выполняете в Jira каждый день.
Например: «Приходит баг → ставлю приоритет → назначаю разработчика → жду фикс». Так вы понимаете реальный рабочий процесс, а не то как он описан в регламенте.

Какие артефакты вы передаёте следующей команде? С кем взаимодействуете?
Узнаёте связи между командами и необходимый результат работы каждой из них.

Что не работает, бесит или хочется изменить?
Пользователь расскажет о настоящих проблемах, а не об «идеальной системе».

Что вы используете, кроме досок и задач?
Дашборды, фильтры, плагины, автоматизации — всё, что могло пройти мимо технического анализа. Здесь же уточняйте про интеграции с внешними системами.

Шаг 6. Ранжируем требования

Собранные данные — это ещё не результат, это сырой материал. Теперь нужно превратить его в инструмент выбора.

Группируем требования по категориям: функциональность, безопасность, производительность и так далее.

Ранжируем по критичности. Удобно использовать MoSCoW. По приоритету Must можно быстро отсечь аналоги, которые точно не подойдут. Если блокирующих требований много — выделяем их отдельно.

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

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

После многих часов общения с пользователями вы получите ещё один взгляд — уже не на текущую Jira, а на то, какой аналог вам действительно нужен. И это может оказаться совсем не то, что казалось очевидным в начале.

В следующей статье разберём как совместить бизнес-требования с результатами технического аудита и проверить это в системах-аналогах.

---

Хотите шаблон для приоритизации требований? Напишите слово «шаблон» на support@teamlead.ru — пришлём. Не хотите разбираться самостоятельно — мы можем провести анализ и помочь с выбором системы. Напишите нам в телеграм.

Подписывайтесь на наш блог, чтобы не пропустить следующие статьи.