Ловушка приоритетов

Лучший ли выбор — множественный выбор?

Ловушка выпадающего списка `Priority`

История стартапа

Без сомнений, ваши администраторы Jira уже нашли решение: вот он, выпадающий список поля Priority! (Совет для enterprise-разработчиков: возможно, он называется Priority2 или P-level.)

Любопытно, что 100% компаний выбирают между P1, P2, P3, P4 или Low, Med, High, Critical — видимо, других вариантов не существует.

Жёстко заданный список из четырёх вариантов? Хорошо. Попробуем пару недель…

2 дня спустя

В повороте событий, который никого не удивил, организация обнаружила тикет с новым, ещё более высоким приоритетом, что потребовало небольшого хака: добавить P0, или Critical Max+!

Ещё 3 дня спустя

Наш бесстрашный босс провёл несколько захватывающих встреч и сделал открытия на конференции!

Каким-то образом они обнаружили приоритет ещё выше, чем P0!

С тех пор команда усердно изучает, как назвать этот новый приоритет.

Может, -1? Нет-нет. Это слишком запутанно (P-1 против P1). Ладно, как насчёт P0.5? Нет?

В «озарённый» момент команда придумала приоритет ещё выше: двойной ноль!
Теперь известный как приоритет P00.

До потопа

Прежде чем кто-либо успевает осознать, ваша команда каким-то образом тонет в тикетах P00!

Как избежать этой глупой игры в «Инженерный театр»?

Что если бы приоритет не был множественным выбором?

Как лучше представить постоянно меняющееся, текучее человеческое понятие, такое как Priority?

В реальном мире приоритеты постоянно сдвигаются и эволюционируют в зависимости от новой информации, изменений на рынке и целей организации.
Часто существует сложное взаимодействие между срочностью, важностью, доступностью ресурсов и анализом затрат/рисков, которое простой выпадающий список не способен отразить — особенно с течением времени. (Гниение тикетов.)
Разные стейкхолдеры могут иметь противоречивые взгляды на то, что составляет высокий приоритет, что делает подход «один размер для всех» непригодным.

Что же дальше?

Есть несколько альтернативных подходов, которые стоит изучить — от простых к сложным:

Чтобы дать больше пространства для манёвра, выберите «нейтральное» начальное значение, скажем 100 или 1 000. Вы всегда можете увеличить или уменьшить число.
- Или начните с нуля, где более высокие числа означают более высокий приоритет.
Внедрите многомерную систему приоритизации, учитывающую такие факторы, как бизнес-ценность, срочность и требуемые усилия. (Создайте composite score для удобной сортировки и фильтрации.)
Используйте динамический метод приоритизации, например метод MoSCoW (Must have, Should have, Could have, Won’t have), позволяющий регулярно пересматривать приоритеты. (См. также модель Кано.)

Итоги

Так много ставится на приоритет, несмотря на его быструю потерю актуальности. Вчерашние CRITICAL-тикеты вряд ли останутся CRITICAL в следующем квартале.

Со временем старые тикеты с высоким приоритетом становятся устойчивыми к очистке и обслуживанию. В конце концов, кто захочет понизить Priority того, что однажды было объявлено essential? Не говоря уже об удалении нерелевантных тикетов… (Боже! Подумайте о бэклоге!)

Я видел, как множество компаний путают Severity и Priority. Severity описывает срочность (или чувствительность ко времени).

Priority ≠ Severity. Имеет смысл определить 3–5 уровней severity (часто используемых для поддержания соглашений об уровне обслуживания — SLA).

Уровни срочности помогают сообщить о диапазоне — от нулевого влияния на клиентов до частичного/полного простоя сервиса.

Предостережение

Развёртывание неограниченного поля приоритета требует немного планирования и дисциплины!

Если вы знакомы с фронтенд-разработкой, то, возможно, пережидали войну z-index.

По сути, z-index позволяет дизайнерам устанавливать любое положительное целое число, чтобы их виджеты отображались «выше» контента с более низким z-index.

Даже незначительное обновление компонента может изменить z-index на их <Dialog /> — сделав его внезапно невидимым. Эти ситуации становились запутанными, когда наши сторонние компоненты, новая функциональность и вклад других команд пытались перещеголять друг друга z-index’ом.

Когда-то z-index был ограничен ~32 000. Однако недавно я видел сниппет с миллиардом: z-index: 1000000000!

Инфляция, должно быть, сильно бьёт по z-index.

Обсуждение

Стоит ли этот мысленный эксперимент?
Идея постоянно растущего приоритета ужасает? Вызывает тревогу?
Неизбежно ли, что этот подход в конечном итоге превысит пределы 64-битного целого числа?
Могут ли другие поля (помимо Severity или Urgency) дополнить этот разговор?
Насколько Jira заслуживает вины? Или кредита?

Мы могли бы кричать в интернет: «Кто будет разбирать все эти тикеты P00?»

Или можно честно взглянуть на свой бэклог.

Примите тот факт, что 90% ваших 1 000 тикетов никогда не будут выполнены. Это нормально.
Архивируйте тикеты, которые не трогали месяцами. Любой изначальный приоритет/срочность больше не актуален. В любом случае, архивные задачи часто можно восстановить.
Когда задача всплывает снова — это отлично; значит, её приоритет вырос.
По моим наблюдениям, выбрасывание старых и незавершённых тикетов не приносит никакого вреда.
Бесконечное пополнение бэклога-как-базы-данных упускает возможность сфокусировать команду и организацию на том, что действительно важно. (Вещи перед нами. Тогда как бэклоги по своей природе смотрят назад.)
Глубокий бэклог превращается в комнату трофеев из зазеркалья, празднующую дерьмо, которое вы никогда не отгрузите.