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

SergeyMax 3 фев 2023 в 09:39

научиться закрывать старьё так, чтобы заказчики по этому поводу не возмущались

Был такой анекдот про кошку и горчицу, который заканчивался фразой "добровольно, и с песней!"

R72 3 фев 2023 в 09:24

Ваше решение проблемы выглядит так:

1) Провели ревизию дублей задач. Это сразу уменьшило очередь на 50% почти.

2) Провели организационные меры - добавили статусы задач, переносящие часть задач на инициаторов задачи

2.1) Ввели статус типа "на приёмке у инициатора"

2.2) Ввели статус "на согласовании у инициатора"

что ещё больше сократило очередь (точнее перекинуло часть очереди с вашего отдела а инициаторов)

3) Ограничили работу 4-мя задачами, остальные в мусор-неважные-делаемпостолькупосколькуможем

Подозреваю, что такие мусорные задачи убедили руководство вынести из KPI вашего отдела (иначе смысла бы в этом решении не было).

Гениально! Но банально. Годик стажа так можно прожить пока до всех дойдёт.

Все решения организационного вида. Не ИТшные.

Технологических решений и причин, как видно, не было выявлено:

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

Dmitrii_Andreev 3 фев 2023 в 13:41

Спасибо за развернутый коммент! Цель статьи как раз и показать, что путем правильной организации процессов, не обязательно внедрять какие-то сложные технические решения. При рациональном подходе даже расширение штата не требуется.
Давайте немного остановимся на ваших пунктах:

Количество задач не всегда колеруется с плохим кодом и архитектурой. Оно может зависеть от незнания того, когда нужно заводить технический тикет, от недостаточной первичной диагностики. Так же не забываем, что тикеты могут быть с предложениями об улучшении чего то на сайте, запросы на получение какой-то информации (как что-то работает, как должно работать и т.д.). Правильное выстраивание процессов помогает быстро обрабатывать поток любого вида задач.
Недостаточная фильтрация тоже безусловно имела место быть, и выявление источников нагрузки помогло это заметить.
В статье внимание было заострено на тех. поддержке, но это лишь один из отделов, который обращается в БП, на самом деле тикеты идут практически со всех отделов компании. И да, структура тех. поддержки не была идеальной, взять хотя бы отсутствие скриптов, упомянутых в статье. Выстраивание процессов - это не только внутренние изменения в одном департаменте, это в том числе и диалог коллегами из смежных департаментов и внедрение нового подхода там.
Такой принцип был введен в ходе изменения процессов, это упоминается в статье. Мы же не просто так закрыли некоторые задачи :), были внедрен регулярные встречи с заказчиками и обсуждение тех задач, которые в принципе не будут делаться, а по каким-то можно найти компромисс.
В БП обращается не только тех поддержка, но и другие команды. Исходя из вашего опыта, как бы вы внедрили принцип, что "задач должно быть не больше, чем ресурсов на их решение"? Когда человек обращается в БП, у него есть какой-то насущный вопрос, который он хочет решить или какая-то информация, которую он хочет получить, он не обязан знать про количество ресурсов разработки или каких либо иных ресурсов, ему интересно решение его проблемы. Есть способы снизить количество обращений (некоторые из которых я описал в статье), но строго ограничивать количество входящих тикетов каким-то KPI, я считаю, не совсем верно.
Вы правильно подметили, ее толком не было. Появилась она после тех шагов, которые мы прошли. Были написаны шаблоны действий, статьи по часто встречающимся вопросам, и т.д.

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

Prion 5 фев 2023 в 15:05

У меня есть большие подозрения, что дело не в новой методологии. А кто то из менеджеров забил на задачи. Никого не смущает почему выстроилась такая очередь? Как не допустить увеличения очереди? Кто то делал разбивку по задачам какого типа задачи больше всего в очереди? Пытались как то автоматизировать? Пытались мелкие задачи объединить в пакет,а большие задачи дробить? Организовывались встречи с другими отделами по поводу задач?

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий