Концерт по заявкам: как мы автоматизировали Яндекс.Трекер
Недавно в одном из профессиональных чатов снова всплыл вопрос о Яндекс.Трекере. Оказалось, что мы не единственные, кто активно использует его в работе агентства.

Хотя, по моим субъективным наблюдениям, большинство коллег все-таки сидят на Битриксе24 или Jira — но это уже другая история.
За несколько лет использования Трекера мы успели хорошо разобраться в системе. Она своеобразная, со своими особенностями, но в целом довольно гибкая и мощная. Где-то лежит начатая статья про всю автоматизацию, которую мы внедрили: там и сам Трекер, и самописные решения, и связка с Google Таблицами, и внутренняя аналитика. В общем, «цифры, цифры, цифры», но руки до этой статьи пока не дошли.
Сегодня хочу поделиться конкретным списком автоматизаций, которые мы используем в работе. Что-то мы придумали сами, что-то подсмотрели в чате, а что-то посоветовали коллеги. Возможно, вам что-то из этого пригодится для вашего бизнеса, проектов или команд.
Важно понимать: многие триггеры у нас связаны между собой. Например, один добавляет комментарий к задаче, другой тут же шлёт его в Telegram.
Уведомление исполнителя об активации задачи
У нас довольно много задач в статусе «Отложено» — это своеобразный бэклог. Они ждут своего часа. Чтобы не теряться в этом потоке, мы сделали так: как только автор активирует задачу, триггер автоматически упоминает исполнителя в комментарии, чтобы тот точно не пропустил новую работу.
Уведомление автора о готовности задачи
Когда исполнитель завершает работу и задача переходит в статус «Ожидаем проверки», система автоматически призывает в комментарии автора или менеджера, чтобы они проверили результат.
Уведомление QA
Если задача готова, но ещё не протестирована, триггер уведомляет нашего QA-специалиста. Он получает уведомление, берет задачу в свою очередь и приступает к тестированию.
Просроченные задачи
Мы больше работаем со списками, чем с канбаном. Но в Яндекс.Трекере, в отличие от Битрикса или Wrike, просроченные задачи в списке ничем не выделяются. Чтобы решить этот момент, у нас настроен триггер, который проверяет дедлайны. Если задача просрочена, в ней автоматически появляется комментарий с упоминанием автора и исполнителя: «Ребята, тут что-то не так».
Подсчет возвратов на доработку
Мы считаем, сколько раз задача вернулась на доработку. Это один из наших показателей качества постановки и исполнения задач.
Автоматическая очистка поля «Ждёт ответа»
В Трекере есть специальное поле — своего рода флажок «ждём ответа от пользователя». Но если задача закрыта и полностью готова, понятно, что никаких ответов уже не требуется. Поэтому при закрытии задача автоматически очищается от этого флажка.
Очистка дат при переходе в «Отложено»
Если задача по каким-то причинам откладывается после полного цикла работы (например, требует доп. согласований), у неё обычно остаются заполненные даты начала и дедлайна. Чтобы не возникало путаницы, при переводе в статус «Отложено» все даты автоматически обнуляются. Этот статус у нас своего рода «бутылочное горлышко»: если задачу решат активировать заново, через него точно пройдут.
Оценка задач
Как только по задаче появляется оценка, триггер отправляет её в нашу внутреннюю систему для дальнейшей обработки и аналитики.
Сбор обратной связи: оценки автора и исполнителя
Мы внимательно следим за качеством процессов. Исполнитель может оценить постановку задачи по 5 параметрам по 5-балльной шкале. В свою очередь, автор задачи (менеджер или инициатор) оценивает исполнителя по аналогичным критериям. Эти данные идут в систему для последующего анализа.
Интеграция комментариев с Telegram
У нас есть Telegram-бот, который уведомляет о отпусках, новостях и другой важной информации. Мы интегрировали с ним и Яндекс.Трекер. Теперь любой комментарий в задаче автоматически уходит в нужный чат, и команда сразу видит, что происходит.
Учёт затрат времени
Все данные о потраченном времени, которые исполнители заносят в Трекер, автоматически передаются в нашу систему учёта. Про саму миграцию на этот подход и нюансы можно рассказать отдельно — это целая история.
Контроль невзятых задач
У нас есть промежуточный статус «Активно» — задача должна быть в работе. Но иногда исполнитель по каким-то причинам не приступает к ней вовремя. Если наступает дата начала задачи, а статус остаётся «Активно», система пишет комментарий: «Почему задача не в работе?». Это помогает авторам вовремя отреагировать.
Шаблон описания для задач
Чтобы все задачи были структурированными, мы используем шаблон описания. Автоматизация добавляет этот шаблон в тело задачи при создании.
Назначение QA-наблюдателя
При старте задачи важно, чтобы QA мог заранее подключиться, дать советы или увидеть возможные проблемы. Поэтому у нас есть триггер, который автоматически добавляет QA в наблюдатели.
Уведомление о перерасходе времени
С переходом на учёт времени мы стали следить за тем, чтобы задачи укладывались в оценку. В каждой задаче есть поле «Оценка» — например, 8 часов. Если исполнитель начинает выходить за рамки, появляется прогресс-бар. Чтобы автор был в курсе перерасхода, триггер шлёт уведомление: «Обрати внимание, задача выходит за пределы оценки». Всё это внедрено максимально лояльно, без излишнего контроля, но помогает следить за процессом.
P.S. Термины «Автор» и «Исполнитель» могут звучать сухо, но это стандартные обозначения из самого Яндекс.Трекера — так просто удобнее и привычнее.
Конечно, у всех этих триггеров есть свои нюансы, иногда случаются казусы и даже зацикливания, но это уже тема для отдельного разговора.