Таск-трекер для IT-отдела: заявки, инциденты и проекты в одной системе

Таск-трекер для IT-отдела должен держать три разных потока работы: заявки пользователей, инциденты и проекты с изменениями. У каждого потока свой тип задачи, свои статусы и свои сроки. Если свалить всё на одну доску, срочное вытесняет важное, а руководитель не может ответить, чем занят отдел. Если потоки развести, хватает одной системы без отдельного helpdesk, отдельного трекера и таблицы с проектами.

Статья для руководителей IT-отделов и тимлидов внутренних команд в Казахстане. Разбираем, как настроить потоки в Plane или Jira, как принимать заявки, договориться об SLA, организовать дежурства и собрать отчёт для руководства. В конце перечисляем признаки того, что таск-трекера уже мало и нужен ITSM.

Три потока работы IT-отдела

Внутренний IT-отдел работает в трёх режимах одновременно.

Заявки. Пользователь просит что-то сделать: выдать доступ, настроить ноутбук, подключить принтер, выгрузить отчёт. Работа мелкая, повторяющаяся, и её много. Важно время реакции и то, чтобы заявка не потерялась.

Инциденты. Что-то сломалось: упала почта, не работает учётная система, лежит VPN, сайт отдаёт ошибку. Работа непредсказуемая и срочная. Важно быстро найти ответственного, восстановить сервис и потом разобрать причину.

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

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

Типы задач, статусы и сроки по потокам

Основа настройки — отдельный тип задачи на каждый поток. В Plane это Work item types, в Jira — типы задач со своими workflow. Схема, с которой мы обычно стартуем:

Поток	Тип задачи	Статусы	Срок и SLA
Заявки	Заявка	Новая → В работе → Ждёт пользователя → Решена → Закрыта	Реакция и решение по приоритету
Инциденты	Инцидент	Зарегистрирован → Диагностика → Восстановлен → Разбор → Закрыт	Реакция в минутах, восстановление в часах
Повторяющиеся сбои	Проблема	Открыта → Анализ причины → Исправление → Закрыта	Без жёсткого SLA, контроль на еженедельной встрече
Изменения	Изменение	Запрошено → Согласовано → Запланировано → Выполнено → Проверено	Окно работ и согласование
Проекты	Задача, эпик	Бэклог → В работе → Проверка → Готово	Сроки этапов и циклов

Несколько принципов.

• Статусов меньше, чем хочется. Пять-шесть на тип достаточно. Каждый лишний статус — место, где задача застрянет.
• Статус «Ждёт пользователя» обязателен для заявок. Без него ожидание ответа съедает SLA, и инженеры начинают закрывать заявки, не дождавшись подтверждения.
• Инцидент и проблема — разные сущности. Инцидент закрывается, когда сервис восстановлен. Проблема закрывается, когда устранена причина. Повторяющиеся инциденты связываются с одной проблемой.
• Изменения на рабочих системах проходят через согласование. Даже если согласующий один, факт согласования фиксируется в задаче.

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

Приём заявок: один вход вместо пяти

Главное правило: работа начинается только с задачи. Сообщение в мессенджере, звонок или разговор в коридоре — повод создать задачу, а не сама задача.

Каналы приёма:

1. Форма. Короткая форма с полями: что случилось, кто заявитель, отдел, срочность, вложение. В Plane это Intake: заявки из формы или с почтового адреса попадают в отдельную очередь, где дежурный их принимает или отклоняет.
2. Почта. Отдельный адрес для заявок. Письмо превращается в задачу, переписка остаётся в её истории.
3. Мессенджер. Заявки из WhatsApp и Telegram дежурный переносит в очередь сам или через бота. Ответ пользователю — ссылка на задачу или номер заявки.

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

Контекст Казахстана. В большинстве казахстанских компаний сотрудники привыкли писать в WhatsApp, и запретить это не получится. Рабочий компромисс: мессенджер остаётся каналом связи, а задача — единственным местом учёта. Форму приёма делайте на русском и казахском, если в компании есть сотрудники, которым удобнее казахский. И помните, что в заявках бывают имена, телефоны и иногда документы сотрудников. Если компании важно хранить такие данные в Казахстане, подойдёт self-hosted трекер на сервере в стране, облачные сервисы с хранением за рубежом — нет.

Приоритеты и SLA

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

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

Приоритет	Когда ставится	Реакция	Решение
P1 Критичный	Не работает сервис для всей компании или ключевого процесса, обхода нет	15 минут	4 часа
P2 Высокий	Затронут отдел или руководитель, обход неудобный	1 час	1 рабочий день
P3 Обычный	Один пользователь, обход есть	4 часа	3 рабочих дня
P4 Низкий	Пожелание, плановая настройка	1 рабочий день	По плану

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

