Яндекс Трекер — мощный инструмент. Это я говорю себе каждый раз, когда настраиваю экран перехода вместо простого чек-бокса «обязательное поле». Эта статья — о любви, боли и изощрённости. В честь 1 апреля решила поделиться с вами любимыми костылями

🩼🩼

Костыль #1. Настройка обязательных полей при создании задачи

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

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

Заходишь в Очереди > Настройки очереди > Рабочие процессы

И между статусами «Новый» и «Готов к работе» вставляешь экран перехода, в котором задаешь все поля, которые должны быть обязательно заполнены в задаче.

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

Костыль #2. Исключение отдельных задач из Leadtime

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

Честно ли исключать тухлые задачи из метрик? Нет. Но кто из нас без греха?

Идешь в Администрирование > Задачи > Поля задачи
Создаешь поле «Исключить из Leadtime» — «Целое число».

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

Источник данных: «Исключить из Leadtime»: empty() OR «0».

Костыль #3. Автоматическое заполнение полезных полей на задачах

Дата создания в Трекере есть. Но в дашборды она не лезет — характер такой

В каждом проекте я задаю автоматическое заполнение следующих полей: Дата создания и Дата завершения. Потому что я активно их использую в дашбордах и отчетах.

Также не забываем про резолюцию, она тоже важна.

Заходишь в Очереди > Настройки очереди > Рабочие процессы.

И через автоматизацию на переходах добавляешь заполнение даты и резолюции. Если использовать две резолюции «Решен» и «Не будем делать», то при переходе в статус Закрыт автоматом прописываешь резолюцию «Решен», при переходе в «Отменен» — «Не будем делать».

При перекрытии задач не забудь очищать резолюцию и даты завершения:

А вот для заполнения Даты создания придется настроить Триггер:

Заходишь в Очереди > Настройки очереди > Автоматизации > Создать триггер

Костыль #4. Автоматическое назначение Исполнителем нужных людей

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

Теперь всегда видно, кто это натворил. В хорошем смысле

Настраиваешь заполнение через рабочий процесс и Автоматизацию на переходах:

Так, при взятии задачи «В работу» Исполнителем назначается тот, кто двинул задачу в этот статус и дополнительно этот человек сохраняется в поле Разработчик, чтобы не потерялся потом.
При переводе в статус «В тестировании» заполняются поля Тестировщик и он же назначается Исполнителем. При переводе в статус Бизнес-ревью задача возвращается на Автора задачи.

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

Костыль #5. Нотификации в Telegram отдельным пользователям

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

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

Для этого создаешь Telegram-бота (например, с помощью @BotFather) и через триггер шлешь ему сообщение:

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

Костыль #6. Счетчик переоткрытых обращений

Одна из метрик, за которой я слежу — это сколько раз было переоткрыто обращение HELPDESK. Если более унифицироунифицировано сформулировать этот запрос: то чтобы посчитать  через интерфейс, сколько раз задача проходила один и тот же статус, придется покостылить. 

Для этого я не придумала ничего проще, чем создать дополнительные поля-счетчики, которые увеличиваются при попадании задачи на этот статус.

Создаешь поле «Переоткрыт»:

Создаешь поле-помощник для работы счетчика:

Через Триггер вместе с датой создания заполняешь начальные значения этого счетчика:

При перекрытии я увеличиваю счетчик следующим образом:

Теперь я могу собирать нужную мне статистику в дашборде очень просто:

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

Костыль #7. CSAT-опрос

Анонимность — это святое. Особенно когда оценка 1 из 5

Любой хороший CSAT-опрос должен быть анонимным, поэтому пришлось вынести его из трекера наружу. Как я это сделала?

При Закрытии задачи отправляется событие через webhook, которое ловит n8n и далее с помощью Telegram-бота отправляет автору задачи вопрос с запросом оценки удовлетворения качеством и скоростью задачи. Оценки записываются в локальную БД, для удобства я вывела их себе в Datalens и слежу за ними.

За этот костыль точно не стыдно, вообще не костыль, а скорее лайфхак.

Костыль #8. Story Points через майки

Еще до того, как Яндекс Трекер начал строить графики Производительности команды в Story Points, я приучила команду оценивать задачи майками (T-shirt sizing (XS/S/M/L/XL)).  

Переучивать людей — это change management. Написать триггеры — это 20 минут. Выбор очевиден

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

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

Костыль #9. Напоминание о дедлайне регулярных событий 

В моей команде, которая занимается разработкой сайтов, целый календарь с датами продления лицензий: хостинги, лицензии битрикс, доменов, сертификатов, подписок).
Я решила поэкспериментировать и перенести этот календарь в Трекер.

Создаешь отдельную очередь, например LICENSE. Заводишь туда все эти шутки в виде задач.

В тело задачи заносишь всю необходимую информацию: для какого клиента, как оплачивается лицензия по счету/или в конце месяца вместе с тех.поддержкой, кто менеджер проекта, вообщем все данные (кроме кредов конечно — для них есть система хранения паролей)
Исполнитель — менеджер или финансовый администратор, который подтверждает актуальность данных и следит  за самым важным в этих задачах — дедлайном.
Уведомления по дедлайнам настраиваешь в Telegram в групповой чат, где есть менеджеры и системный администратор или девопс.
Менеджер ставит апрув на нотификацию и девопс подхватывает выполнение нужных действий на продление.
После этого менеджер двигает дату дедлайна на следующий период, когда нужна дата продления (через месяц, год или квартал)

Можно извратиться и настроить таким образом календарь check-in по OKR, например.
Потому что про них всегда тоже все забывают.

Костыль #10. Календарь дежурств

В Костыле #4 я рассказала, как назначать нужных Исполнителей автоматически. Но представим более сложный кейс, когда в команде есть дежурства, как здесь назначить дежурного исполнителем? Откуда взять инфу, если календаря дежурств в Трекере нет. Тут уже пришлось призвать «Бога костылей».

Итак, тебе потребуется: календарь дежурств, и кто-то, кто умеет вайбкодить на n8n.

Настраиваешь на n8n несложный процесс, который:

3. Ежедневно получает по API данные из календаря дежурств (он может быть в почте/расшаренном документе/вики или в какой-нибудь базе данных)

4. Ловит новые обращения из Трекера 

5. Отправляет в корпоративный чат сообщение кто страдает дежурит сегодня

6. Назначает дежурного исполнителем задачи через API трекера

Также не забываем прихранить это в каком-нибудь дополнительном поле «Дежурный», чтобы потом легко использовать в отчетах.

Вот такой набор костылей в нашем Трекере. Работают и ладно!