Четыре линии поддержки. Как успеть за темпами отечественной разработки

Логотип компании
Четыре линии поддержки. Как успеть за темпами отечественной разработки
изображение создано нейросетью
Российские заказчики сегодня хотят, чтобы отечественный софт развивался как можно быстрее, работал с минимальным количеством проблем, ошибки быстро устранялись. Отечественные вендоры ищут баланс между скоростью разработки и качеством тестирования. В этой ситуации служба поддержки начинает играть ключевую роль для репутации разработчика и его продукта. Как избежать ошибок при построении линий поддержки разбирался  IT World.

Линий поддержки обычно бывает три или четыре. В случае с корпоративными коммуникационными платформами второй вариант наиболее эффективен.

Первая линия – сотрудники колл-центра, которые принимают заявки. Особенность их задачи – они общаются с конечными пользователями, в том числе неподготовленными в части ИТ. На первой линии расскажут, где находится та или иная кнопка в приложении, научат создавать звонок и планировать конференцию, искать по тегам сообщения. Все эти базовые вещи относятся к стандартным возможностям приложения «из коробки». Кстати, первой линией чаще всего вступает клиентская служба поддержки в структуре организации-заказчика.

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

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

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

Зачем нужно разграничивать полномочия

Не всегда можно четко провести границу между полномочиями каждой из линий поддержки. Корпоративные коммуникационные приложения, например, – это сложный продукт, он очень плотно встраивается в ИТ-ландшафт заказчика, и на этапе анализа проблемы часто возникает «серая зона», где специалисты смежных линий работают совместно. Скажем, нужно точно выяснить, в коде или особенностях ИТ-инфраструктуры заказчика кроется ошибка. Командная работа инженеров и разработчиков будет здесь необходима.

Но есть типовые ошибки в распределении зон ответственности, которые снижают качество поддержки.

  • Специалисты одной линии начинают давать советы своим коллегам на другой линии. В равной степени неуместно как первой линии судить о настройке сервера, так и третьей – учить колл-центр отвечать на базовые вопросы.

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

  • Одни и те же специалисты ведут все линии. В принципе, если компания небольшая, это возможно. Но, скорее всего, даже маленькой компании придется часть функций поддержки передать на аутсорсинг или вести в облачных сервисах.

  • Все компетенции поддержки сосредоточены в одном человеке. Да, бывает и такое, но это почти всегда ведет к потере качества обслуживания системы. Профессионалу, который специализируется на сложных системах, неинтересно заниматься, скажем, задачами десктоп-поддержки. С большой вероятностью он захочет развивать свои компетенции в другой компании. Более устойчивым на такой позиции будет базовый специалист, набирающий опыт работы с функционированием сервисов. Но также очень рискованно брать на эту позицию специалиста недостаточно высокого уровня.

Кто и как руководит поддержкой

У всех четырех линий поддержки может быть единый руководитель или несколько руководителей. Главное – строго придерживаться единого подхода к предоставлению услуги. Заключив специализированный контракт по техподдержке, заказчик вправе рассчитывать на единый формат реагирования в рамках единого бизнес-окна. Руководство такой поддержки должно обладать общим пониманием правил и принципов предоставляемой услуги, общими инструментами для фиксации обращений и работы над ними.

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

Объединить все линии в единый слаженный механизм помогают:

  • Простые и понятные, единые для всех линий поддержки правила работы.

  • Единые коммуникационные инструменты для взаимодействия на всех уровнях.

  • Регулярные встречи и общие вебинары между представителями смежных линий и не только. Специфика рынка российского ПО на текущий момент заключается в том, что развитие продукта, разработка его новой функциональности идет семимильными шагами. Чем крупнее продукт, тем более длинный у него жизненный цикл и тем сложнее вносить изменения. Все это требует диалога между командами разработки, внедрения и техподдержки – для того, чтобы всем оставаться в едином информационном поле.

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

Сарафанное радио – один из каналов получения информации о присутствующих на рынке компаниях. Когда заказчики приходят к разработчику коммуникационного решения, они, как правило, уже многое знают про вендора, к которому обратились.

Google сломала квантовую физику: теория дала сбой на новом чипе Sycamore
S3-хранилище против классического СХД: что выбрать для современного бизнеса?
Вышло глобальное обновление системы централизованного управления РЕД АДМ Промышленная редакция 2.0

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

Большой плюс – наличие у вендора качественного интернет-ресурса с документацией по взаимодействию с продуктом, функционированию продукта, диагностике возникающих проблем. Это дает возможность пользователям самостоятельно и быстро находить базовые ответы на свои вопросы.

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

Особенности поддержки отечественного софта

Все российские компании-разработчики живут под прессингом требований со стороны заказчиков, которые хотят, чтобы отечественные решения не уступали продуктам мировых гигантов. Это заставляет наших разработчиков бежать в темпе догоняющего – то есть, быстрее лидеров, и у нас это неплохо получается. Однако более высокий темп разработки порождает большее количество потенциальных ошибок: чем быстрее идут изменения, тем меньше времени остается на тестирование. К тому же зарубежные вендоры работают на большой территории, и о проблеме, найденной на одном континенте, на другом могут никогда и не узнать. Российский рынок относительно небольшой, каждая выявленная ошибка здесь заметна.

Быстрый бег на узком рынке приводит к особенностям технической поддержки. Допустим, поддержка получила сообщение об ошибке – с точки зрения заказчика, весьма критичной. Если проблема уже известна разработчикам и ее исправление запланировано в следующей версии, но заказчику надо сейчас – специальная версия под этого заказчика может появиться за считанные часы. Глобальные разработчики так быстро изменения не вносят. С другой стороны, если ситуация не критична, внесение изменений может затянуться, потому что в приоритете всегда критические задачи разработки, а их немало.

Читайте также
Цифровые двойники в строительстве. Эффективность, проблемы и перспективы
Цифровой двойник — это виртуальная точная копия объекта, например, автомобиля или здания, или процесса, например, производства того или иного продукта. Согласно исследованию НИУ ВШЭ, почти 22% компаний из 15 секторов экономики уже используют эту технологию, а 34% — планируют внедрить ее в работу. О том, как подобные двойники помогают строительной отрасли, IT-World рассказал Кирилл Поляков, основатель цифровой платформы для управления стройкой Pragmacore (малая технологическая компания Сколково).

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

Опубликовано 28.02.2025

Об авторах
Игорь Малышев
Игорь Малышев
директор по сервисам eXpress
техподдержка
Похожие статьи
Кто поддерживает дешевле и надежнее: собственная ИТ-команда или внешний подрядчик?
Кто поддерживает дешевле и надежнее: собственная ИТ-команда или внешний подрядчик?
Как выбрать правильный период оценки и корректно учесть все расходы, не забывая даже неочевидные? Какие параметры нужно реально учитывать при принятии решения? Кому точно не стоит собирать команду инхаус? Разбирался IT-World.
Павел КрасавцевИТ в бизнесе, 05.03.25
Разграничение зон ответственности между первой, второй и третьей линией поддержки
Разграничение зон ответственности между первой, второй и третьей линией поддержки
«Алло техподдержка? У меня Интернет не работает». Если вам это знакомо, значит вы либо сами звонили в поддержку, либо работали там. В идеале техническая поддержка должна подразделяться на три уровня, но в реальности все куда хаотичнее и многограннее. Иногда вообще кажется, что это просто один большой чат, где все друг на друга перекидывают задачи. IT-World разбирался, кто за что отвечает на каждом уровне.
Иван ДегтяревИТ в бизнесе, 03.03.25
В каких случаях лучше держать поддержку внутри компании, а когда стоит передавать подрядчикам?
В каких случаях лучше держать поддержку внутри компании, а когда стоит передавать подрядчикам?
Бывали ли у вас ситуации, когда приходилось «висеть» на трубке, ожидая по 10-15 минут перевода на ближайшего освобождающегося оператора?
Евгений КарасевИТ в бизнесе, 27.02.25