Июль 07

Jira на максималках: как автоматизировать рекрутинг, замер узнаваемости, финансовые процессы и учет доменов

Меня зовут Алексей Охмуш, уже более 3 лет занимаюсь настройкой и администрированием систем Atlassian. Отдельная должность Jira-администратора в IT-компаниях (особенно в Украине, где все пытаются максимально оптимизировать штат и сэкономить ресурсы на персонале) — это не очень распространенная практика. Чаще всего задачи по настройке и администрированию Jira ложатся в виде дополнительной нагрузки на одного из технических специалистов (системного администратора/разработчика/проджект- или продакт-менеджера). В таком случае используется только базовый набор функций. Кроме того, много важных моментов, таких как конфиденциальность данных, оптимизация ресурсов, распределение ролей и прав, остаются без внимания. Сегодня на примере Boosta хочу поделиться опытом максимально широкого использования возможностей Jira и успешной имплементации ее практически во все процессы компании.

Почему в Boosta решили сделать полноценную CRM-систему на базе Jira

Когда компания маленькая (до 30-40 сотрудников), ей нужно совсем немного инструментов для работы, а процесс трекинга трудозатрат на первых порах обычно вообще отсутствует. Многие вещи можно хранить в Google Docs, на почте, в мессенджерах. Но со временем становится сложно контролировать все вручную. Возникает необходимость разработки правил, построения процессов и отслеживания результатов. И чем динамичнее растет количество сотрудников, тем сложнее вскочить в последний вагон уезжающего поезда: внедрение новых инструментов становится все более проблематичным. Ведь в больших компаниях понадобится и больше времени и ресурсов на анализ, интеграцию инструмента, настройки его под собственные нужды и обучение персонала.

Изначально систему Jira в Boosta привнес технический директор, Алексей Прокашев. Это случилось в скором времени после основания компании. На тот момент Jira использовалась исключительно для трекинга задач отдела разработки, как и в большинстве других компаний. Со временем начали возникать запросы на создание систем администрирования для других отделов и процессов.

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

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

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

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

Гибкость. Функционал всех специализированных программ жестко зафиксирован. И на запрос к техподдержке об изменениях, даже минимально выходящих за его рамки, чаще всего приходит отрицательный ответ. Таким образом, покупая программу, можно использовать только определенный набор опций. Хорошо, если они покрывают абсолютно все запросы, но по нашему опыту так случается редко. Например, однажды нам необходимо было связать данные из известной HR-программы с ПО для выплат вознаграждения. Для решения этой на первый взгляд простой задачи пришлось приложить кучу усилий, поскольку данные передавались с неподходящим синтаксисом, а техподдержка не смогла помочь с внесением изменений. Работа с Jira всегда предоставляет нам больше возможностей для внедрения персонализированных настроек и расширения функционала под индивидуальные потребности. У тебя практически нет границ (точнее, они очень широки). Появляется необходимость в расширении возможностей — допиливаем новые функции.

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

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

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

Безопасность. Чем больше создается взаимосвязей между разными программными пакетами (особенно при использовании дополнительных плагинов и приложений для их связи), тем больше уязвимостей и возможностей для нарушения конфиденциальности и перехвата информации. Сторонние приложения обычно требуют высокий уровень доступа в систему (на уровне администратора), но при этом не несут ответственности за сохранность данных. То есть в случае компрометирования их сервиса злоумышленники также получают администраторский доступ в системы, подключенные к подобным сервисам. В дополнение — не все компании доверяют платформам, которые хранят данные у себя, без возможности хранить их на собственных серверах.

Унификация. Если бы сейчас сказать нашим менеджерам изучить специальное ПО для процессов найма, еще одно — для адаптации, потом для администрирования и апрува тайм-офов, а затем для оценки 360, ПО LMS для обучения и так далее, они бы половину своего времени тратили на новые интерфейсы. А после этого имели кучу точек входа, пар «логин-пароль» и большую вероятность в них запутаться. При использовании Jira для покрытия максимального количества потребностей у пользователя всегда есть только одна точка входа и знакомый интерфейс.

