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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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