Что такого в Jira, что за неё отказывают на собеседовании?

Кандидатке отказали за отсутствие опыта в Jira. Что скрыто за доской с карточками: JQL, воркфлоу, схемы прав, автоматизация — и что отвечать на собеседовании

Вся переписка по вакансии Junior+ Project Manager уместилась в три реплики.

— Расскажите, пожалуйста, какой у вас практический опыт работы в Jira? — Опыта в Jira нет, работала в Slack, Planner, Notion, Битрикс. Поэтому освоить новую программу для меня не проблема. — Отказ.

Скриншот этой переписки выложила в Threads пользовательница kruchaforever с подписью: «Расскажите, что там такого особенного в этой Jira, что аж отказывают, если нет опыта? Вообще надоело, что мне за 30, я могу изучить любую программу, которую дадут. Хотите 2+2=5? Да без проблем, но не берут, потому что я чего-то не знаю».

На момент скриншота пост собрал 115 лайков и 220 комментариев. Комментарии в основном двух сортов: HR — звери, а в Jira делать нечего.

Один выбивался. heartfeel92 написал: «Все кто говорит, что там знать нечего и просто задачи влево/вправо двигать — тот сам не знает жиру. У жиры есть свой собственный язык запросов — JQL, с помощью которого можно делать кучу всего, от простого поиска задач, до написания мини-скриптов. Вот начни изучение хотя бы с него».

Я с ним согласен. Дальше — по пунктам, что в Jira есть, кроме перетаскивания карточек.

JQL: место, где кончается интерфейс

Jira Query Language (JQL) — язык запросов к вашему трекеру. Синтаксис похож на SQL, но заточен под задачи: поля, операторы, функции, сортировка.

Самый простой запрос выглядит так:

project = OPS AND assignee = currentUser() AND resolution = Unresolved ORDER BY updated DESC

Мои незакрытые задачи в проекте OPS, свежие сверху. Пока ничего интересного: то же самое даёт пара кликов в фильтрах.

Интересное начинается там, где появляются операторы истории. Они умеют читать прошлое задачи.

project = OPS AND status CHANGED FROM "In Progress" TO "Done" DURING (startOfWeek(), endOfWeek())

Что команда реально закрыла за неделю. Именно закрыла: считается сам факт перехода в готово, а даты создания и обновления тут ни при чём.

project = OPS AND status = "In Progress" AND updated <= -5d

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

project = OPS AND status WAS "Blocked" AFTER -30d

Всё, что за месяц побывало в блоке. Даже если сейчас оно закрыто и в отчёте не видно.

Ещё несколько кусков, которые вы будете писать постоянно:

• sprint in openSprints() — задачи текущего активного спринта, без привязки к его номеру. Фильтр не придётся править каждые две недели.
• assignee in membersOf("team-backend") — по группе, а не по списку людей. Человек уволился, группу поправили, фильтр живой.
• labels IS EMPTY — задачи без меток. Обычно это дыра в процессе, которую видно только запросом.
• priority in (Highest, High) AND due <= endOfWeek() — то, за что вас спросят в пятницу.
• filter = "Мой базовый фильтр" AND component = Billing — фильтры вкладываются друг в друга, и это экономит половину работы.

Есть ещё функция linkedIssues(): она собирает всё, что связано с задачей, включая блокеры. Стандартная, никаких плагинов не требует, но пишется через issue in и ждёт конкретный ключ:

issue in linkedIssues("OPS-123")
issue in linkedIssues("OPS-123", "blocks")

Второй аргумент — тип связи. А вопрос посложнее, вроде «покажи всё, что блокирует любой открытый баг в проекте», стандартный linkedIssues() уже не берёт: ему нужен один ключ, подзапрос он не понимает.

Про «мини-скрипты» из комментария. В базовой Jira JQL остаётся языком поиска, до программирования он не дотягивает. Скриптовая часть появляется вместе с функциями ScriptRunner (Adaptavist). Это отдельный платный плагин с Marketplace, и там живут конструкции вроде

issueFunction in linkedIssuesOf("project = OPS AND type = Bug AND resolution = Unresolved", "blocks")

то есть подзапрос внутри запроса. Оговорка для Jira Cloud: issueFunction там работает не в обычном поле поиска, а на отдельном экране ScriptRunner Enhanced Search (меню Apps). В Data Center эти функции работают прямо в стандартном поиске.

Суть комментария от этого не меняется. Человек, умеющий писать JQL, задаёт трекеру вопросы. Тот, кто не умеет, смотрит на то, что ему показали.

Разница примерно как между «умею пользоваться Excel» в значении «набиваю числа в клетки» и в значении «строю сводную по выгрузке на сорок тысяч строк».

Воркфлоу: откуда вообще берутся статусы

Второй слой — процесс.

Статусы в Jira не даны свыше. Это схема, которую кто-то нарисовал: какие состояния бывают у задачи и какие переходы между ними разрешены. Цепочка «В работе», «На ревью», «Готово» — чей-то осознанный выбор, а не устройство мира.

У каждого перехода есть три группы настроек, и в них вся соль:

Условия (conditions) — кому переход вообще виден. Например, отправить задачу в «Готово» может только исполнитель, а не любой прохожий.

Валидаторы (validators) — что должно быть заполнено, чтобы переход состоялся. Нельзя закрыть задачу без указанной резолюции. Нельзя взять в работу без оценки.

Пост-функции (post functions) — что происходит автоматически после перехода. Проставить дату, назначить исполнителя, отправить событие, пересчитать поле.

Менеджер жалуется: «у нас разработчики закрывают задачи, не заполнив время». Рассылка в чат тут не поможет. Поможет валидатор на переходе.

Хороший воркфлоу команда проходит не задумываясь, и состояний в нём обычно четыре-шесть. Самая же частая ошибка новичка — нарисовать воркфлоу из восемнадцати статусов, потому что «так же точнее». Точнее — да. Работать по нему никто не будет.

Схемы и права: место, где ломаются все

Дальше идёт часть, про которую в вакансиях не пишут, но из-за которой пишут в поддержку.

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

Две оговорки к таблице. Первая: схемы есть только в company-managed проектах. В team-managed настройки лежат внутри самого проекта, схем там нет, и половина этого раздела к ним не относится. Вторая: Atlassian переименовала в Cloud «issue» в «work item», поэтому в свежем интерфейсе те же схемы подписаны словами work type и work item. В Data Center остались привычные issue type scheme и issue security scheme.

Логика такая: у вас двадцать проектов и три реальных процесса. Вы делаете три схемы и цепляете их к проектам, а не настраиваете двадцать раз одно и то же.

Побочный эффект — разговор, случающийся в каждой компании:

— Поправьте, пожалуйста, статус только в нашем проекте. — Не могу, эта схема ещё у семи проектов.

Отдельно — права. Схема прав говорит, кто создаёт задачи, кто правит чужие, кто меняет исполнителя, кто вообще видит проект. Причём права выдают ролям: Administrator, Developer и что там ещё завели. Людей в роль набирают отдельно в каждом проекте, а схема одна на всех.

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

Знать это наизусть джуну не нужно. А вот понимать, что за словами «дайте доступ» стоят четыре разных механизма, полезно. Особенно если организовать доступ поручили именно вам.

Доски, спринты, бэклог

Здесь интерфейс наконец совпадает с картинкой в голове: колонки, карточки, перетаскивание. Только и здесь под капотом не то, что кажется.

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

Что настраивается:

• Колонки — каждая маппится на один или несколько статусов. Статусов может быть больше, чем колонок.
• Лимиты WIP — сколько задач допустимо держать в колонке одновременно. Колонка подсвечивается, когда лимит пробит.
• Свимлейны — горизонтальные дорожки. По исполнителю, по эпику, по приоритету или по произвольному JQL. Дорожка «горит» для всего, что старше трёх дней, — обычный рабочий приём.
• Быстрые фильтры — кнопки над доской, каждая из которых внутри снова JQL.

JQL всплывает в этом тексте третий раз, и это не совпадение: он подложка под половиной остального интерфейса.

Спринты и бэклог — про планирование: оценка в story points или в часах, перенос незакрытого в следующий спринт, разбивка эпика на задачи. Кнопки там простые. А вот что делать с задачей, которая не влезла в спринт третий раз подряд, ни одной кнопкой не решается.