И last but not least: когда ты анализируешь целесообразность покупки дополнительной программы и понимаешь, что абсолютно все твои запросы сейчас покрываются Jira, система отлажено работает, а внедрение нового инструмента повлечет только дополнительные сложности и затраты — решение напрашивается само собой.

Таким образом Jira начала проникать во все большее количество процессов компании. Постепенно возникали новые и новые запросы. Их реализация поспособствовала тому, что сейчас для 85% представителей Boosta Jira является инструментом, через который проходят все задачи.

Техническая реализация

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

Рекрутинг

Проект «Рекрутинг» делится на два типа запросов:

«Вакансия» (таск).
«Кандидат» (субтаск).

Постановщиком задачи типа «Вакансия» выступает менеджер, который открывает позицию. Он заполняет большое количество полей, позволяющее понять портрет кандидата (пол, возраст, скиллы, размер вознаграждения, задачи на испытательный срок и прочее). В общей сложности необходимо заполнить 47 обязательных параметров. Это самый объемный таск в нашей системе. Но подобный подход к детализации помог значительно повысить качество рекрутинга в компании.

После постановки вакансия проходит процесс согласования. Сначала рекрутер проверяет правильность заполнения и достаточность информации. Далее заявка уходит на согласование руководству. Оно может быть 2- или 3-уровневым в зависимости от человека, который хочет открыть позицию. После получения апрува таск возвращается к рекрутеру, который берет его в работу.

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

Реализовано это через REST Endpoint ScriptRunner и выводится как HTML-страничка на дашборде:

import com.onresolve.scriptrunner.runner.rest.common.CustomEndpointDelegate
import com.atlassian.jira.bc.issue.search.SearchService
import com.atlassian.jira.web.bean.PagerFilter
import com.atlassian.jira.component.ComponentAccessor
import groovy.transform.BaseScript
import javax.ws.rs.core.Response
import javax.ws.rs.core.MediaType

@BaseScript CustomEndpointDelegate delegate
hr_table (httpMethod : "GET", groups: ["jira-users"]) {
    def jql = 'ENTER YOUR JQL FOR TASKs'
    def admin = ComponentAccessor.getUserManager().getUserByKey('admin')
    String response = ''
    String color
    response+='<table border = "1" class="table aui table-hover table-bordered">'+
            '<thead class="thead-dark"><th>Приоритет</th><th>Вакансия</th><th>Статус</th><th>Команда</th><th>Таск на вакансию</th></thead>'
    def searchService = ComponentAccessor.getComponentOfType(SearchService)
    def customFieldManager = ComponentAccessor.getCustomFieldManager()
    SearchService.ParseResult parseResult = searchService.parseQuery(admin, jql)
    def results = searchService.search(admin, parseResult.query, PagerFilter.unlimitedFilter)
    def issues = results.results //List of valid issues
    if (issues){
        issues.each{
            Integer counts = it.getCustomFieldValue(customFieldManager.getCustomFieldObject("customfield_18300")) as Integer //Point customfield
            if(counts>=10){
                color='class="table-danger"'
            }else if(counts>6 && counts < 10){
                color='class="table-warning"'
            }else if(counts>=4 && counts<=6){
                color='class="table-success"'
            }else if(counts <4){
                color='class="table-info"'
            }
            def team = it.getCustomFieldValue(customFieldManager.getCustomFieldObject("customfield_10742")) //Team Customfield
            String href_vac_link = '<a href="http://jira.yourdomain.com/browse/'+it.key+'">'+it.key+'</a>'
            response += '<tr>'+'<td '+color+ '>'+counts+'</td>'+'<td>'+
                    it.summary+'</td>'+'<td>'+it.status.getName()+'</td>'+'<td>'+team+'</td>'+'<td>'+href_vac_link+'</td>'+'</tr>'
        }
    }
    response += '</table>'
    Response.ok().type(MediaType.TEXT_HTML).entity(response.toString()).build()
}

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

