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

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

Итак, для этого рецепта нам понадобятся:

• хранилище пользовательских данных (наверняка есть у каждой большой компании: сервер, куда складываются логи и данные о клиентских компьютерах);
• парсер вышеупомянутых пользовательских данных (тоже наверняка имеется: кто же откажется от лишней статистики по операционным системам, конфигурациям, моделям и версиям);
• парочка программистов: один со стороны продукта и еще один со стороны отдела внутренней разработки (главный по хранилищу и парсерам);
• аналитик (приятно познакомиться).

Пункт первый: реестр сообщений.
Участники: продуктовый программист, аналитик.

В любом программном продукте наверняка есть минимум три типа сообщений, выводимых для пользователя: ошибки, предупреждения и информационные сообщения. Назовем их APP_ERR, APP_WARN и APP_INFO.

Внимание: сообщения с вопросами вроде «Действительно ли вы хотите отформатировать диск С? Да/Нет» в этом рецепте не участвуют!

В коде и логах эти сообщения могут быть организованы либо при помощи цифровых кодов (APP_ERR_1 и далее), либо при помощи имен (APP_ERR_KABOOM), либо при помощи комбинаций того и другого. В принципе, способ организации для нашей затеи неважен. Выгружаем все сообщения, которые видит пользователь, в файл и скармливаем аналитику, который в содружестве с продуктовым программистом добавляет к каждому из них комментарии: когда, кому и зачем это сообщение может показываться и какие механизмы в этом задействованы. Например: APP_ERR_KABOOM – показывается компонентом таким-то в случае, если он вот-вот взорвется. Возможные причины: 1) кончилось место на диске, 2) кончились права на запись на диск, 3) что-то недоброе с самим диском. Создается этот реестр для того, чтобы не дергать продуктового программиста лишний раз в процессе последующей работы с сообщениями. Дальше сообщения можно сортировать по компонентам или любым другим любезным вам признакам.

Пункт второй: розыскные мероприятия.
Участники: оба программиста, аналитик.

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

Пункт третий: выемка и осмысление результатов парсинга.
Участники: программист отдела внутренней разработки, аналитик.

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

Пункт четвертый: выводы.
Участники: аналитик.

Ошибки. Зачем, спрашивается, таким странным и сложным способом анализировать сообщения об ошибках, если пользователь сам побежит с ошибкой в техподдержку? И тут-то я достану из кармана свой любимый пример о таймаутах. Таймауты есть у каждого, и время ожидания зачастую задается из сложных соображений, не вполне сообразующихся с реальностью пользователя – скажем, на глаз. Отсюда распространеннейший тип проблем: время от времени какой-то тяжелый процесс грустно сообщает о таймауте. Но не всегда, а в зависимости от загрузки компьютера или сети. Воспроизведение у пользователя отнюдь не стопроцентное, повторение операции зачастую проходит удачно, а техподдержка далеко, и как ты объяснишь, что происходит, если сообщение машинально закрыл, например. Посему, если таймаут не выскакивает каждый или хотя бы каждый второй раз, мы можем не узнать об этом довольно долго. При этом, не блокируя работу полностью, эти сообщения создают крайне негативное впечатление от программы. То же касается и многих других ситуаций с непостоянным воспроизведением.

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

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

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