OSD - автоматизация техподдержки десктопного ПО

В мае 2002 года на рынок десктопных продуктов для разработчиков базы данных Oracle вышел коробочный продукт Table Magic российского производства. В течение года его переименовали в DatabaseVoyager и распространяли компакт-дисками по Европе, летали в Америку и Юго-Восточную Азию. Пользователей было не много, общение проводилось посредством электронной почты и ICQ. C увеличением разноязычных пользователей было принято решение о едином языке техподдержки. Отчёты пользователей добавлялись в имевшуюся Bug Tracking System отдельными задачами, с указанием имени юзера и параметров связи с ним (e-mail адрес или номер ICQ в самом тексте задачи). Высокий приоритет таких задач объяснялся именем автора, баги от внутреннего тестирования исправлялись во вторую очередь.
Мировой Интернет развивался и стало возможным оплачивать покупки и распространять ПО без затрат на пересылку, хранить и пересылать большие объёмы данных. Под это дело к 2005 году был создан сайт WWW.SQLDETECTIVE.COM (параллельно в очередной раз переименовали продукт в  SQLDetective) и выбран SWREG как готовый вариант проведения электронных платежей. Количество пользователей начало расти естественным образом. Одного адреса e-mail, указанного в About окне продукта, стало мало.
На сайте появился стандарт – Contact Us, с которого была настроена автопересылка e-mail писем на ящики QA, PM, CEO. Поскольку продукт был достаточного качества, которое было достигнуто 100% занятостью тестировщика пока не расширили обязанности до сотрудника техподдержки, то отдельного сотрудника для ведения техподдержки не нанимали. У одного тестировщика на 4-5 разработчиков хватало продуктовых знаний и способности совмещать весь цикл техподдержки (приём-составление-отправка сообщений, воспроизведение проблем и оценка предложений, оформление задач в BTS).
На сайте также был организован Форум, через который стали поступать отчёты пользователей о багах и предложениях. Нотификации о новых сообщениях в форуме автоматически рассылались на e-mail адреса QA, PM, CEO. Техподдержка всех уровней всё ещё была на плечах одного человека. Конечный вариант ответа утверждался руководством в плане английской грамматики и общей политкорректности. Для сокращения излишней работы шефов было принято решение о составлении шаблонов ответов: структура заголовка и подписи, набор стандартных фраз и ответов на идентичные вопросы.
Исторически сложилось так, что e-mail клиент ящика техподдержки был TheBat. Все письма удалялись с сервера и хранились на одной машине. Использовались полезные свойства клиента: расфасовка писем по папкам, авто-сохранение копии ящика по таймеру, поиск по письмам, блокировка неотвеченных писем для контроля работы техподдержки. Единый ящик копил базу писем пользователей и не засорял сайт (сервер). Ещё один положительный момент TheBat выявился при общении с разноязычными пользователями, когда Outlook стал автоподменять некоторые символы на русско-язычную раскладку (например, двойные кавычки открытие-закрытие, символы больше-меньше в html-формате). Такие символы не отображались или подменялись в ответах пользователям, и смысл текста искажался, что подрывало авторитет компании.
Электронные платежи, увеличенные объёмы серверов, ускорение загрузок сайта позволило распространять инсталлятор десктопного продукта через WEB. Хотя продукт и состоял из ядра и эдонов, но инсталлятор приходилось собирать единым большим файлом. Когда в версию вносились незначительные изменения, то юзеру было накладно качать полный большой инсталлятор. Поэтому апдейты решено было делать отдельными мелкими файлами. Инструкция по установке таких апдейтов была сложная и длинная, поэтому для упрощения жизни конечному пользователю был придуман OSD Updater.
Общение с пользователями через разные средства (direct e-mail, Forum, Contact Us) осложняло работу техподдержки, поэтому был придуман OSD Messenger.
OSD (Online Support Desk) модуль продукта SQLDetective стал выполнять полноценно всю работу техподдержки: переписка с пользователями, распространение апдейтов.
Как обычно конечный пользователь  десктопного продукта общается с разработчиком? Открывает сайт, чаще ещё и логинится, а потом выбирает более удобный вариант: Contact Us, Forum, Download  Updates, Release Notes. Чтоб написать небольшое сообщение без прикреплений обычно используют Contact Us форму. Чтоб сообщить о проблеме или выяснить особенности программы, пишут в Forum. Чтобы скачать обновления или купить продукт, открывают Download и Buy Now, предварительно сверившись по Release Notes об исправленных проблемах и новых возможностях. Все эти неудобства (большое множество путей с неизвестным маршрутом)  устраняются одним модулем в десктопном продукте – OSD.
Преимущества Contact Us есть только для пользователя: не надо регистрироваться на сайте, связь осуществляется быстро, бесплатно, сохраняя конфиденциальность сообщений. Недостатки для пользователя: к таким сообщениям не делают возможности прикрепить файлы (логи, скриншоты), чаще не делают копию сообщения на ящик отправителя, нет подтверждения о получении, недостаточный объём текста можно отправить. У техподдержки тоже в этом случае больше проблем, нежели преимуществ: нет привязки к данным пользователя (тип лицензии, оплаченные сервисы), приоритета и градации сообщения, настроек программы или screenshots.
Преимущества Direct e-mail сообщения для пользователя: не нужна регистрация на сайте, можно любой e-mail использовать, прикреплять картинки, файлы, текст не ограничен размером, бесплатно, индивидуально. Нет гарантии получить конфирмацию, есть опасность пересылки спама и вирусов. Тех.поддержка получает дополнительные файлы с настройками или логами и картинками, но всё также нет привязки к базе зарегистрированных пользователей со списком оплаченных сервисов, тип и важность сообщения определяется самим производителем-фиксатором.
Среди преимуществ Forum для пользователя можно отметить: вопросы и ответы сгруппированы по продуктам и темам, FAQ, модератор отсекает спам, бесплатно. Недостатками являются обязательность регистрации, не всегда есть возможность опубликовать картинки и логи, отсутствие защищенности конфиденциальных данных. Техподдержке такой тип общения помогает определить версию продукта по информации зарегистрированного пользователя, нет необходимости дублировать ответы на одинаковые вопросы. Но также нет полной информации о проблеме ввиду отсутствия конфиденциальности в публикуемых данных.
Зарегистрированный на сайте пользователь может скачать инсталлятор или патч для текущей купленной версии. Но для этого нужно открыть сайт, залогиниться, выбрать нужный файл, как-то его сохранить и выполнить, самостоятельно определив возможность апдейта.
Поняв и оценив все неудобства пользователя компания Conquest создала утилиту для общения конечного пользователя с группой техподдержки и разработчиками. OSD – Online Support Desk.
OSD Messenger, встроенный в десктопный продукт, является фактически e-mail клиентом. На стороне пользователя сообщения сгруппированы по стандартным папкам "Отправленные" и "Принятые", в рамках которых разделены по значимости: General, Suggestion, Support, Other, News. Значимость и приоритет сообщения выбирает сам юзер при создании сообщения, кроме News, присылаемых компанией в одностороннем порядке (своеобразная реклама деятельности компании).
Переписка через OSD хранится в базе, респонденты идентифицируются по ключу лицензии и ПК, с которого ведётся переписка. Пользователи триальных версий тоже имеют уникальные идентификаторы, но переписка не ограничена триальным периодом в отличие от возможности апдейтов. Поэтому у техподдержки и отдела маркетинга всегда есть под рукой информация для анализа. Сообщение содержит следующие параметры: уникальный номер сообщения со сквозной нумерацией входящих и исходящих сообщений; уникальный идентификатор пользователя в зависимости от лицензионного ключа и используемого ПК; идентификатор продукта, название и страна владельца ключа автоматически считываются из лицензии; имя пользователя и e-mail (юзер получит на него нотификацию об отправленном в OSD ответе) вводятся вручную самим юзером при создании первого сообщения и хранятся в настройках приложения на конкретном ПК; тема сообщения вводится вручную для каждого нового сообщения (кроме авто-создаваемых из EurekaLog); тип и приоритет сообщения юзер выбирает из списка для каждого нового сообщения; текст сообщения юзер вводит вручную, для автосформированных из EurekaLog имеется шаблон, для писем с историей предыдущие тексты видны только в режиме просмотра и недоступны для редактирования; пользовательские прикрепления разрешены стандартных типов, кроме исполняемых файлов, размером не более 4Мб как ограничение базы с сообщениями; в числе стандартных прикреплений лог приложения и лог ошибки в формате EurekaLog, скриншот рабочего стола при логировании ошибки с помощью EurekaLog, настройки приложения из реестра и файлов, настройки аудитора кода, параметры операционной системы и клиентов базы Oracle, некоторая инфа о лицензии продукта. Все эти данные позволяют быстро и эффективно, без лишних вопросов юзеру решать описанную проблему сразу на первой линии техподдержки.
Сообщение можно создать в несколько приёмов, для этого имеется папка Drafts. В последних версиях продуктов добавлена возможность создавать черновики сообщений без наличия Интернета, который ранее использовался для присвоения уникального номера сообщению. Теперь он создаётся в момент отправки на сайт.
К сожалению, пока что стандартные прикрепления актуальны на момент просмотра сообщения или на момент отправки.  Параметры системы, настройки приложения и системы могут быть изменены с момента появления ошибки и до момента отправки сообщения, и это может исказить условия проблемы. А также они не сохраняются при сохранении черновика.
Каждое сообщение, отправленное из OSD Messenger, регистрируется в базе и юзеру моментально отправляется ответ с подробностями о принятом сообщении: присвоенный уникальный номер, планируемая дата ответа, объём принятых прикреплений. Тем самым выказывается юзеру уважение о каждом его посте.
При появлении нового сообщения юзера в базе на ящик техподдержки высылается нотификация с важными подробностями, достаточными для рассмотрения проблемы: уникальный номер сообщения; параметры лицензии и юзера для определения доступных возможностей и приоритетов ответа; срок отправки ответа; линки для скачки прикреплений; дубликат заголовков и текста сообщения. Подробности о лицензии (оплаченный сервис техподдержки, срок действия лицензии, купленные эдоны) ранжируют сроки ответа: триальщики и пользователи с оплаченным сервисом должны получить ответ в день получения сообщения, но не позже двух рабочих дней; бета-тестерам ответы можно отправлять на следующий день после получения, но не позже 7 рабочих дней; пользователям с оконченной лицензией и с оплаченной лицензией, но без оплаченного сервиса техподдержки, ответ отправлять спустя 5 дней после получения, но не позже 10 дней. Такие сложности были придуманы как маркетинговый ход для покупки юзерами годового сервиса техподдержки. Подробности об эдонах из лицензии дают понимание о функциональных ограничениях на стороне пользователя.
Наличие нотификаций о сообщениях пользователя исключает утечку персональной инфы за пределы серверов и сети компании. Доступа к корпоративным ящикам и сайту достаточно в локальной сети для поддержания политики безопасности о нераспространении информации. С 2014 года команда разработки активно расширялась, на десяток разработчиков добрали трёх тестировщиков и распределили их по-продуктно. Каждому сотруднику техподдержки помимо личного корпоративного ящика определён был e-mail для ведения техподдержки. Но два ящика на сотрудника принесли только проблемы: команда стала путаться на какой ящик какого характера инфу отправлять; поскольку названия ящиков техподдержки унифицированы (например, tech-support-99), то имена владельцев путались до особого распоряжения об обязательной полной подписи владельца в теле письма и адресной книге.
Половинчато система получения и рассмотрения сообщений реализована на сайте, но поскольку на создание и переделку back-end для внутренних нужд всегда не хватает ресурсов и времени, то e-mail нотификаций вполне достаточно.
С полученной нотификацией техподдержка работает по следующей схеме. Тема нотификации префиксуется коротким именем продукта, а тестировщики распределены по-продуктно. Ответственный тестировщик при получении нотификации проводит расследование: воспроизводит проблему на билде, указанном в сообщении; пытается воспроизвести на последнем опубликованном билде, если он отличается от билда юзера; пытается воспроизвести на текущем разрабатываемом билде; при недостаточности знаний продукта обращается за помощью к продуктовым разработчикам. Любые подозрения об использовании лицензии уточняются с отделом маркетинга путём пересылки текущей нотификации топам с копией PM. Для выяснения таких проблем помогает база всех сообщений в разрезе пользователей. Поскольку сообщения на сайте время от времени архивируются, то удобней пользоваться e-mail клиентом, в котором за год добавляется около тысячи писем, а все прикрепления к письмам скачаны и лежат на быстром жёстком диске. Выявленные проблемы оформляются в BTS. Составляется черновой вариант ответа на английском языке (включаются пересылки прод.лидам в случаях сложных проблем), выделяется в пересылаемой нотификации особыми символами (одинарные фигурные скобки), сразу прописывается имя юзера по особо принятой схеме (первые пять ответов First Name + Last Name, остальные – только First Name), текст форматируется под обычный (форма ответов не располагает опциями html-форматирования, получаемые юзером ответы просматриваются как обычный текст), подпись конкретным именем отвечающего разрешена только для особых давних пользователей. Первый черновик отправляется лингвисту на проверку. Лингвист вносит исправления и добавляет второе выделение фигурными скобками, как признак пройденности вторичной проверки. Проверенный текст перенаправляется PM на утверждение технических и юридических сторон. При благополучном пройдении проверки у PM он разрешает отправку согласно графику (приписывает "OK" в начале пересылаемого письма) и отправляет первоначальному тестировщику, в иных ситуациях (ответ отложить или раньше времени отправить, ответ не соответствует ожиданиям) с соответствующей припиской нотификация возвращается на доделку тестировщику или лингвисту. Одобренный черновик ответа публикует тестировщик в строго отведённое время, чтоб пользователь в разных частях света не был потревожен e-mail нотификацией в его внерабочее время. Если юзер указал e-mail в OSD сообщении, то на него высылается нотификация о наличии ответа. Сам ответ юзер может прочитать только в OSD Messenger. После отправки ответа тестировщику тоже приходит нотификация об отправленном ответе с полным его текстом. Их фильтруют по папкам юзеров в e-mail клиенте.
Для выяснений всех обстоятельств проблемы техподдержке часто приходится беспокоить пользователя дополнительными вопросами. В Conquest было принято правило минимизации количества пересылаемых писем юзеру, которое может показать высокий уровень подготовленности кадров. В помощь для соблюдения этого правила, для сбора статистики отделом маркетинга, для полноты картины проблемы в сообщения OSD добавили авто-прикрепление настроек приложения, параметров системы и логи. Поскольку настройки приложения хранятся в разных местах (реестр, файлы в папках %AppData% и MyDocuments), то пользователю сложно выбрать и найти необходимый объём информации для пересылки в техподдержку. Но пользователь всегда должен иметь возможность просмотреть объём отправляемой информации, так как в ней может оказаться некоторая персональная/корпоративная тайна (пароли, параметры доступа и т.д.). Поэтому в рамках просмотра отправляемого сообщения должна быть возможность исключения настроек приложения и системы из пересылаемого прикрепления. В текущих версиях продуктов можно только увидеть список отправляемых файлов, без возможности просмотра и исправления их содержимого. Реализовать такое не сложно, но Conquest не тратит на это время, потому что каждый раз подписывается обещанием о нераспространении инфы третьим лицам. А отсутствие возможности править отправляемое стандартное прикрепление подрывает доверие пользователя, и во избежание недоразумений юзер совсем исключает стандартные прикрепления. Большая помощь техподдержке и программисту поступает из лога и скриншота EurekaLog. Внешнюю утилиту несложно встроить в десктопное приложение. При сложных багах утилита собирает информацию о приложении и системе (запущенные дополнительно приложения, выполненные команды приложения вплоть до номера строки в конкретном модуле/скрипте), которую можно напрямую отправить по электронной почте или в качестве прикрепления к OSD сообщению. Зачастую такой лог программисту говорит намного больше, чем картинка и описание шагов от юзера. Eureka может и сама составить письмо, но оно получается скупым, без настроек приложения и screenshot-а. А OSD сообщение имеет полноценный заголовок, развёрнутое тело и все прикрепления.
Описанная система техподдержки имеет много недостатков в случае текучки кадров, из-за задержек при работе с почтой, архивы базы сообщений разбросаны по разным машинам, клиент TheBat накладно переносить и распространять на другие машины. К тому же базы OSD, Contact Us и Direct сообщений разрознены. Поэтому была запущена реорганизация работы отдела техподдержки. Первым шагом был перенос архива переписки с пользователями из TheBat в Thunderbird. Процесс растянулся на несколько дней, так как нужно было каждую папку экспортировать отдельно для файлов "msf". В очередной раз пришлось отказаться от Outlook из-за его неудобства экспорта-импорта и последующих проблем излишнего форматирования текстов. В качестве второго шага было принято правило рассылки черновиков с ответами всем членам первого уровня техподдержки для повышения знаний продуктов. Но очень скоро выяснилось, что данное правило спамит сильно и отвлекает тестировщиков от своего продукта. Для исключения недостатков и объединения OSD сообщений с Contact Us в единую базу было предложено отказаться от почтовых пересылок за счёт хранения и обработки всей информации на сайте, но предложение усовершенствовали до более лёгкого в реализации – создавать задачи в Jira автоматически из сообщений пользователей. Если к Jira привлечь топов, то такая система имела бы место жить и эффективно работать. Но Product Manager никак не желал открывать внутреннюю BTS верхнему руководству. Здесь же аукнулась проблема языка межкомандного общения (с топами только по-английски, внутри разработчиков по-русски), которая не всегда позволяет полноценно описать и понять проблему ввиду ограниченности знаний. А пока техподдержка оборудована нотификациями о новых сообщениях, о предстоящем окончании срока отправки ответа, о просроченной отправке ответа.
Для бета-тестеров одно время существовала система публикации вопросов и ответов OSD сообщений, но её прикрыли во избежание обнародования всех продуктовых проблем. Даже в созданных группах соц.сетей модератор запрещает обсуждать какие бы-то ни было продуктовые проблемы и даже предложения.
В Conquest отказались от Forum, так как "OSD Messenger + Contact Us" решают все проблемы в полной мере, на сайте предостаточно описательной инфы продуктов и проводятся вебинары (по запросу).
Вторая немаловажная часть OSD – это Updater. Пользователю десктопного продукта со сложной структурой ядра и плагинов часто сложно определить наличие и доступность апдейтов. Большую проблему обновления десктопных продуктов приносят в ручном режиме. Хотя на сайте и существует блок аккаунта пользователя лицензий, но и в нём бывает сложно определиться – что скачать, куда и как ставить. OSD Updater в десктопном продукте с подключением к интернету выполняет апдейт в автоматическом режиме исходя из данных лицензии и установки: определяется пакет доступных обновлений, скачивается и распаковывается с достаточным количеством перезапусков.
OSD Updater может присылать и применять ключ для апгрейда. Но во всех других случаях (утеря, докупка или прерывание AMS сервиса, увеличение количества лицензий, смена персональных данных) дубликат или новый ключ можно получить только через сайт. Это предложение не запущено в разработку, поскольку ни один из реальных пользователей пока что не запросил подобное.
Для пользователей с очень закрытой системой, то есть без доступа в Интернет, была сделана доработка OSD Updater через файловую систему. В этом случае администратор продукта скачивает апдейт с сайта и выкладывает в общий локальный ресурс, а в приложении выставляется настройка на этот локальный ресурс. Но даже в режиме файловой системы апдейты могут определяться и устанавливаться автоматически при запуске приложения. OSD Updater в desktop приложении работает как и тихие апдейты сегодняшних web-приложений, сайты: стартует с приложением; определяет тип, версию приложения и ключа; определяет место установки конкретной версии; предлагает доступный билд или версию, если оплачен upgrade; проводит переинсталляцию; качает и применяет ключ новой версии (и в многопользовательской версии для нескольких филиалов). Юзеру остаётся только откинуться на кресле и подождать пару минут, не забыв кликать по кнопкам Next и OK.
Для заканчивающихся ключей и AMS (Annual Maintenance Support) придумали нотификатор в трее. Он может работать без Интернета, имеет настройку от спама.
В 2009 году линейка продуктов пополнилась ClearSQL и ClearDB Documenter. Для них OSD было вынесено в самостоятельную библиотеку и внедрено в оба продукта. В 2016 году появился бесплатный docuVIEWER, который тоже планируют пополнить модулем OSD.