Workflow «Кандидата» включает в себя следующие статусы:

Согласование менеджером.
Телефонное интервью.
Первое собеседование.
Второе собеседование.
Тестовое задание.
Тестовый день.
Отправка офера.
Офер принят/отклонен.

Сам workflow выглядит следующим образом:

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

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

Замер узнаваемости

Длительное время мы думали о том, каким образом внедрить механику замера узнаваемости на регулярной основе и «оцифровать» это значение. Несколько месяцев назад нашли решение в том же субтаске «Рекрутинг» в Jira.

Сейчас при переведении «Кандидата» из статуса интервью в любой другой статус добавили дополнительный функционал. Рекрутеру высвечивается несколько полей, которые необходимо заполнить:

«Знал ли кандидат о компании ранее» (да/нет) — обязательное поле.
«Характеристика компании» (положительная/отрицательная/смешанная/нейтральная) — если ответ на первый вопрос «да».
«Источник» — если ответ на первый вопрос «да».
«Предоставленная информация» — если ответ на первый вопрос «да».

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

Адаптация

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

У каждого есть доступ только к своей карточке. Общий доступ к этому проекту предоставлен только HR-менеджерам. Если кто-то хочет посмотреть информацию о коллеге, он использует для этого другой (сторонний) инструмент.

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

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

После выхода человек входит в свою карточку и нажимает кнопку «Адаптация, день 1». Автоматически создается 18 заданий, которые ему необходимо выполнить в свой первый день. Например, по заполнению корпоративных профилей, ознакомлению с различными правилами, основной информацией о компании, условиями работы и ключевыми процессами.

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

После выполнения каждое задание проверяет HR-менеджер. При необходимости он вносит коррективы и помогает.

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

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

В качестве завершающей части задач («карточек») данного проекта реализован обходной лист. Когда по каким-то причинам происходит расставание с коллегой, его карточка переводится в статус «Увольнение». При этом создается новый субтаск, у которого есть свой специфический workflow. Сначала процесс вовлекает самого сотрудника: человек получает указания по передаче дел и переводит все свои незакрытые задачи на коллег. Далее субтаск переходит на менеджера, который подтверждает, что учетные записи можно закрывать. После этого исполнителем выступает Helpdesk, который блокирует доступы и учетные записи. Финансовый отдел выплачивает оставшуюся сумму вознаграждения, Helpdesk принимает технику, а административный отдел — ключ доступа к офису.

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

Образование

Еще одним примером замены ручной обработки информации и кучи рассылок в почте стал проект «Образование». В нем происходит полный цикл работы с заявками на посещение конференций, курсов и других образовательных мероприятий: от получения запроса от сотрудника до шеринга впечатлениями и материалами.

Схема реализована следующим образом:

Человек создает таск на посещение мероприятия.
Таск проходит апрув у руководителя.
Таск берет в работу Education Manager. Он согласовывает формат покупки билета, компенсацию стоимости (по корпоративным правилам компания оплачивает 100% при стоимости до 1000 грн и 80% при стоимости свыше 1000 грн) и другие детали.
Создается таск на оплату.
При необходимости (если мероприятие проходит в другом городе или стране) — создается таск на организацию поездки для административного отдела.
Сотрудник получает билет и все документы на почту.
После посещения делится итогами в комментариях. Все предоставленные файлы и отзывы Education Manager загружает в образовательную базу компании.

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

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

Бронирование Boosta HUB

В компании существует свой небольшой конференц-зал, который в основном используется для внутренних мероприятий. Изначально его бронирование проводилось максимально простым способом — через Google Calendar. Но наш HUB — очень адаптивное пространство, которое можно модифицировать в зависимости от потребностей ивента. Мы быстро обнаружили, что при самостоятельном бронировании люди забывают о подготовке помещения и за пару минут до начала судорожно ищут офис-менеджера и просят о помощи. Так люди, которые не занимаются организацией мероприятий на регулярной основе, могут не предусмотреть много факторов. И если переставить стулья и убрать столы еще получится оперативно, то на зарядку микрофона или поиск специфического переходника уходит значительное количество времени.

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

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

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

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

Финансовые процессы (оплаты + бюджетирование)

Для администрирования финансовых процессов у нас созданы отдельные проекты «Оплата» и «Бюджетирование» в Jira.

В проекте «Оплата» каждый платеж оформляется отдельным таском. При его создании заполняются все необходимые параметры:

сумма;
валюта;
формат оплаты;
реквизиты;
статья расходов и прочее.

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

Процесс бюджетирования проводится на ежеквартальной основе. Один раз в квартал все ответственные за определенные статьи расходов специалисты получают задачу на заполнение бюджета в проекте «Бюджетирование». Планы по расходам вносятся в систему и согласовываются с руководством. После этого бюджет становится активным на указанный период.

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

Учет доменов

Специфика работы компании подразумевает наличие большого количества доменов. Конечно, на рынке есть множество решений для ведения их учета, а также хранения смежной информации о регистраторах, хостингах и тому подобное. Но на практике мы столкнулись с тем, что у каждого отдела (финансового, разработчиков, системных администраторов и SEO-специалистов) были созданы свои Excel-таблицы, данные из которых хотелось свести воедино для централизации.

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

дату покупки;
дату следующей оплаты;
информацию о хостинге;
информацию о регистраторе;
ответственного за SEO;
ответственного за разработку;
ответственного за оплаты;
приоритет;
статистику по доступности домена за последние 7/14/30 дней и другое.

Статистику по доступности и статус мониторинга Jira получает из Prometheus.

Поле «приоритет» позволяет нашим отделам разработки и дизайна приоритизировать задачи и ускоряет выполнение задач по ключевым проектам компании. При этом после создания задача назначается на РМ’а, указанного в карточке домена.

Также проект «Домен» автоматизирует некоторые процессы. Например, с его помощью разработчик может очистить кэш домена на Cloudflare, не имея туда доступа: Jira сделает это автоматически и напишет об этом в комментариях к задаче.

Планы

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

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

Основные плагины, которыми при этом пользуемся:

AIO Reports — самый мощный инструмент для отчетов.
ScriptRunner — дополнительные JQL-функции и скрипты для сложных автоматизаций.
Project Automation — автоматизация с максимально простым и удобным интерфейсом.

Конечно, не все так гладко и существуют подводные камни в использовании Jira:

Все же система создавалась не для этих целей. Подобная кастомная доработка предполагает использование Jira не по прямому назначению.
Можно найти более адаптированные под конкретные задачи решения. Здесь всю логику мы создаем вручную и с нуля, а в специализированном ПО об этом уже позаботились его разработчики.
Влияние на UX/UI ограничено архитектурой самой системы, и в некоторых моментах придется мириться с дизайном/функционалом. С одной стороны, это плюс, поскольку интерфейс для всех привычный и понятный, но с другой — речь о привлечении дизайнера и создании «красивой» картинки не идет.
Необходимо иметь в штате выделенного специалиста. Для компании это дополнительные расходы, есть риск ухода специалиста и сложность его замены, поскольку рынок узкий.
Когда у вас большая команда и существуют процессы согласования, вы столкнетесь с тем, что Jira не понимает разницы между пользователями (я не говорю об очевидных типа "группы"/"роли"). И, соответственно, выстроить в самой системе иерархию пользователей просто так не получится. Для решения данной проблемы пришлось создавать обходные пути, хотя в специализированных сервисах это уже предусмотрено и нет нужды изобретать велосипед.
Зависимость от одной системы — представьте, что у хостинга провайдера случились проблемы в ДЦ. В такой ситуации возникнут сложности в работе практически всех отделов.

Несмотря на это, Jira нам позволила автоматизировать и упростить множество процессов. Это подтверждает на практике, что подход имеет право на жизнь.

Читайте еще: Как настроить Jira для управления бэклогом: пошаговая инструкция