Фильтры, дашборды, автоматизация, отчёты

Дальше всё складывается в одну цепочку.

Написанный запрос вы сохраняете как фильтр. Фильтр раздаёте людям и группам. На фильтре строится гаджет на дашборде: таблица результатов (Filter Results), круговая диаграмма по исполнителям (Pie Chart), двумерная сводка «статус против компонента» (Two Dimensional Filter Statistics). Всё это стандартные гаджеты, ставить ничего не нужно.

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

Автоматизация — правила из трёх частей: триггер, условие, действие. Задача висит в ревью больше двух дней — напомнить в канал. Все подзадачи закрыты — закрыть родительскую. Создана задача с меткой incident — поставить наивысший приоритет и назначить дежурного. Внутри правил живут smart values: {{issue.key}}, {{issue.assignee.displayName}} и подобные, то есть обращение к полю через точку в двойных фигурных скобках. Префикс issue. часто можно опустить, {{key}} работает так же.

У автоматизации в Cloud есть лимит на запуски, и он зависит от тарифа:

Правда, на практике этот лимит мешает реже, чем кажется, и вот почему. Считаются только правила, работающие на несколько проектов или на весь сайт; внутри одного проекта правила не ограничены. И запуск засчитывается, только если правило дошло до действия: триггер сработал, а условие не пропустило — не считается. Цифры приведены на сентябрь 2026, Atlassian уже меняла модель тарификации автоматизации, так что перед планированием их стоит сверить с актуальной страницей.

Отчёты — burndown по спринту, velocity по последним спринтам, диаграмма накопленного потока, control chart с временем цикла. Отчёты в Jira честные до неприятного: если команда закрывает половину спринта в последний день, это видно на графике сразу, и объяснять придётся вам.

Ещё есть время в статусах — метрика, за которую отдельно цепляются, потому что она показывает, где именно процесс стоит. Отдельного отчёта «время в статусе» в стандартной Jira Cloud нет. Ближайшее из коробки — control chart, дающий время цикла по выбранным колонкам доски, и диаграмма накопленного потока. Разбивка по каждому статусу отдельно — это уже плагин с Marketplace.

Где соискательница права

Теперь честно, иначе получится поучение.

Фильтр по названию инструмента бывает откровенно тупым. Человек, пять лет проработавший в YouTrack, Redmine или Azure DevOps, разберётся в Jira за неделю: сущности те же, слова другие. Отсеивать такого по строке в резюме — терять сильного кандидата ради удобства сортировки. Это происходит регулярно, и раздражение kruchaforever понятно.

Дальше. По моему опыту, компании сплошь и рядом используют Jira процентов на десять. Проект заведён по умолчанию, воркфлоу стандартный, дашборда нет, автоматизации нет, JQL никто не видел. В такой компании «опыт работы в Jira» действительно означает «умею перетаскивать карточки», и все слои, о которых я писал выше, лежат там мёртвым грузом.

Но в диалоге со скриншота есть деталь, работающая против кандидатки. Её ответ звучал так: опыта нет, работала в Slack, Planner, Notion, Битрикс.

Slack — мессенджер. Notion — база знаний, в которой можно завести доску. Planner — простой планировщик задач. Из перечисленного только Битрикс отчасти сопоставим с трекером, да и то боком. То есть на вопрос про практический опыт работы с трекером человек ответил списком, где трекера почти нет.

Нанимающий услышал не «я не знаю Jira». Он услышал «я не работала в формализованном процессе». Для Junior+ Project Manager это и есть содержание вакансии.

Что отвечать, если опыта нет

Между «освою» и «знаю, чего именно мне предстоит осваивать» — пропасть шириной в одно собеседование.

Ответ «опыта нет, но я быстро учусь» честный, но пустой: его говорит каждый второй, и проверить его нечем. Ответ «в Jira не работала, но в Redmine собирала фильтры и настраивала переходы, к JQL присматривалась — вот примерно такие запросы пишу» звучит иначе, даже если запросов там три штуки. Он показывает, что человек заглядывал глубже интерфейса.

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

Снаружи это по-прежнему доска с карточками. Так выглядит любой инструмент со вторым слоем — пока не откроешь.