#статьи #кейсы

Значение процессов и инструкций на проекте

Начало истории в предыдущем посте.

Часть 2. Что мы сделали
Перед нами стояла задача быстро разобраться в подводных камнях поддержки масштабного проекта – более 100.000 строк C#. Это был сложный челлендж!
Итак, что мы делали:
1️⃣ Поняли, что мы постоянно имеем дело с внушительным объемом запросов от пользователей на саппорт и нужно что-то менять. Теперь при их выполнении собирали статистику по типам и частоте запросов.
2️⃣ Закрыли устаревшие задачи, которые были созданы более 2 месяцев назад. Вместе с тем нашли 30-40 задач без метки саппорта: выбрали их из треда «без метки», добавили метку – иначе они не отображались в задачах саппорта.
3️⃣ Нашли первое место для улучшения: сделали отдельный проект в Jira. До этого задачи саппорта создавались в том же проекте, что и задачи для разработки, но с пометкой Support.
4️⃣ Обновили админки во всех госпиталях до единой версии, так как она стала средством доставки фиксов. Сама админка не участвовала в бизнес-процессах, только настраивала их, поэтому можно было обновить все админки до последних версий.
5️⃣ На основании собранной статистики поняли: нужно временно начать перерабатывать, чтобы впоследствии ускорить работу. Иногда для ускорения каких-либо действий саппорта в таких длительных проектах нужно 3-4 часа программировать, чтобы потом сэкономить 5–7 минут при изучении определенных типов запросов, в первую очередь повторяющихся.
6️⃣ Создали специальную страницу-саппорт с инструкциями и готовыми кнопками: «Как фиксить различные классы проблем в админке». В итоге время фикса некоторых классов проблем сократилось с 2–4 часов до 1 минуты. Причем за 3 месяца по этому алгоритму не удалось исправить только один-единственный (!) баг.

Результаты
Самый главный результат – снизилась нагрузка на саппорт c 9–10 запросов в день до одного.
Как выглядел процесс создания задачи в саппорте ранее: Завести баг в джире, слинковать с джирой заказчика, передать на обработку, подтвердить закрытие, спросить у пользователя, закрыть в джире заказчика.
Как выглядит процесс теперь: Когда пользователь позвонил, сразу ввести номер пациента, нажать готовую кнопку для исправления бага, спросить пользователя о результатах.
➡️Это позволило 99% запросов исправлять за 1 минуту, и это могла делать первая линия саппорта. А после обновлений до последних версий многие баги исчезли. Вместо 12–16 часов на саппорт мы стали тратить всего 2 часа.
Также ежедневно отправляем автоматический отчет по всем задачам саппорта, которые находятся в реализации, в том числе просрочены более чем на 2 дня. Это позволяет понимать, какая задача «подвисла», мотивирует на поиск и устранение причин.

Выводы
1️⃣ Вопросам саппорта незаслуженно уделяют мало внимания, хотя работа с ними может серьезно улучшить процессы.
2️⃣ Добавление процессов и инструкций часто может быть более эффективным, чем введение новой фичи или технологии.
3️⃣ Затратив немного времени на обучение пользователей перед началом использования какой-то программы или оборудования, можно избежать многих проблем.

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

Также приглашаем поделиться впечатлениями, какие посты в Телеграме вам интереснее – короткие или длинные? А может быть, вы предпочитаете читать лонгриды, переходя по ссылке на сайт или Telegraph? Нам интересно и важно узнать ваше мнение 💙