EN



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

Распространенный вариант составления графиков отпусков — Google sheets или Excel. Справиться можно, и некоторые компании пользуются подобными методами, но визуально это не всегда чётко и понятно. Никто не застрахован от ошибок, и иногда, к сожалению, по разным причинам возникают казусы с наложением дат у взаимозаменяемых сотрудников. Также необходимо использовать дополнительные программы и переключаться, например, между Jira и Excel, чтобы сопоставить даты важных проектов и отпусков участников этих проектов. А также придумать, как уведомлять сотрудников о каких-либо изменениях в графиках.

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

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

Визуализируйте график отсутствия сотрудников с помощью Calendar for Jira

Чтобы работать стало ещё удобнее, можно информацию о том, что каких-то сотрудников нет на рабочих местах, наглядно представить в календаре с помощью приложения Calendar for Jira.

В каких ситуациях это полезно? 

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

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



Преимущества Calendar for Jira для команд и отдела кадров

В чем особенность именно Calendar for Jira, и почему приложение отлично подойдёт как для оптимизации работы отдела кадров для всей компании, так и внутри проектных команд?

В первую очередь – широкий простор для кастомизации.

Любой период времени, отмечаемый в календаре, создаётся в виде задачи. Типы этих задач уже создаются на ваше усмотрение. Обычно компании используют отпуска, больничные и отгулы. Но мы от себя можем добавить ещё пару идей.

  • Тренинги

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

  • Командировки

Чтобы не искать сотрудника на рабочем месте, когда он в другом городе.

  • Карантин

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

Второй не менее важный момент – наглядная и понятная визуализация.

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

Тогда при просмотре таймлайнов можно будет даже не вчитываться в названия задач – всё станет понятно исходя из цвета.

Можно пойти ещё дальше и разделить вашу команду на структурные подразделения, которые будут выделены как группы, и задать им разный цвет с помощью JQL. Тогда не окажется, что пришло время разработки новой фичи, а все ваши ключевые сотрудники начали уходить в отпуск.

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

Удобство использования календаря для пользователей.

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

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

Отдел кадров выполняет аналогичный порядок действий, если нужно отметить тренинг или командировку сотрудника. Единственное уточнение – в поле *Сотрудник необходимо указать нужного пользователя.

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

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

Пользователь создает запрос на отпуск где указывает: 

  • в поле Summary краткоe описание. Например, Иванов Иван, отпуск с 1.08.2021 по 14.08.2021
  • в поле Start Date дата начала отпуска
  • в поле Finish Date дата окончания отпуска
  • в поле Number of vacation Days количество дней отпуска


При нажатии кнопки Create создается задача в статусе POTENTIAL и назначается на Ответственного (в нашем случае все отпуска правилом Automation назначаются на руководителя). Сотрудник, идущий в отпуск, добавляет всех, кто заинтересован и согласовывает свое отсутствие.

Далее в статусе POTENTIAL внутри задачи идет обсуждение отпуска. 

Когда все согласованно - "Ответственный" согласовывает отпуск нажатием кнопки "Approve vacation", при переходе создается задача для бухгалтера, связанная с текущей задачей, в которую переносятся все необходимые данные. Добавляется комментарий, что отпуск согласован.

Далее задача висит в статусе POTENTIAL до даты указанной в поле Start Date.

За 7 дней до наступления "Start Date" отправляются сообщения о том, что сотрудник уходит в отпуск через 7 дней.

Когда наступает "Start Date" - правило, которое запускается каждый день, переводит задачу в работу.

В первый день отпуска задача с типом Vacation попадает в статус IN PROGRESS

Когда наступает дата "Finish Date" задача закрывается и отправляется - попадает в статус CLOSED c Resolution Fixed. Отправляются сообщения о том, что сотрудник вернулся из отпуска. 

Сам бизнес процесс:

Для визуализации отпусков использовано приложение Calendar for Jira.

В нем создан календарь с именем Vacations, в котором отображаются все запросы отпусков.

Настройки календаря (cog) → Цвета карточек

Установите правила раскраски задач в календаре, если они соответствуют определенным условиям JQL. Если проблема соответствует нескольким условиям, будет применено первое.

Например, можно задать разный цвет задач для каждой группы (Reporter in membersOf("groupname»)), чтобы визуализировать пересечания отпусков в рамках одного подразделения. Для это нужно, чтобы структурные подразделения были выделены как группы.

Если после нашей прошлой статьи вы поняли, что уже сейчас то самое время, когда нужно переходить в Atlassian Cloud, вам полезно будет узнать, какой вообще существует порядок действий для перехода.

Сама миграция делится на 6 этапов, при этом большая часть времени уйдёт именно на планирование и на анализ.

Пройдёмся по каждому этапу.


Этап 1. Оценка

Если вы хотите избежать неожиданностей и неприятностей, которые могут вылезти уже после самой миграции, нужно понять основу – в чём вообще разница между Atlassian Server и Atlassian Cloud.

Различий много, начиная от тарифов, заканчивая администрированием. Основную информацию об отличиях в развертывании Server и Cloud вы можете прочитать здесь. Используется бесплатный расширенный триал на Cloud, чтобы вживую попробовать его возможности.

Также, помимо понимания разницы между Server и Cloud, нужно разобраться в отличиях собственной инфраструктуры: что именно у вас установлено, какой версии, сколько человек пользуется, какие плагины и интеграции у вас есть. Проведите полный аудит и сформулируйте для себя ответ на вопрос: почему ваша система выглядит так, как она выглядит? для чего нужен каждый элемент системы?

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


Этап 2. Планирование

Для того, чтобы начать делать что-то конкретное и практическое для миграции, нужно сделать подготовительную работу в Облаке: активировать пробный период для миграции, создать организацию и подтвердить права на домен. На данном этапе это вся работа в Облаке.

Основная задача – разобраться с результатами аудита.

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

Пройдитесь по этим пунктам:

  •  Размер: все ли данные и пользователи вам нужны;
  •  Приложения: проверьте, существуют ли облачные версии необходимых плагинов, какова их функциональность и какой механизм их миграции. Эту информацию можно уточнить вот тут.
  •  Индивидуальные настройки системы;
  •  Количество продуктов: чем их больше, тем сложнее миграция;
  •  Тип размещения на облаке: будь то с консолидацией или федерализацией данных, или гибридное размещение – у всего есть свои заморочки;
  •  Управление пользователями: придётся ли использовать Atlassian Access.

Когда уже есть понимание, насколько сложная будет миграция, и в какие сроки вы хотите мигрировать, можно приступать к выбору способа миграции. Их всего четыре:

  1. Перенос данных после оптимизации;
  2. Перенос сразу всех данных;
  3. Постепенная миграция;
  4. С чистого листа.

У каждого из них есть свои особенности: первые два рассчитаны на несложные системы (до 5000 пользователей и 10 приложений), постепенная миграция подходит для сложных систем. Название «с чистого листа» говорит само за себя – быстро, но никаких старых данных.

Подробнее о способах миграции здесь - https://support.atlassian.com/migration/docs/compare-cloud-migration-methods/

Итогом этого этапа является план, в котором расписано кто что делает и в какие сроки.


Этап 3. Подготовка

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

Также это этап последней проверки системы перед миграцией.

Убедитесь, что версия ваших продуктов поддерживается тем способом миграции, который вы выбрали на предыдущем этапе.

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

Проверьте, все ли пункты из подробного контрольного списка миграции у вас выполнены:

Контрольный список для миграции Jira

Контрольный список для миграции Confluence 

Не забудьте установить облачные версии приложений, которые хотите протестировать.


Этап 4. Тестирование

Очень не рекомендуем пропускать этот этап - потратите чуть больше времени, но целее будут нервы.

Проведите тестовую миграцию с помощью руководства по тестированию.

Сделайте резервную копию данных и проведите приемочное пользовательское тестирование у конечных пользователей (есть в руководстве - пункт 6).

После того, как все недочёты и особенности учтены, и вы удовлетворены итогами теста, можно начинать подготовку к самой миграции.

Посте теста становится понятно, сколько времени примерно занимает миграция. Можно выбирать дату для переноса рабочей среды. Лучше подходят выходные или ночное время, когда никто не будет пользоваться как версией на сервере, так и облачным сайтом.

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

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

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

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


Этап 5. Миграция

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

Следуйте перечню необходимы процедур, который вы составили при тестировании.

Перенесите в облако все критически важные приложения и проверьте, что все данные перенеслись корректно.

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


Этап 6. Запуск

Поздравляем, можно выдохнуть, основная часть позади.

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

Изучите руководство по началу работы в облаке, чтобы выделить важные моменты и донести их до всех заинтересованных лиц.

Также не забывайте следить за обновлениями в дорожной карте развития облака - и адаптируйтесь к изменениям!


Если вам кажется, что самостоятельно вы не справитесь, у вас недостаточно ресурсов, или после прочтения этой инструкции у вас возникли вопросы по каким-то моментам – запишитесь к нам на консультацию!

Всё разберём, со всем поможем и мигрируем вас на Облако - https://www.teamlead.ru/display/RU/Contact+Us

Ни для кого уже давно не секрет, что в 2024 продукты Atlassian под редакцией Server прекращают своё существование.

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

Так кто же прав?

Хоть Atlassian действительно прилагает все усилия, чтобы миграция прошла безболезненно, Cloud на данный момент не обладает всем тем функционалом, к которому мы привыкли в серверной редакции. Это касается как самих Jira и Confluence, так и практически всех популярных плагинов.

Но всё же Cloud стремительно развивается. Все обновления можно отслеживать на "дорожной карте развития облака". Atlassian и вендоры плагинов вносят изменения в свои продукты практически каждый день. И не скупятся на инструкции для более лёгкого перехода.

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

И мы плавно подошли к насущному вопросу – когда мигрировать?

Наш совет:

Если вы уже давно используете редакцию Server, все процессы работают как часы, и вы всем довольны – не спешите. До 2024 года ещё есть время подготовиться, составить план перехода и без спешки мигрировать как на Cloud, так и на Data Center.

Если же ваша система ещё в самом начале настройки, то есть смысл не оттягивать по ряду причин:

  • Вы изначально сможете настроить систему так, как надо, и больше не думать о трудностях миграции.
  • Программа лояльности Atlassian для крупных клиентов позволяет очень сильно сэкономить. Чем раньше вы мигрируете, тем больше сэкономите.
  • Более длительная бесплатная пробная версия Cloud для тех, кто решится мигрировать как можно раньше. Подробнее можно почитать об этом здесь 


На самом деле, главный вопрос не КОГДА, а КАК.

Миграция – сложный процесс, со множеством нюансов и тонкостей. Самим разобраться очень сложно.

С чего начать? Что важно, а что нет? Какой тарифный план выбрать? Может вообще не Cloud, а Data Center?

Напишите нам. Ответим на все эти и другие ваши вопросы, составим план действий, всё подготовим и поможем вам мигрировать - https://www.teamlead.ru/display/RU/Contact+Us

С удовольствием делимся гостевым постом наших друзей из компании Polontech. Эта команда на профессиональном уровне поможет разобраться с внедрением Agile-методологии на базе Atlassian и не только.


Posted by Anastasia Sarana

 Мы постоянно работаем с большим количеством Jira проектов, и 2020 год не стал исключением. Часто настроек в Jira по умолчанию бывает недостаточно для реализации всех потребностей бизнеса, поэтому мы дополняем инстанс всевозможными приложениями. В этой подборке мы собрали набирающие популярность приложения Jira Cloud для упрощения и автоматизации управления проектами и ежедневными задачами.  

Custom Charts for Jira от Old Street Solutions

Это идеальное дополнение для создания отчетов в Jira. Интуитивно понятный интерфейс, множество шаблонов отчетов и диаграмм на все случаи жизни помогут автоматически составить понятный отчет. В приложении также можно настроить внешний вид диаграмм в Jira. Легко заходит как техническим, так и не техническим специалистам.  Приложение доступно для версий Jira Cloud, Server и Data center. 

Epic time for Jira — Sum of Worklogs от Teamlead

Как понять, хватает ли времени на выполнение всех задач в эпике? Если вы не уверены, что сможете закончить еще пару дополнительных тасков, проверьте оставшееся время эпика с помощью этого приложения от Teamlead. Здесь можно мониторить процент выполнения эпика, сколько у команды осталось времени до дедлайна и другую важную информацию по задачам. 

Whiteboards for Jira от Spartez Software

Приложение для визуализации работы онлайн. С его помощью все в команде могут использовать виртуальные доски во время совещаний, брейнсторминга, работы над совместным проектом или планирования в режиме реального времени. В приложении можно создавать новые тикеты Jira сразу на доске или работать над уже существующими тикетами. Можно также прикреплять изображения, видео, документы для лучшей визуализации проекта. Приложение доступна только для Jira Cloud.

Elements Copy & Sync от Elements

Elements Copy & Sync автоматизирует перенос задач из одного проекта Jira в другой. Можно клонировать и перемещать задачи в два клика или автоматически при переходе с возможностью добавления ссылок и синхронизации изменений между исходным тикетом и его копиями. Такое приложение необходимо для лучшего управления инцидентами или доработки эпиков. Самый популярный кейс использования — это копирование запросов с Jira Service Management в проект Jira Software для разработчиков с комментариями и вложениями. Облачная версия уже доступна на Atlassian Marketplace.

Smart Attachments for Jira от Stiltsoft

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

Все эти приложения доступны для облачной версии Jira. Если вы не нашли приложение, которое подошло бы вам больше всего, обратитесь к нашим специалистам. Мы подберем оптимальное решение из Atlassian Marketplace и настроим его или разработаем новое дополнение на базе Atlassian с учетом требований вашего бизнеса.


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

Как можно отследить эти задачи-дубликаты?

У Jira есть очень полезное расширение – Automation. Оно позволяет автоматизировать многие рутинные процессы с помощью создания правил для обработки необходимых сценариев.

В библиотеке Automation Cloud есть готовое правило с заманчивым названием Close duplicate issues, но, если заглянуть внутрь, станет понятно, что это правило всего лишь закрывает задачу, у которой тип связи Duplicate. Сам факт определения дубликатов при этом остается за кадром.

Пойдём другим путём. Как можно найти дубликаты в Jira?

Можно использовать JQL-запрос, в котором задать параметры-маркеры и значения, для которых ищутся дубликаты, по типу:

Project = DEV AND client = Barry AND problem = “Unstable connection”

Но проблема в том, что заранее неизвестно, какими будут значения полей в новой задаче.

Этот момент можно решить с помощью smart values ( подробнее об этом читайте здесь - https://support.atlassian.com/jira-software-cloud/docs/what-are-smart-values/).

Они помогут настроить поиск дубликатов по JQL с помощью Automation. Используя smart values можно искать задачи, в которых значения полей совпадают со значениями в текущей задаче, при этом сами значения могут быть любыми, нет нужды их знать заранее.

Единственное, что нужно помнить: если в значении поля могут содержаться символы, требующие помещения в кавычки в jql-запросе (например, пробел или запятая), значение Smart value также помещают в кавычки.


Пример настройки:

Рассмотрим случай, когда нам требуется проверять каждый новый запрос на дублирование с полным совпадением по полям Problem и Client (клиент повторно жалуется на ту же проблему).

В случае, если такие задачи найдутся, Jira должна привязать их к текущей с типом связи Duplicate.

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


Выбираем триггер

Определите, в какой момент будет происходить проверка. В нашем примере это создание задачи.


Определяем условия задач-дубликатов

New component → Branch rule/related issues

В этом месте должны быть определены условия, по которым Jira будет понимать, нужно или нет применять это правило к конкретной задаче.

В нашем случае поиск будет идти по jql, в котором как раз заменим конкретное значение полей на smart values. Когда указываем значение каждого поля, необходимо использовать синтаксис типа:

{{triggerissue.customfield_10034}}

что можно прочитать как "значение поля с id 10034 из задачи, которая явилась триггером к запуску правила".

Обратите внимание на то, что синтаксис для получения значения зависит от типа поля. На примере выше запрос на получение значения текстового поля.

Если в вашем случае используется другой тип поля, уточните его синтаксис здесь - https://support.atlassian.com/jira-software-cloud/docs/what-are-smart-values/

Поиск по всем задачам может занять длительное время.

Чтобы сократить время на обработку, ужесточите условия. Например, в примере выше сверка идет только с задачами, созданными за последние 3 дня.


Добавляем действие для найденных дубликатов

New Action → Link issues

В примере мы хотим, чтобы найденные дубликаты были автоматически связаны с новой задачей.

Для этого используем действие Link issues и при выборе типа связи учитываем, что поскольку действие применяется к "старым" задачам, именно новая должна быть отмечена как дублирующая, а значит, для проверенных выбираем направление связи is duplicated by.


Всё! Отныне можно забыть о том, что нужно вручную искать и проверять повторяющиеся задачи, Jira сделает это за вас.


Это лишь один из множества вариантов, как можно упростить себе жизнь, автоматизировав рутинные дела.

Если в вашей работе часто встречается какой-то затык, "больное место", или вы просто тратите неимоверное количество времени на рутину, приходите к нам в поддержку. Мы поможем найти выход.

Пошаговые инструкции, инструменты, поддержка

Все уже слышали новости от компаниии Atlassian об упрощении редакции Server и переходе на Atlassian Cloud и Data Center.

Со 2-го февраля 2021 г. вступят в силу следующие изменения:

Вы больше не сможете приобретать новые серверные лицензии на продукты Atlassian (за исключением Fisheye, Crucible и Bamboo Server).

Увеличатся цены на обновления и апгрейды серверных лицензий, а также возрастут цены на подписки DataCenter.

Со 2-го февраля 2022 г.

Вы больше не сможете производить апгрейды  и даунгрейды серверных лицензий на продукты и приложения Atlassian за исключением Fisheye, Crucible и Bamboo Server

Со 2-го февраля 2023 г.

Вы больше не сможете покупать обновления для серверных лицензий. Также больше нельзя будет купить новые серверные лицензии на плагины с Marketplace.

Со 2-го февраля 2024 г. вступят в силу следующие изменения Atlassian перестанет предоставлять поддержку и багфиксы для серверных продуктов


Итого у владельцев серверных лицензий есть три года для перехода на редакцию Cloud. Для этого Atlassian подготовил довольно большой пул информации, чтобы облегчить непростой процесс переезда. 


The Atlassian Migration Program

Материалы программы доступны любым клиентам Atlassian, планирующим переезд в облако.

Ресурсы

На протяжении всего период перехода на Cloud, всем клиентам доступен Информационный портал, содержащий пошаговые инструкции, примеры стратегий, техническую информацию, необходимую для переезда. Вся информация доступна в том числе на русском языке.

Для крупных клиентов (1001+) также доступен дополнительный ресурс по поддержке миграцииМиграция для корпоративных клиентов.


Как часть программы миграции, есть серия видео о миграции на Cloud, рассказывающие о планах развития платформы, информацию о безопастности.


Инструменты

Частью успешной миграции является понимание отличий возможностей серверной и облачной платформы. К сожалению, довольно часто оценить, что и как будет работать, можно только начал мигрировать (smile). Поэтому Atlassian предагает бесплатный расширенный триал на Cloud, для проведения тестовой миграции. 

Триал доступен компаниям, у которых есть лицензии редакций Server или DC с действующим сроком поддержки - срок триала будет равен сроку действия поддержки текущих лицензий. 

Для оценки возможности миграции Вы также можете воспользоваться бесплатными приложениями по миграции для Jira и Confluence

С этими инструментами вы сможете:

  • проверить наличие облачной редакции плагина и пути его миграции 
  • мигрировать пользователей, проекты, данные и спейсы из Jira и Confluence с сервера в облако
  • найти и решить, возникающие в процессе миграции, инциденты.


Поддержка

У Atlassian есть выделенная команда поддержки миграции, поэтому, если в процессе переезда, вы столкнулись с какими-то трудностями, напишите в поддержку Atlassian запрос в разделе Migrration support, чтобы получить ответ максимально быстро.

Подробнее о том, чем может помочь поддержка Atlassian можно узнать в документации поддержки.


Если несмотря на все доступные ресурсы, задача миграции выглядит неподъемной, напишите запрос нам и мы поможем пройти через этот процесс максимально безболезненно.





Have you already used our app HelpDesk for Jira?

If you have, and, moreover, you’ve preferred SLA 2.0 over the standard SLA functionality, we have great news for you! 

We added new JQL-functions such as:

  • Searching for issues with currently breached SLA
  • Searching for issues with currently completed SLA
  • Searching for issues with particular SLA time spent
  • Searching for issues with particular SLA time remaining before the SLA is breached
  • Searching for issues having an SLA paused due to a condition.
  • Searching for issues that have a running SLA, regardless of the calendar.

You can check for syntax by this link https://wiki.teamlead.ru/doc/helpdesk/latest/admin-guide/sla/sla-2-0/jql-functions-sla-2-0

Create more filters and improve your queues. Upcoming within the SLA functionality: compact SLA 2.0 field view on agile-boards, historical JQL-search, reports.

Searching for something else? Drop us a line!

But if you are not familiar with HelpDesk for Jira, we highly recommend you to check it out.

It’s not just a simple service desk. It’s a multifunctional but still affordable one. HelpDesk lets you support thousands of customers without providing them with Jira accounts. They even don’t have to know what Jira is.

You can customize a unique design for customer portals which can be multiple single or cross-projects. Also, your customers can easily check what progress with their issues solving is. With two-level SLA it’s easy to control the response time not only for all company issues’ SLA but also a team-based SLA for issues.

Start your free trial by this link and try these and many other benefits of HelpDesk for Jira.

Looking for HelpDesk for Jira Cloud? It’s on the way, stay tuned.

Налетай, не ленись, за карьеру берись!

Ребята, ловите свежий видос о карьере. "Капитан Очевидность" расскажет о видах карьерного роста, о том, что помогает и мешает карьере.

Наконец-то рада сообщить, что 20 октября в полюбившейся нам SREDA Loft на Курской пройдет наш очередной Teamlead Atlassian Day.

Регистрация открыта, программу формируем, но уже точно расскажем кейсы с nFeed, про удобство Swimline в JIRA Software, про управление проектами в BigPicture и Tempo.

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

В целом, все планируется как обычно - насыщенные доклады, активная "коллоборация" (надо же поддержать Германа Оскаровича), ну и без Гиннесса и Шпатена не обойдется.

Регистрируйтесь, приходите, будем рады увидеться вновь!

Всем привет!

Как уже многие поняли, Atlassian приобрёл Trello. Этот неоднозначный, но интересный сервис уже наделал много шума. Однако мало кто понимает как его применить в жизни. Одни говорят - это трекер дел для простых людей, другие - проектный офис для топ-менеджеров, третьи...

И вот, мы в своей лаборатории попробовали наш один внутренний процесс на этом движке, который до этого работал в Confluence. Не уверен, что такой процесс ещё есть у кого-то, но вдруг. Этот процесс - новости. Не простые, а золотые. Вернее платиновые (wink). Каждую пятницу, один из нас пишет итоги недели и планы на следующую. Сначала происходит сбор материалов со всех сотрудников, а затем сведение их в..., присядьте - стенгазету. Процесс полезен тем, что новости пишут все, меняясь еженедельно. Это позволяет каждому проникнуться работой других людей, а так же проявить творческое начало во время подготовки очередного выпуска.

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

Круто, да?

Есть идея в перспективе подтягивать что-нибудь автоматически из JIRA с помощью Trello Sync for JIRA.

Что ж, ребята, может и у вас есть какой-нибудь кот в сапогах? Берите Trello и пробуйте раскидать своих котов по мешочкам!

Всем хорошего настроения! (c)

Anton Kolin (Teamlead)