Мы развиваем облачную систему службы поддержки 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 систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания
