Максим Кулагин, руководитель технической поддержки C3D Labs, делится секретами предоставления эффективной технической поддержки и объясняет, как правильно создавать запросы.

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

Давайте рассмотрим, какой путь преодолевает запрос пользователя.

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

Итак, информация получена, проблема воспроизводится, что дальше?

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

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

Рассмотрим технические аспекты получения запросов от пользователей. Непосредственно техническая поддержка осуществляется с помощью системы ServiceDesk. Эта система является общей для группы компаний АСКОН и хорошо знакома пользователям продуктов компании.

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

После того как пользователь зашел в систему, он получает возможность создавать запросы. Задать вопрос по бесплатному программному обеспечению, к примеру по C3D Viewer, который доступен для скачивания на сайте www.c3dlabs.ru, может любой пользователь, зарегистрировавшийся в ServiceDesk, задав в качестве сервиса «Бесплатное ПО» или «Ознакомительные версии». У пользователей, находящихся на коммерческой технической поддержке C3D Labs, подключен специализированный сервис C3D.

Рассмотрим создание запроса в системе ServiceDesk по пунктам.

Для создания нового запроса необходимо выбрать «Новый запрос» в меню сайта.

При создании нового запроса следует выбрать сервис «C3D», далее продукт, а именно «Ядро C3D», который устанавливается по умолчанию при выборе этого сервиса.

Следующий пункт — версия. В настоящий момент текущей версией является 2023, в дальнейшем цифра, разумеется, будет меняться.

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

Далее необходимо выбрать тип запроса. Тут все просто, выберите то, что вам подходит. Злоупотреблять типом «блокирующая ошибка» не рекомендуется, выбирайте этот тип, только если действительно дальнейшая работа из-за этой ошибки невозможна, к примеру из-за вылета приложения.

Следующая важная вещь, которую обязательно стоит указать, — это версия компонента, с которой вы работаете и на которой возникла описываемая ситуация. Эту информацию можно указать в поле «Доп. информация о продукте». Если не указать ее, может возникнуть ситуация, когда пользователь сообщает о проблеме, относящейся к устаревшей версии и уже исправленной в более новых выпусках. Не зная реальной версии, на которой возникает проблема, сотрудник технической поддержки попытается ее воспроизвести на текущей, и если это не получится, то он столкнется с дилеммой: не воспроизводится, потому что отличается окружение, система или что-то еще, или не воспроизводится, потому что проблема уже была решена? В любом случае придется запрашивать дополнительные данные для подтверждения одного из вариантов, а если указать версию, то ответ будет получен практически сразу.

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

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

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

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

Особое значение имеют файлы, которые пользователи прилагают к запросу. Файлы служат для того, чтобы служба технической поддержки смогла воспроизвести ситуацию, разобраться в проблеме и дать ответ или передать данные разработчикам. Очень сложно воспроизводить запрос по текстовому описанию. Предположим, пользователь пишет: «Я вызываю некую функцию, и приложение «падает». Что получается в итоге? Чтобы воспроизвести ситуацию, сотрудник отдела техподдержки пишет эту функцию по описанию, однако часто случается, что приложение не «падает» для созданного варианта. Причиной тому может служить, например, какой-то из параметров, который при вызове функции был задан немного по-другому. Исходный код совместно с описанием может дать значительно больше информации, чем каждый из них по отдельности. Поэтому части исходного кода и файлы моделей для воспроизведения являются очень ценными для ускорения воспроизведения и, в конечном итоге, решения проблемы.

Какие же файлы исходного кода нужно прикладывать к запросу? Тут есть варианты.

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

• Использовать одно из тестовых приложений, поставляемых с модулями C3D, для воссоздания проблемной ситуации и передачи измененных файлов этих приложений. В данном случае воспроизведение будет выполнено гораздо быстрее, так как необходимо только заменить файлы в примере на присланные и запустить его для воспроизведения ситуации. Кроме того, в коде тестовых приложений уже содержатся типовые сервисные команды, такие как загрузка файлов или добавление геометрии в окно визуализации.

Рассмотрим для примера тестовое приложение, поставляемое с геометрическим ядром C3D Modeler. В приложении имеется меню, позволяющее загружать и сохранять геометрию, а также выполнять функции, поставляемые геометрическим ядром. В файле test_user.cpp имеются заготовки функций, вызываемых из меню Помощь → Создание новых команд → Пользовательская команда.

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

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

MbModel & model = TestVariables::viewManager->GetActiveWindow()->SetGeomModel();

Следующий код позволяет удалить/добавить трехмерный объект в модель с обновлением отображения в окне:

TestVariables::viewManager→DeleteObject( initialSolid );
TestVariables::viewManager->AddObject( TestVariables::SOLID_Style, resultSolid );

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

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

Если речь идет о вопросе, касающемся модуля C3D Vision, то ситуация следующая: вместе с C3D Vision поставляется большое количество примеров, на данный момент более сорока. Каждый пример демонстрирует ту или иную функциональность, показывает, как с ней работать, и на базе этих же примеров можно воспроизвести ситуацию пользователя. Это оптимальный вариант, потому что достаточно прислать в отдел технической поддержки измененный исходный код примера для воспроизведения. То же самое касается оболочки C Sharp для Vision — NetC3DToolkit.

Для воспроизведения ситуаций, возникающих при работе с C3D Solver, к запросу можно приложить журнал, полученный с помощью вызова следующей функции:

• Для 2D-версии C3D Solver:

  bool GCE_SetJournal( GCE_system gSys, const char * fName );

• Для 3D-версии C3D Solver:

  bool GCM_SetJournal( GCM_system gSys, const char * fName );

В журнал записываются все данные, передаваемые в систему C3D Solver, благодаря чему можно воспроизвести ситуацию.

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

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

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

Максим Кулагин

Руководитель отдела технической поддержки
C3D Labs