Введение

К организации технической поддержки проекта необходимо подойти грамотно. С одной стороны недостаточно просто завести электронный ящик, на который клиенты будут присылать свои вопросы, а вы будете на них отвечать. С другой стороны нельзя сильно углубляться в аспекты ITIL/ITSM, которые могут быть применимы для очень крупных центров технической поддержки, а в случае обычных проектов процесс организации техподдержки будет очень затяжным (в худшем случае, техподдержка так и не будет налажена). Самое главное - это понять зачем нужна служба техподдержки и в том, как она будет организована. В этом заинтересованы все стороны: клиент, заказчик и исполнитель-разработчик.

  ТП с точки зрения клиента

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

  ТП с точки зрения исполнителя

С точки зрения разработчика необходимо:

• Определиться с перечнем решаемых вопросов, которые вы будете обрабатывать от клиента через исполнителя/заказчика.

  Это могут быть консультации по функционалу или по back-end разработанного решения, по работе с административной частью. Вопросы могут быть как по технической части как самого решения, так и связанные с инфраструктурой (и относится к тому, кто эту инфраструктуру поддерживает). Также это могут быть срочные вопросы, связанные с аудитом производительности и безопасности, или обработка каких-то аварийных ситуаций. Все это стоит зафиксировать, рассмотреть вместе этот круг вопросов и по возможности стараться за него не выходить.

• Определить зоны ответственности - кто, собственно, за что отвечает (особенно, если у вас в процессе участвует больше, чем 2 стороны).

  Это могут быть: зоны ответственности по инфраструктуре, по резервным копиям, по тестовой среде, по среде разработки. Если вы размещаете инфраструктуру не на своих ресурсах, то всегда определяйте кто отвечает за код сайта, за само приложение, за его контент.

• Разработать процедуру обращения: кто может обращаться в техподдержку и какими способами.

  Например, в компании-заказчике работает 100 тыс. человек и, если к вам, как к разработчику, будет обращаться каждый из этих человек, то техподдержку оказывать будет очень тяжело. От компании должны быть представлены контактные лица, которые будут с вами работать. Также зафиксируйте интерфейсы для обращения (телефон, электронная почта, тикетная система) и выделите наиболее приоритетный и удобный с обеих сторон способ.

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

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

  Внутренняя организация техподдержки

Все входящие обращения в техподдержку обязательно должны быть зафиксированы:

• В случае использования тикетной системы все просто: каждому обращению присваивается свой номер.
• Если же обращения поступают по электронной почте, то старайтесь генерировать тикет, чтобы был номер обращения, и желательно, чтобы клиент получал автоответ о принятии его обращения.
• В случае обращения клиента по телефону в техподдержку также следует создавать тикет (многие автоматизированные системы позволяют по телефонному звонку создавать тикет).

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

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

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

Немаловажным аспектом работы службы техподдержки является внутренняя система мотиваций. Оценивать работу сотрудников можно по совокупности или по отдельным критериям, например:

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

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

Что же касается технической стороны вопроса, то сейчас очень много тикетных систем, помогающих организовать службу техподдержки. В Bitrix Framework имеется собственный инструмент - модуль Техподдержка, который включает в себя публичный интерфейс для создания обращений, удобную работу с тикетами и их историей и много других возможностей (подробное описание смотрите в главе Техподдержка курса Администратор. Модули).