Как считать SLA на практике. В Jira Service Management SLA-таймеры с календарём рабочего времени встроены. В Plane и в Jira без сервисного модуля SLA контролируется через срок задачи, приоритет и автоматизации: срок ставится при триаже по таблице приоритетов, запланированные автоматизации (в Plane это Runner, в Jira — Jira Automation) напоминают ответственному о задачах с подходящим сроком, а дашборд показывает просрочки. Для отдела в 10–30 человек такой схемы обычно достаточно.

Инциденты и дежурства

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

Как мы настраиваем:

• График дежурств ведётся на странице в Pages или в Confluence. Дежурный назначается исполнителем всех новых инцидентов в свою смену.
• Уведомления. Новый инцидент с приоритетом P1 сразу уходит дежурному и в канал команды через интеграцию со Slack или через бота в мессенджере.
• Ведение инцидента. В задаче фиксируются время начала, затронутые сервисы, действия и время восстановления. Комментарии пишутся по ходу, а не задним числом.
• Разбор. После восстановления — короткий разбор на странице, связанной с инцидентом: что случилось, почему, что сделаем, чтобы не повторилось. Действия из разбора становятся задачами с исполнителем и сроком.
• Эскалация. Если дежурный не взял инцидент за время реакции, уведомление получает руководитель. Это настраивается автоматизацией или закрепляется регламентом.

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

Проекты и изменения рядом с операционкой

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

Что помогает:

• Отдельный проект для заявок и инцидентов. Операционка живёт в своём проекте и не смешивается с проектной работой. Проекты делятся на Modules и Cycles в Plane или на эпики и спринты в Jira.
• Квота на операционку. Договоритесь, какую долю времени команда отдаёт заявкам и инцидентам. Остальное — проекты. Time tracking в задачах показывает, выдерживается ли квота.
• Ротация. Один-два инженера в неделю закрывают заявки, остальные работают над проектами. Это снижает число переключений.
• Изменения через согласование. Любая работа на рабочей системе оформляется задачей типа «Изменение» с окном работ и планом отката.

Метрики и отчёт руководителю

Отчёт руководителю отвечает на три вопроса: справляется ли отдел с потоком, где горит и куда уходит время. В Plane он собирается в Dashboards, в Jira — в дашбордах на JQL-фильтрах.

Метрика	Что показывает	Как часто смотреть
Входящий поток заявок по неделям	Нагрузку и сезонность	Еженедельно
Время первой реакции по приоритетам	Скорость приёма	Еженедельно
Время решения по приоритетам	Скорость работы	Еженедельно
Доля нарушений SLA	Выполнение договорённостей с бизнесом	Ежемесячно
Открытые заявки старше срока	Забытые хвосты	Еженедельно
Повторные инциденты по сервисам	Слабые места инфраструктуры	Ежемесячно
Доля времени на проекты и операционку	Соблюдение квоты	Ежемесячно
Статус ключевых проектов	Движение по инициативам	Раз в две недели

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

Когда таск-трекера мало и нужен ITSM

Таск-трекер с настроенными потоками закрывает потребности большинства небольших и средних IT-отделов. Но есть признаки, что пора смотреть на ITSM-систему, например Jira Service Management:

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

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

Учитывайте сроки и размещение. Облачные продукты Atlassian хранят данные в регионах, среди которых нет Казахстана. Data Center больше не продаётся новым клиентам с 30 марта 2026 года, а поддержка заканчивается 28 марта 2029 года. Если требования к хранению данных в стране жёсткие, приём заявок через Intake в self-hosted Plane часто оказывается практичнее.

Как мы это делаем

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

Если хотите навести порядок в работе IT-отдела, посмотрите страницу внедрения таск-трекеров Jira и Plane: там описан процесс, сроки и что входит в результат.

---

Источники. Таймлайн Data Center: atlassian.com/enterprise/data-center. Регионы хранения данных Atlassian Cloud: документация Atlassian. Репозиторий Plane: github.com/makeplane/plane.

Термины простыми словами

SLA

Согласованный с бизнесом срок реакции и решения по заявке в зависимости от приоритета. Его публикуют для всех сотрудников и пересматривают по фактическим данным.

Инцидент и проблема

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

ITSM

Класс систем для управления IT-услугами: портал для сотрудников, каталог услуг, очереди, таймеры сроков. Нужен крупным отделам с формальными регламентами, небольшим часто хватает трекера.

Intake

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

Триаж

Первичный разбор заявки: проверить, что это задача для IT, поставить тип и приоритет, назначить исполнителя. Не пускает сырые обращения в рабочий список.

Эскалация

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

Портал самообслуживания

Страница, где сотрудник сам выбирает тип запроса и видит статус своей заявки. Один из признаков, что отделу уже нужна ITSM-система.

Self-hosted

Трекер на собственном сервере компании. Если в заявках есть данные сотрудников, установка на сервере в Казахстане оставляет их в стране.