Эффективный отдел техподдержки сайтов

Согласно последним исследованиям наблюдается тенденция сжимания рынка заказной разработки сайтов. Согласно данным CMS Magazine общий объем рынка в 2016 году составил 16,4 млрд. рублей. В 2012 году было немного больше — 17,7 млрд. рублей, при этом среднегодовой курс доллара вырос более чем в два раза.

Веб-студиям необходимо перестраиваться. Одним из таких направлений может стать техподдержка уже существующих проектов. Многие возразят, что техподдержка есть у всех. Если иметь в виду страницу на сайте в разделе «Услуги», то скорее всего да, но настоящая техподдержка с правильно выстроенными процессами есть у совсем небольшой части рынка. Под техподдержкой я понимаю сопровождение кода сайта после его запуска.

1. Отдельная команда

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

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

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

2. Принципы и ценности команды

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

Взаимозаменяемость программистов, никакой привязки к проекту

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

Использование канбан-доски и проведение ежедневных митингов

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

Канбан-доска для отдела техподдержки сайтов

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

Борьба с потерями времени на повторяющихся операциях через базу знаний

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

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

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

Еженедельная ретроспектива

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

3. Структура отдела

Структура отдела техподдержки сайтов

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

Менеджер полностью заведует всеми сотрудниками отдела и знает всех клиентов техподдержки, все их особенности и странности. Основная задача менеджера распределять задачи между программистами, помогать им общаться с клиентами и следить за соблюдением регламентов.

Тим-лид является наставником разработчиков. Помогает им в выполнении задач, делает точные оценки для клиентов, развивает инструментарий отдела и делает некоторые задачи для поддержания формы.

Все остальные сотрудники из структуры работают согласно своим должностным обязанностям. Больше всего у вас будет программистов. Исходя из практики на 4-5 программистов нужен один QA-специалист и один HTML-верстальщик. Каких-то ролей может и не быть.

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


4. Документы и регламенты

У читателя может возникнуть вопрос, как сделать так, чтобы это все заработало и без вашего участия, как руководителя компании? Тут на помощь приходит система документов и регламентов.

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

  • Регламент рабочего дня
  • Определяет когда сотруднику приходить на работу, во сколько обед, сколько коммерческих часов он должен наработать в течении дня и т.п. Он как правило общий по всей компании, а не только для техподдержки.

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

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

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

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

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

5. Отдельный сайт техподдержки

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

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

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

6. Аналитика клиентской базы

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

7. Преимущества

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

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

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

8. Недостатки

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

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

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

На данном сайте собираются метаданные пользователя (cookie, данные об IP-адресе и местоположении) для функционирования сайта. Если Вы не хотите чтобы эти данные обрабатывались, то должны покинуть сайт

Заявка
на сотрудничество

Как вас зовут? Заполните это поле
Адрес электронной почты Неверный формат почты
Телефон для связи Заполните это поле
Нажимая на кнопку «Отправить заявку»,
я даю согласие на обработку персональных данных