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

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

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

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

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

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

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

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

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

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

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

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

Работа над процессами отдела — непрерывный процесс. На данный момент в отделе выделены следующие процессы:

• Работа с обращениями

• Ввод/найм нового сотрудника

• Вывод/увольнение сотрудника из отдела

• Принятие проекта на обслуживание через аудит

• Новый клиент

• Завершение работ с клиентом

При классической иерархии отдела, когда менеджер принимает задачи от клиентов и далее ставит их программистам, именно менеджер будет являться узким горлышком. Впрочем с этим вполне можно жить, если вы «Сибирикс» и отбираете проекты на поддержку по многим критериям, но если у вас упор на массовость, то на каждые 3-4 программиста необходимо будет нанимать менеджера увеличивая издержки, что недопустимо.

Необходимо выстроить структуру, когда на всех программистов будет всего один менеджер.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развивая личный кабинет клиента вы постепенно убираете эффект черного ящика, когда он поместил в задачу в некую коробку и через какое-то непонятное время ему дали результат.

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

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

На данным момент в нашей системе можно посмотреть следующие метрики по клиентам: