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

Лучшее
Опубликовано: 19.12.2016
Обновлено: 05.12.2022
Время на чтение: ~7 мин.

Мы развиваем облачную систему службы поддержки 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 — это бесплатно
Простая и быстрая автоматизация задач по сервисному обслуживанию и технической поддержке ваших заказчиков. Внедрение без программистов. Бесплатный доступ ко всем возможностям на 14 дней.
Попробовать бесплатно

Поделитесь статьей
Кирилл Федулов
Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания
Популярные материалы
Опыт клиентов
Зачем мигрировать с корпоративной service desk на Okdesk — Опыт «Совтех»
14.09.2022
От экспертов
Help desk система: что это и зачем она нужна вашей компании?
21.11.2022
Лучшее
10 признаков того, что вашей компании нужна новая help desk система
21.11.2022
От экспертов
Как help desk система поможет сделать сервисный бизнес прибыльнее и эффективнее?
29.12.2022
Лучшее
Отличия service desk и CRM: совмещаем две системы в одну
28.09.2022
Руководство: «55+ бесплатных сервисов для развития бизнеса»
Рекомендуем почитать
От экспертов
Что такое Facility Management

Facility management (FM) — это профессиональное управление обслуживанием недвижимых активов. В зависимости от назначения объекта в сегменте facility management выделяют управление коммерческими и жилыми зданиями. Также может отличаться сфера ответственности управления — компании, функционирующие на данном рынке в зависимости от ответственности и полномочий могут управлять объектом целиком (управляющие компании) или обслуживать отдельные элементы инфраструктуры объектов (facility-операторы). И в первом, и во втором случае отношения собственника с оператором или управляющей компанией регулируются договором оказания услуг.

От экспертов
Service Desk. Как правильно выбрать систему автоматизации поддержки?

Рынок service desk систем предлагает десятки различных вариантов: от простых тикет решений до сложных корпоративных и очень дорогих. Существуют предложения для Customer Support, для внутренней поддержки (ITSM). Какая именно service desk система нужна сервисной компании, и на что в первую очередь обратить внимание при выборе? Давайте разбираться!

От экспертов
Мобильные сотрудники и Field Servic: как управлять, планировать работы и загрузку

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

От экспертов
ТРМ или всеобщий уход за оборудованием

TPM (Total Productive Maintenance, всеобщий уход за оборудованием) — это подход к обслуживанию производственного оборудования, направленный на постоянное поддержание его работоспособного состояния. В этой статье обсудим, почему этот подход важен именно сейчас и как внедрить его в компании.

От экспертов
Что такое Field Service Management и зачем это сервисным компаниям

Field service management (FSM) — это подходы и практики управления выездным обслуживанием, когда техники и инженеры выполняют работы на территории заказчика. Таким образом обслуживаются инженерные сети, всевозможные датчики (в том числе IoT), коммерческая недвижимость, вендинговые автоматы, банкоматы и т.п.

Прочее
Техническое обслуживание и ремонт вентиляционных систем

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

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