Это — вторая часть цикла “Начало работы с Jira Automation”, в которой мы разбираем Smart Values и учимся применять их на практике внутри автоматизаций Jira.
OKR — штука в целом полезная, если знаете, зачем и как её внедрять.
Сегодня я не собираюсь вам продавать OKR как «идею» или «мечту» как способ достичь того, что не получается с помощью обычных средств. Моя цель сейчас — скорее, рассказать вам, как сделать в инструменте удобный механизм ведения Целей и Результатов (а именно так переводятся Objectives and Key Results) их дальнейшего отслеживания. В качестве инструмента будет выступать Jira, в качестве дополнительного удобства — плагин Structure с его удобными фишками. Рассказ будет поделен на 2 части — о создании механизма и о создании мониторинга.
В конце вас ждёт инструмент, который поможет вам сэкономить на покупке платного плагина для Jira. И который вы сделаете сами с помощью этого гайда.
Часть 1. Создаём механизм
На этапе, когда в компании началось массовое внедрение и команды начали знакомиться с этим подходом, предлагалось ведение всех целей в таблицах и файлах-документах. Для одной команды — вполне себе неплохой вариант, но когда команд за 30 и часть Целей зависит от других Целей, то понять общую картину в куче Excel-таблиц, где каждая команда, хоть и соблюдая общие принципы, но всё же ведет все по-своему — становится крайне тяжело. И мне это очень не понравилось.
Я решил попробовать найти или сделать механизм для этого.
В командах часто тратят часы на ручное обновление статусов задач, проставление дат релизов и уведомления коллег о готовности работы.
В этой статье я покажу, как с нуля настроить правило в Jira Automation: от выбора триггера и условий до действий с задачами. Даже если вы никогда не работали с Jira Automation, следуя шагам, вы сможете создать свой первый рабочий сценарий за 10 минут.
(спойлер: в конце будет ссылка на GitHub)
Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.
Потом проект стартует…
Внезапно меняются требования и бэклог, появляются дополнительные зависимости. Часть задач внезапно оказывается ненужной, ещё более внезапно меняются менеджеры и ключевые участники. Рано или поздно таски начинают зарастать мхом: апдейты не комментируются, статусы не двигаются.
В какой-то момент наиболее ответственный член команды решает устроить субботник и позакрывать то, что уже сделано. Отсюда — популярность следующих вопросов в поддержке Jira:
Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.
Компания Atlassian, известный производитель систем для управления проектами и разработки, объявила о прекращении продаж и поддержки on-premise версий своих продуктов в 2029 году. Эта новость вызывает серьезные опасения среди российских компаний, активно использующих эти продукты для своей работы.
Почему Jira прекращает поддержку on-premise версий?
Atlassian начала поэтапный отход от серверной модели ещё в 2020 году, когда была провозглашена стратегия Cloud First. Инновационные функции последних лет разрабатывались исключительно для облачных решений, оставляя on-premise версии позади. Изначально компания отказалась от версии Server, теперь же процесс коснулся всех серверных решений:
Чтобы освободить команду от рутины, я возглавил инициативу по внедрению автоматизации. Мы добились этого с помощью Jira Automation и Telegram Bot API, полностью избавившись от отчётов и ускорив работу команды — о результатах расскажу в этой статье. Стоит сказать, что до этого я был обычным пользователем Jira, без глубокого погружения в её внутренние возможности. Тем интереснее этот кейс оказался для меня!
В этой статье расскажу, как мы реализовали гибкое многоэтапное согласование в Jira. Особенность подхода — все согласование зациклено в одном статусе, без громоздких схем workflow. Вся логика задается в Assets и управляется через Groovy‑скрипт.
Всем привет!
Я Полина — старший системный аналитик на проекте разработки и развития решений по управления данными в компании "Цифровые сервисы". В целом мой опыт в аналитике более 10 лет на позициях, как бизнес , так и системного аналитика.
На одной из конференций по аналитике[1] увидела интересный слайд, на котором был перечислен набор аббревиатур и вопрос для размышления: «Должен ли аналитик уметь все?».
Наверняка тебе знакома ситуация: начинается утренний синк, и ты задаёшься вопросом: «А что вообще сейчас происходит с задачами?». Кто‑то что‑то делал, кто‑то ждал ревью, у кого‑то что‑то зависло, а кто‑то вообще сидит без работы. На расспросы команды уходит много времени, а картина всё равно остаётся неполной. И самое важное не про все вспомнишь в момент синка.
Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.
Никто не любит очереди и ожидания. Мы не любим стоять в очередях и ещё больше не любим лезущих вне очереди. Сверхэффективный ад порой представляют как бесконечную, зацикленную саму на себе очередь... В конце концов, что есть символ неизбывной печали и тоски, как не Хатико.
Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.
Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.
Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.
Компания Atlassian была первопроходцем в преобразовании традиционной модели обеспечения качества (Quality Assurance) в модель Поддержки Качества (Quality Assistance). На протяжении многих лет они разрабатывают свою методологию, доступную в различных материалах.
В этой статье расскажем о том, как Atlassian проводит анализ качества своего менеджмента, организации, навыков и методологий. В их модели инициирующая сила начинается с руководства.
В этой статье я поделюсь результатами исследования, посвященного унификации процессов создания проектов в Jira, используя возможности автоматизации и API. Статья была написана с помощью GPT Deep Research в целях изучения различных подходов к унификации рабочих процессов и настройки проектов в Jira. Основная цель — собрать мнения и комментарии от других экспертов, чтобы понять, как они подошли к созданию стандартов и оптимизации процессов в своей практике. Буду рад услышать ваши истории и советы по унификации в Jira, а также обсудить лучшие методы для повышения эффективности и согласованности в работе команд.
Меня зовут Дина, я занимаюсь аналитикой в одной из команд «Ростелеком Информационные Технологии» (РТК ИТ). В статье хочу осмыслить полученный опыт переноса документации и поделиться своими соображениями. Возможно вы тоже думаете о переходе на базу знаний. Такой переход может занять больше времени, чем ожидается. Я расскажу, как это было у нас. В конце подведу итоги: что получили и что потеряли.
Всем привет, меня зовут Денис, я хотел бы поделиться опытом использования AWX в рамках одной из наших потребностей. Статья может быть полезна ребятам с «инфры», если в компании используется vmware и подобное cloud решение для частого деплоя, а для всяческой бюрократии и запросов вы обращайтесь в Jira.
Недавно @kuksepa выкладывала отличную статью про AWX по этому я не стану много описывать конкретно его, а постараюсь кратко описать процесс. Прошу не обращать внимание на замазанные элементы.
Предлагаю познакомиться с нашим опытом по внедрению метрик по JIRA для измерения продуктивности команды разработки 1С в компании Moex.
В данной статье я делюсь своим опытом планирования и декомпозиции задач и рассказываю, как инструмент планирования и управления проектами помог мне и моим коллегам улучшить свою работу.
Привет, Хабр! Меня зовут Павел Родичев, и я тимлид технической поддержки в СберМаркете. Эта статья — о том, как мы интегрировали в Jira систему, которая для этого не предназначена, и сократили время на нотификацию пользователей.
Если для вас проблема долгих Review такая же боль, как и моя, то после прочтения данной статьи вы будете на шаг ближе к решению данной проблемы.
Привет! Приятно ведь читать хорошо оформленные статьи на уютном хабре? В которых часть текста спрятана под катом, есть подписи к картинкам, красивые и понятные таблицы и все остальные плюшки? Я думаю очень приятно. Поэтому предлагаю рассмотреть немного полезных советов, о том какие макросы в Confluence помогали делать это раньше, а теперь точно также помогают в EvaWiki.
В интернете много полезной информации по использованию Confluence. Например, вот статья с рекомендациями по использованию макросов. В ней всё достаточно круто описано, но хотелось бы внести поправку. Конфлюенс ушел из России, а EvaWiki осталась. И теперь тот функционал, который был в зарубежном решении можно использовать в российском.
Статья может быть полезной для тех, кто активно работал в Confluence и хочет точно также делать это в нашем ПО.
