изображение создано нейросетью
Российские заказчики сегодня хотят, чтобы отечественный софт развивался как можно быстрее, работал с минимальным количеством проблем, ошибки быстро устранялись. Отечественные вендоры ищут баланс между скоростью разработки и качеством тестирования. В этой ситуации служба поддержки начинает играть ключевую роль для репутации разработчика и его продукта. Как избежать ошибок при построении линий поддержки разбирался IT World.
Линий поддержки обычно бывает три или четыре. В случае с корпоративными коммуникационными платформами второй вариант наиболее эффективен.
Первая линия – сотрудники колл-центра, которые принимают заявки. Особенность их задачи – они общаются с конечными пользователями, в том числе неподготовленными в части ИТ. На первой линии расскажут, где находится та или иная кнопка в приложении, научат создавать звонок и планировать конференцию, искать по тегам сообщения. Все эти базовые вещи относятся к стандартным возможностям приложения «из коробки». Кстати, первой линией чаще всего вступает клиентская служба поддержки в структуре организации-заказчика.
Специалисты второй линии обрабатывают обращения от первой линии или клиентской службы поддержки. Часто такие вопросы относятся к особенностям инсталляции продукта у конкретного заказчика. Если ошибка кроется в клиентской части, на второй линии помогут ее устранить. Также вторая линия агрегирует сообщения об ошибках в приложении, проводит их анализ и передает задачи, связанные с серверной частью или кодом, на третью или четвертую линии.
Если проблема относится к серверной части приложения или к реализации системы в рамках ИТ-ландшафта заказчика, к ее решению подключаются специалисты третьей линии. Эти инженеры глубоко разбираются в нюансах функционирования системы. Например, они знают, какие компоненты ИТ-ландшафта, внешние по отношению к системе, могут влиять на ее работу.
Когда проблемы упираются в некорректное поведение системы как таковой или указывают на необходимость внести исправления в код приложения, задачу передают на четвертую линию – команде разработки. Для устранения проблемы разработчики в соответствии с уровнем критичности в максимально короткие сроки реализуют багфикс.
Содержание:
Зачем нужно разграничивать полномочия
Не всегда можно четко провести границу между полномочиями каждой из линий поддержки. Корпоративные коммуникационные приложения, например, – это сложный продукт, он очень плотно встраивается в ИТ-ландшафт заказчика, и на этапе анализа проблемы часто возникает «серая зона», где специалисты смежных линий работают совместно. Скажем, нужно точно выяснить, в коде или особенностях ИТ-инфраструктуры заказчика кроется ошибка. Командная работа инженеров и разработчиков будет здесь необходима.
Но есть типовые ошибки в распределении зон ответственности, которые снижают качество поддержки.
Специалисты одной линии начинают давать советы своим коллегам на другой линии. В равной степени неуместно как первой линии судить о настройке сервера, так и третьей – учить колл-центр отвечать на базовые вопросы.
На первой линии задействованы специалисты четвертой линии. То есть, разработчиков пытаются вовлечь в решение абсолютно всех заявок. Это приводит к тому, что разработчики теряют фокус на создании продукта, загрузка непрофильной деятельностью их демотивирует.
Одни и те же специалисты ведут все линии. В принципе, если компания небольшая, это возможно. Но, скорее всего, даже маленькой компании придется часть функций поддержки передать на аутсорсинг или вести в облачных сервисах.
Все компетенции поддержки сосредоточены в одном человеке. Да, бывает и такое, но это почти всегда ведет к потере качества обслуживания системы. Профессионалу, который специализируется на сложных системах, неинтересно заниматься, скажем, задачами десктоп-поддержки. С большой вероятностью он захочет развивать свои компетенции в другой компании. Более устойчивым на такой позиции будет базовый специалист, набирающий опыт работы с функционированием сервисов. Но также очень рискованно брать на эту позицию специалиста недостаточно высокого уровня.
Кто и как руководит поддержкой
У всех четырех линий поддержки может быть единый руководитель или несколько руководителей. Главное – строго придерживаться единого подхода к предоставлению услуги. Заключив специализированный контракт по техподдержке, заказчик вправе рассчитывать на единый формат реагирования в рамках единого бизнес-окна. Руководство такой поддержки должно обладать общим пониманием правил и принципов предоставляемой услуги, общими инструментами для фиксации обращений и работы над ними.
Что касается компетенций, руководителю поддержки наверняка потребуются навыки в части ITIL и ITSM. Он должен знать, как строятся процессы, связанные с реагированием на инциденты, понимать зоны ответственности каждой из линий, уметь наладить коммуникацию между специалистами всех линий.
Объединить все линии в единый слаженный механизм помогают:
Простые и понятные, единые для всех линий поддержки правила работы.
Единые коммуникационные инструменты для взаимодействия на всех уровнях.
Регулярные встречи и общие вебинары между представителями смежных линий и не только. Специфика рынка российского ПО на текущий момент заключается в том, что развитие продукта, разработка его новой функциональности идет семимильными шагами. Чем крупнее продукт, тем более длинный у него жизненный цикл и тем сложнее вносить изменения. Все это требует диалога между командами разработки, внедрения и техподдержки – для того, чтобы всем оставаться в едином информационном поле.
На что заказчику обратить внимание, выбирая службу поддержки
Сарафанное радио – один из каналов получения информации о присутствующих на рынке компаниях. Когда заказчики приходят к разработчику коммуникационного решения, они, как правило, уже многое знают про вендора, к которому обратились.
У каждого вендора есть общедоступные телефоны поддержки на сайте или формы обращения. «Тайный покупатель» в любой момент может оценить скорость и качество ответа. Это не даст полную картину относительно функционирования всех четырех линий поддержки, но первая из них себя точно проявит.
Большой плюс – наличие у вендора качественного интернет-ресурса с документацией по взаимодействию с продуктом, функционированию продукта, диагностике возникающих проблем. Это дает возможность пользователям самостоятельно и быстро находить базовые ответы на свои вопросы.
Но только на этапе пилотного тестирования заказчик может всесторонне оценить скорость реакции поддержки и решения возникающих проблем. Положительная тенденция заключается в том, что пилоты при внедрении коммуникационных решений становятся нормой.
Особенности поддержки отечественного софта
Все российские компании-разработчики живут под прессингом требований со стороны заказчиков, которые хотят, чтобы отечественные решения не уступали продуктам мировых гигантов. Это заставляет наших разработчиков бежать в темпе догоняющего – то есть, быстрее лидеров, и у нас это неплохо получается. Однако более высокий темп разработки порождает большее количество потенциальных ошибок: чем быстрее идут изменения, тем меньше времени остается на тестирование. К тому же зарубежные вендоры работают на большой территории, и о проблеме, найденной на одном континенте, на другом могут никогда и не узнать. Российский рынок относительно небольшой, каждая выявленная ошибка здесь заметна.
Быстрый бег на узком рынке приводит к особенностям технической поддержки. Допустим, поддержка получила сообщение об ошибке – с точки зрения заказчика, весьма критичной. Если проблема уже известна разработчикам и ее исправление запланировано в следующей версии, но заказчику надо сейчас – специальная версия под этого заказчика может появиться за считанные часы. Глобальные разработчики так быстро изменения не вносят. С другой стороны, если ситуация не критична, внесение изменений может затянуться, потому что в приоритете всегда критические задачи разработки, а их немало. Читайте также
Ореn API как ведущий тренд развития финтеха. Аналитика IT-World В 2026 году ЦБ РФ обяжет все крупные российские банки, страховые компании и брокеров использовать Открытые интерфейсы прикладного программирования. С 2027 года такая обязанность ляжет на МФО, депозитарии, финансовые платформы и операторов по выпуску ЦФА. Зачем ЦБ РФ переводит игроков финансового рынка на Open API и что будет дальше, разбирался IT-World.
В целом, поскольку экосистемы отечественных продуктов активно развиваются, скорость и качество реакции на запросы заказчиков становятся крайне важны. Поэтому у любого ответственного российского вендора развитие службы поддержки сейчас – в списке приоритетных задач.
Игорь Малышевдиректор по сервисам eXpress