Блог Okdesk
Все о Help Desk (Service Desk) – отзывы, обзоры, экспертные мнения
Новости19 дек. 2016

Развитие системы службы поддержки Okdesk: долгосрочная стратегия или пожелания клиентов? (часть 2)

Мы развиваем облачную систему службы поддержки Okdesk. Наши принципы работы — не “впаривать”, а решать реальные проблемы среднего и малого бизнеса в части сервисного обслуживания. Именно поэтому мы уделяем пристальное внимание развитию возможностей продукта.

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

В этой части мы расскажем о реальных клиентских требованиях, о их системном решеним и о том, как устроен процесс разработки нашей help desk системы.

Система службы поддержки Пожелания клиентов. Реальные истории. Системные решения.

Перейдем от теории к практике и реальной жизни. В Okdesk имеется панель (dashboard) с оперативной информацией о работе службы поддержки:

Служба поддержки. Оценка качества

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

Оказалось, что бизнес-процесс компании реализован так, что у заявок есть статусы. В этих статусах, например, ожидается ответ от автора обращения, или ожидается поставка запчастей. Запросы, которые "висят" в таких статусах долгий период, считаются системой просроченными (и, соответственно, подсчитываются на одной из плиток). Клиент предложил реализовать настройку параметров фильтрации для плитки. Фактически он хотел исключить заявки в “замороженных” статусах из подсчета. Подойдя к вопросу системно, и "подключив" к рассмотрению другие кейсы и требования, мы нашли иное решение — реализовать в настройках бизнес-процессов параметр “Учитывать время” для статуса. Таким образом, клиент сможет настроить “заморозку” счетчика времени, и отложенные заявки не будут считаться просроченными.

При реализации пользовательского требования “как есть”, мы бы совершенно точно потратили уйму времени на разработку (в первую очередь — на разработку удобного интерфейсного решения). Однако, перейдя на уровень сценариев использования, нашлось более простое и понятное решение, которым смогут пользоваться и другие для решения схожих и иных задач.

Подытоживая, хочется отметить, что обратная связь от пользователя ожидает обратной связи от вас :). Если пользователь сформулировал требование или пожелание к системе — важно дать ответ о планах разработки. А когда (и если) ожидаемая функция будет реализована, необходимо проинформировать автора требования об этом. Обеспечение обратной связи по пользовательским требованиям пересекается с процессами службы технической поддержки. Именно поэтому логично собирать пожелания пользователей и давать им обратную связь в системе службы поддержки.

Так, для поддержки пользователей Okdesk мы используем Okdesk :). Основные каналы поступления обращений:

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

Система службы поддержки. Как улучшать отношения с клиентами?

Когда готов новый релиз (в среднем это происходит раз в 3-5 недель), мы проверяем все тикеты в указанном состоянии, и если какая-то часть из них полностью или частично решается новой функциональностью — сообщаем радостную новость пользователям. Пользователи довольны и ощущают нашу заботу :)

Бесплатное тестирование системы службы поддержки!

Система службы поддержки, как инструмент управления требованиями. Процесс разработки Okdesk

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

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

Перед разработкой кода наши аналитики пишут постановки (спецификации или ТЗ). Все требования разбиваются по крупным функциональным модулям и внутри модулей сгруппированы в смысловые блоки. Например, есть крупный блок “01. Модуль учета заявок”. В нем — ряд смысловых блоков “01.01. Карточка заявки”, “01.02. Комментарии к заявкам”, “01.03. Список заявок” и так далее. Отдельно фиксируются изменения в требованиях по каждому релизу. Для каждого требования описываются кейсы, варианты решения и, при необходимости, причины выбора одного из вариантов. Для всех — ведем (и актуализируем при изменениях) список Test-кейсов. Дорогих специализированных инструментов нет — на текущий момент достаточно Google Docs.

По итогам зафиксированного и проанализированного требования, начинаем разработку. Все задачи попадают под процедуру Code Review (один из основателей проекта отвечает за технологическую часть). Далее новая функция "выкатывается" на тестовый сервер для поверхностного визуального тестирования — в нашем случае осуществляет человек, разработавший требование. При наличии замечаний — отправляем на устранение, если замечаний нет — задача уходит на более глубокое ручное тестирование. По итогам устранения всех замечаний новая функциональность покрывается автотестами в соответствии с написанными Test-кейсами.

Когда все задачи текущего релиза готовы — проводим еще одно ручное тестирование версии, где собраны все новые функции. Нет замечаний — скрещиваем пальцы (шутка :)) и выкатываем новые функции.

Система службы поддержки как инструмент управления требованиями

Релизы нашей системы службы поддержки мы выпускаем регулярно, в среднем каждые 3-5 недель. В каждый релиз включается одна большая функция или новый модуль, а также ряд улучшений сделанного ранее. Случается, что некоторые большие функциональные блоки не умещаются в один релиз — например, в конце 2016-го года мы выпустили мобильное приложение для работы с заявками “полевых” сотрудников. На его разработку ушло около 3 месяцев.

Наши "помощники" : Google Docs для документов и управления требованиями, Redmine для управления разработкой, GitHub для кода, Slack для коммуникаций, Okdesk для технической поддержки и работы с обратной связью от клиентов.

Вместо постскриптума

"Строительство" ИТ-продукта — сложный и долгий путь. К сожалению, на этом пути велик соблазн свернуть в сторону реализации заглушек под нецелевые требования конкретных клиентов. На выходе получается кусочный продукт со множеством ненужных, неудобных функций. С одной стороны это ужасно, а с другой — клиенты с таким "монстров" мигрируют в том числе на наш продукт.
А если Вы ищите удобную систему службы поддержки, которая, к тому же, может стать инструментом управления требованиями - попробуйте Okdesk. Доступ к бесплатному тестированию можно получить по ссылке ниже.



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

 
Время Uptime за последние
12 месяцев – 99,97
17 тыс
Количество клиентов, которых
поддерживают с помощью Okdesk
 
Активное развитие. Новый
релиз каждые 3-5 недель