Очень часто технической поддержкой программных продуктов обязывают заниматься тестировщиков. Но и как самостоятельный объект тестирования ТП вполне должна занимать определённое место в тест-плане.
Долгие годы мне приходилось осуществлять ТП продуктов, совмещая с тестированием и постановкой задач. Хоть это порой и сложная задача, но весьма полезная во всех отношениях. Общее качество продукта складывается и из качества (оперативность, экспертиза, внимание к каждому пользователю) его поддержки, как одного из завершающих этапов.
Скомпоновать потребности технической поддержки мне захотелось не только для того, чтобы тестировщики могли упростить свой процесс тестирования этой грани продукта, но и в качестве идеи для тех StartUp-ов, которые хотят и могут создать универсальные утилиты для встраивания их в любые продукты. Личным опытом стоит делиться, но он субъективен. Поэтому, собрав воедино некоторые аспекты ТП, хочу доставить свои знания не только тем, кто о них не задумывался, но также и тем, кто желает усовершенствовать поддержку своего продукта. Наличие каждого артефакта разделено по типу продукта с уровнем потребности:
Вполне допускаю, что какие-то из сторон дела упущены. Моя благодарность уже летит к тем, кто поможет дополнить и расширить список:
Вполне возможно, что некоторые пункты не раскрывают сути в таблице, поэтому постараюсь дополнить их пояснениями.
1. Обмен сообщениями с ТП одно из основных предназначений ТП, как элемент общения производителя с потребителем.
1.1. e-mail письма наиболее популярный вид современного общения с хорошей конфиденциальностью пересылаемых данных.
1.1.1. внешний клиент доступен пользователям любых типов продуктов, но сложен для производителя в плане учёта сообщений (конвертация в BTS, группирование по юзерам или типам обращений). Также в их редакторах иногда возникают проблемы с кодировкой языка и локализацией времени. Но из готовых клиентов стоит присмотреться к их функционалу: фильтрация сообщений, планирование событий, шаблонизация ответных текстов, форматирование текстов, размещение и хранение прикреплений и другие полезности.
1.1.2. встроенный клиент требует серверного пространства на сайте производителя, внутренних ресурсов команды (знания, время). Нет возможности встроить в некоторые типы продуктов. Но такая система самая гибкая.
Огромную часть оформления можно переложить на пользователя и авто-сборщик:
- дата-время создания сообщения должна конвертироваться в единый формат и региональный пояс;
- уникальный номер входящего сообщения автоматически может формироваться в системе приёма (ID юзера + timestamp получения поддержкой) или отправки (ID юзера + timestamp создания пользователем);
- параметры кастомера (территория, дилер, корпорация кастомеров, и т.д.) для группирования аналитических данных;
- категория (жалоба, благодарность, предложение, запрос на покупку или дополнения, и т.д.) может выбираться из оговоренного списка;
- уровень (критичное, важное, мелочёвка) может выбираться из оговоренного списка;
- краткий заголовок задачи автоматически попадает из Subject письма в Summary поле BTS;
- содержимое письма Body автоматически разделяется на текст для Description и прикрепления в BTS:
- распарсивание логов и настроек для последующего бизнес-анализа;
- расчёт конечной даты ответа автоматически производится по типу лицензии и критериям сообщения;
- автоматически в ТП формируются напоминания о неотвеченных сообщениях;
- обратная совместимость BTS с отправщиком писем;
- авто-ответ с отметкой о регистрации входящего сообщения (обязательная или настраиваемая отправка).
Любой бизнес-аналитик подтвердит, что по данным, полученным через встроенный сервис, можно сделать множество реальных прогнозов (или даже финансовых планов). Активность пользователей легко поддерживать массовой рассылкой новостей.
1.1.3. учёт обращений легко и быстро автоматизируется при наличии встроенного клиента. Внешние клиенты писем пока не разрешают совместное использование, поэтому учёт ограничен одним сотрудником ТП, а не распространяется на тестировщиков и владельцев продукта.
1.2. форум-сообщество и BTS на сайте производителя как часть системы встроенного клиента e-mail писем, но может нарушаться конфиденциальность публикуемых данных.
1.2.1. вход через интерфейс ПО возможно осуществить при наличии определённого интерфейса (главное меню, единый футер web-страниц, и другое) в продукте и доступа в Интернет с машины пользователя.
1.2.2. единый ID пользователя на портале производителя и в форуме пользователей, экспертов.
1.2.3. закрытость/открытость самого сервиса влияет на доверие пользователя при публикации внутренних данных. Но открытые форумы или их часть могут способствовать рекламе продукта.
1.2.4. самописные (ресурсы, цена, поддержка) порталы гибкие в настройке и управлении, но могут быть дороги в обслуживании.
1.2.5. учёт обращений всегда возможен в автоматическом режиме, но ограничен общедоступными параметрами сообщений.
1.3. группа в общественных сетях, облачная BTS как любое готовое решение не всегда имеет необходимый набор возможностей. В большинстве случаев требуется постоянная оплата сервисов.
1.3.1. открытая исключает конфиденциальность, обилие жалоб и неотвеченных сообщений снижает рейтинг производителя, но вполне может быть бесплатным рекламным субъектом.
1.3.2. закрытая группа нуждается в модераторе (подключение участников, контроль конфиденциальности), малополезна в качестве рекламного щита.
1.3.3. линк с сайта производителя ПО или из интерфейса продукта будет не только полезным, но и удобным путём обращения пользователя в ТП.
1.3.4. QR-код, линк в документации пользователя необходим в современном мире для ускорения общения. Некоторые сотрудники ТП даже считают его наличие хорошим тоном.
1.3.5. оплата внешних сервисов может быть завышена или абсолютно отсутствовать. Этот критерий весьма важен при выборе между самописным и внешним сервисом.
1.3.6. привязка к внутреннему учёту обращений уже существует в некоторых утилитах. Как пример, между Slack и Jira имеется экспорт, либо можно дописать на Python.
1.4. интернет-канал телефонных сетей весьма важен для современных пользователей.
1.4.1. с дубляжем на сайте сети канал расширяет восможности продукта, связывая интерфейс ПО с возможностью быстрого общения.
1.4.2. общие группы телефонных сетей аналогичны закрытым группам соц.сетей по многим параметрам.
1.4.3. индивидуальные звонки являются наилучшими каналами для передачи конфиденциальных данных.
1.4.4. видео-звонок расширяет возможность общения, но не приемлем для продуктов, установленных на том же самом устройстве, если не поддерживает расшаривание экрана.
1.4.5. учёт обращений требует дополнительных сервисов, которых пока нет на рынке.
1.5. голосовой звонок чаще выбирают пользователи-экстраверты. У сотрудника ТП, кроме экспертизы технической, должны быть на высоте навыки общения, знания иностранных языков, готовность к сменной и круглосуточной работе.
1.5.1. авто-набор телефонного номера имеется почти во всех интернет-браузерах, но вполне возможен и будет полезен в десктопных интерфейсах (About окно, главное меню) или хелпах.
1.5.2. многоканальный сервис позволяет иметь множество пользователей, но требует не только технической возможности, но и достаточного числа сотрудников.
1.5.3. запись разговоров важна как для обработки обращения, так и для последующего учёта.
1.5.4. учёт звонков требует дополнительных сервисов, которых пока мало на рынке.
1.6. прикрепления к сообщению при баге ПО очень нужны программистам и ТП для актуализации, вполне помогут бизнес-аналитикам составлять прогнозы на востребованность будущих новшеств. Самописные утилиты для отправки сообщений в ТП должны автоматически формировать полный комплект.
1.6.1. скриншот считают первоочередным источником для конкретизации источника проблемы.
1.6.2. логи бывают разные - от открытия приложения до бага, от запуска ОС до добавления в список задач текущего ПО, автоматически собираемые системой или специально формируемые продуктом. Их важность велика не только для исправления бага, но может содержать полезную информацию для бизнес-анализа. Критичным моментом стоит считать соблюдение законов о конфиденциальности данных.
1.6.3. макрос шагов, видео с экрана весьма удобные вещи, но случается, что утилиты для передачи сообщений в ТП ограничивают типы вложений по объёму или неопознанному содержимому.
1.6.4. настройки ПО, ОС, РС (железо) иногда помогают выяснить причины бага, весьма полезны своим набором данных для анализов и прогнозов бизнеса. Особое внимание стоит уделять конфиденциальности и прозрачности.
1.7. письменно на бумажном носителе обратиться в ТП могут те, кому нужны неоспоримые артефакты в юридическом смысле.
1.8. личное обращение без средств связи чаще используют юзеры ближнего круга (альфа- и бета-тестеры, владелец продукта, и т.д.)
1.9. авто-сообщение при баге считаю наиболее удобным способом передачи данных в ТП.
1.9.1. нотификация и подтверждение отправления должно происходить только с согласия пользователя ПО. Также хорошей практикой считаю уведомление отправителя о получении его сообщения службой ТП.
1.9.2. редактирование текста сообщения в ТП - весьма полезно, если у юзера есть возможность более подробно описать предшествующие багу шаги.
1.9.3. контроль, редактирование прикреплений обязательны для спокойствия пользователя, поскольку конфиденциальные данные могут быть зашифрованы так, что нарушат закон о невмешательстве в персональные действия.
1.9.4. отложенная отправка сообщеня бывает удобна в случае временного отсутствия связи с ТП.
1.9.5. дубляж на e-mail отправителя или сохранение отправленного контента весьма важно для учёта на стороне пользователя. Это поможет ему не спамить ваш отдел ТП повторными однообразными багами.
2. Обновление ПО вторая обязанность ТП. За качество (вовремя, требуемая версия за оговоренную плату) поставки новых версий ПО ответственны сотрудники ТП.
2.1. самостоятельно обновить ПО юзеру должно быть позволительно при любом раскладе работы ТП.
2.1.1. контроль оплаты является важным моментом бизнеса, аналогичен присказке "вечером деньги, утром стулья". Сам юзер в момент приобретения обновдения должен видеть прозрачно процесс движения денежных средств и объём поставки.
2.1.2. версионность вверх и вниз должна не только контролироваться инсталлятором, но и поддерживаться деинсталлятором.
2.1.3. совместимость ПО и ОС, версий ПО и плагинов должна быть собрана тестировщиками и разработчиками в процессе исследования ПО, а итоги этих анализов должны информировать пользователя в открытых источниках (ReadMe, Release Notes, ...).
2.1.4. инсталляция и настройка должны являться прозрачными процессами, чтобы юзер сам мог контролировать версионность и совместимость.
2.1.5. получение апдейта (нашёл-скачал, линк в спам-письме) необходимо максимально упрощать, чтобы избегать проблемы несовместимости системы и ПО, своевременно подстёгивать пользователя к приобретению новых версий.
2.1.6. апдейт из первых рук или от посредника может сильно разниться, поэтому владелец продукта обязан контролировать дилеров не только в плане получения прибыли, но и вовремя актуализировать версии.
2.2. автоматически получать и запускать апдейт - это наилучший способ удовлетворять клиентов.
2.2.1. период для сканирования обновлений должен быть напрямую связан с длиной спринта группы разработки. В качестве отрицательного примера могу процитировать маркетолога ConquestSS, который рекомендует юзерам сканировать наличие апдейтов ежедневно, тогда как версии ПО выпускаются весьма нерегулярно (раз в квартал или три года).
2.2.2. видимый/скрытый режимы проверки и установки должны выбираться и переключаться для продуктов, умеющих работать в непрерывном режиме. Но лучшей практикой считаю вариант скрытого поиска обновления и запуск инсталлятора только после юзерского одобрения.
3. Обучение пользователей, внедрение, бета-тестирование некоторые считают прерогативой отдела аналитиков, но на мой взгляд отдел ТП для того и формируется, чтобы пользователи работали в продукте так, как это запрограммировано разработчиками.
3.1. вебинары, лекции, курсы можно проводить и удалённо, и на стороне пользователя. Конференции и семинары на нейтральной стороне весьма способствуют привлечению новых юзеров. Сотрудник ТП является лучшим презентатором ПО, потому что знает внутренности продукта, легко догадывается о требованиях пользователя, обладает высоким уровнем навыков общения.
3.2. встроенный в ПО хелп (текст, картинки, видео) является нейтральным способом передачи знаний от разработчиков пользователям. Содержимое этих документов формируется на понятном юзеру языке, не спамится рекламой. Не даром повсеместно она вызывается по первой горячей клавише и зовётся "помощью".
3.3. обучающий режим ПО весьма полезен тем, кто ленится читать инструкцию пользователя.
4. Оплата сервисов - дело двустороннее. Производитель ПО может единожды вложиться в сторонние сервисы, но при этом со своих пользователей взымать плату за предоставление ТП.
4.1. бесплатный/триальный период обычно предоставляется в рекламных целях. Соглашусь с ТП, что он должен быть минимальным, поскольку это прямое недополучение ими платы за оказываемые услуги.
4.2. периодичный сервис (годовая оплата All-included) можно назвать "окладным" способом оплаты работы ТП. За предоплаченный период у юзера может и не случиться проблем, разработчики не опубликуют новую версию, но пользователь уже отдал деньги за "будущие" услуги.
4.3. по критериям (общение бесплатно, апдейт за деньги) сервис можно назвать "сдельным", то есть ТП получает свою долю за конкретно предоставленные услуги.
4.4. внешний сервис оплаты или встроенный "кошелёк" выбирает владелец продукта для сокрытия или прозрачности денежных потоков, проверенные сервисы для сохранности операций. ТП может подсказывать маркетологам направления развития, контролируя объёмы общения с пользователем.
Огромная просьба к тем, чья экспертиза в ТП больше моей, дополните или исправьте вышеописанный набор знаний.
Долгие годы мне приходилось осуществлять ТП продуктов, совмещая с тестированием и постановкой задач. Хоть это порой и сложная задача, но весьма полезная во всех отношениях. Общее качество продукта складывается и из качества (оперативность, экспертиза, внимание к каждому пользователю) его поддержки, как одного из завершающих этапов.
Скомпоновать потребности технической поддержки мне захотелось не только для того, чтобы тестировщики могли упростить свой процесс тестирования этой грани продукта, но и в качестве идеи для тех StartUp-ов, которые хотят и могут создать универсальные утилиты для встраивания их в любые продукты. Личным опытом стоит делиться, но он субъективен. Поэтому, собрав воедино некоторые аспекты ТП, хочу доставить свои знания не только тем, кто о них не задумывался, но также и тем, кто желает усовершенствовать поддержку своего продукта. Наличие каждого артефакта разделено по типу продукта с уровнем потребности:
| обязательно |
| желательно, можно, опционально |
| ненужное, лишнее |
| Desktop без доступа в Интернет | Desktop с выходом в Интернет | WEB | Mobile | IoT | IoT + PC/mobile menu | |||
|---|---|---|---|---|---|---|---|---|
| 1. Обмен сообщениями с ТП | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.1. e-mail | ++ | ++ | ++ | ? | ? | ? | ||
| 1.1.1. внешний клиент | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.1.2. встроенный клиент | __ | ++ | ? | ? | __ | ? | ||
| 1.1.3. учёт обращений | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.2. форум-сообщество и BTS на сайте производителя | ? | ? | ? | ? | ? | ? | ||
| 1.2.1. вход через интерфейс ПО | __ | ++ | ++ | ++ | __ | ++ | ||
| 1.2.2. единый ID пользователя | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.2.3. закрытость/открытость | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.2.4. самописные (ресурсы, цена, поддержка) | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.2.5. учёт обращений | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.3. группа в общественных сетях, облачная BTS | ? | ? | ? | ? | ? | ? | ||
| 1.3.1. открытая | ? | ? | ? | ? | ? | ? | ||
| 1.3.2. закрытая | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.3.3. линк с сайта производителя ПО | ? | ? | ? | ? | ? | ? | ||
| 1.3.4. QR-код, линк в документации пользователя | __ | ++ | ++ | ++ | ? | ++ | ||
| 1.3.5. оплата внешних сервисов | ? | ? | ? | ? | ? | ? | ||
| 1.3.6. привязка к внутреннему учёту обращений | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.4. интернет-канал телефонных сетей | ? | ? | ? | ? | ? | ? | ||
| 1.4.1. с дубляжем на сайте сети | ? | ? | ? | ? | ? | ? | ||
| 1.4.2. общие группы | __ | ? | ? | ? | ? | ? | ||
| 1.4.3. индивидуальные звонки | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.4.4. видео-звонок | ? | ? | ? | ? | ? | ? | ||
| 1.4.5. учёт обращений | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.5. голосовой звонок | ? | ? | ? | ? | ? | ? | ||
| 1.5.1. авто-набор телефонного номера | __ | ++ | ++ | ++ | __ | ++ | ||
| 1.5.2. многоканальный сервис | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.5.3. запись разговоров | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.5.4. учёт звонков | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.6. прикрепления к сообщению при баге ПО | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 1.6.1. скриншот | ? | ? | ? | ? | ? | ? | ||
| 1.6.2. логи | ? | ? | ? | ? | ? | ? | ||
| 1.6.3. макрос шагов, видео с экрана | ? | ? | ? | ? | ? | ? | ||
| 1.6.4. настройки ПО, ОС, РС (железо) | ? | ? | ? | ? | ? | ? | ||
| 1.7. письменно на бумажном носителе | ++ | ? | ? | ? | ++ | ? | ||
| 1.8. личное обращение без средств связи | ++ | ? | ? | ? | ++ | ? | ||
| 1.9. авто-сообщение при баге | ++ | ++ | ++ | ? | ++ | |||
| 1.9.1. нотификация и подтверждение отправления | ++ | ++ | ++ | ++ | ? | ++ | ||
| 1.9.2. редактирование текста | ? | ? | ? | ? | __ | ? | ||
| 1.9.3. контроль, редактирование прикреплений | ++ | ++ | ++ | ++ | ? | ++ | ||
| 1.9.4. отложенная отправка | ++ | ? | ? | ? | ? | ? | ||
| 1.9.5. дубляж на e-mail отправителя | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 2. Обновление ПО | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 2.1. самостоятельно | ++ | ? | __ | ? | ++ | ? | ||
| 2.1.1. контроль оплаты | ++ | ? | __ | ? | ? | ? | ||
| 2.1.2. версионность вверх и вниз | ++ | ++ | __ | ++ | ++ | ++ | ||
| 2.1.3. совместимость ПО и ОС, версий ПО и плагинов | ++ | ++ | __ | ++ | ++ | ++ | ||
| 2.1.4. инсталляция и настройка | ++ | ++ | __ | ++ | ++ | ++ | ||
| 2.1.5. получение апдейта (нашёл-скачал, линк в спам-письме) | ++ | ++ | __ | ? | ? | ? | ||
| 2.1.6. апдейт из первых рук или от посредника | ? | ? | __ | ? | ? | ? | ||
| 2.2. автоматически | __ | ++ | ++ | ? | ? | ++ | ||
| 2.2.1. период для сканирования обновлений | __ | ++ | ++ | ? | ? | ++ | ||
| 2.2.2. видимый/скрытый режимы проверки и установки | __ | ++ | ++ | ? | ? | ++ | ||
| 3. Обучение пользователей, внедрение, бета-тестирование | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 3.1. вебинары, лекции, курсы | ? | ? | ++ | ? | ++ | ? | ||
| 3.2. встроенный в ПО хелп (текст, картинки, видео) | ++ | ++ | ? | ? | __ | ++ | ||
| 3.3. обучающий режим ПО | ++ | ++ | ? | ++ | ? | ? | ||
| 4. Оплата | ? | ? | ? | ? | ? | ? | ||
| 4.1. бесплатный/триальный период | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 4.2. периодичный сервис (годовая оплата All-included) | ++ | ++ | ++ | ++ | ++ | ++ | ||
| 4.3. по критериям (общение бесплатно, апдейт за деньги) | ? | ? | ? | ? | ? | ? | ||
| 4.4. внешний сервис оплаты или встроенный "кошелёк" | ? | ? | ? | ? | ? | ? | ||
1. Обмен сообщениями с ТП одно из основных предназначений ТП, как элемент общения производителя с потребителем.
1.1. e-mail письма наиболее популярный вид современного общения с хорошей конфиденциальностью пересылаемых данных.
1.1.1. внешний клиент доступен пользователям любых типов продуктов, но сложен для производителя в плане учёта сообщений (конвертация в BTS, группирование по юзерам или типам обращений). Также в их редакторах иногда возникают проблемы с кодировкой языка и локализацией времени. Но из готовых клиентов стоит присмотреться к их функционалу: фильтрация сообщений, планирование событий, шаблонизация ответных текстов, форматирование текстов, размещение и хранение прикреплений и другие полезности.
1.1.2. встроенный клиент требует серверного пространства на сайте производителя, внутренних ресурсов команды (знания, время). Нет возможности встроить в некоторые типы продуктов. Но такая система самая гибкая.
Огромную часть оформления можно переложить на пользователя и авто-сборщик:
- дата-время создания сообщения должна конвертироваться в единый формат и региональный пояс;
- уникальный номер входящего сообщения автоматически может формироваться в системе приёма (ID юзера + timestamp получения поддержкой) или отправки (ID юзера + timestamp создания пользователем);
- параметры кастомера (территория, дилер, корпорация кастомеров, и т.д.) для группирования аналитических данных;
- категория (жалоба, благодарность, предложение, запрос на покупку или дополнения, и т.д.) может выбираться из оговоренного списка;
- уровень (критичное, важное, мелочёвка) может выбираться из оговоренного списка;
- краткий заголовок задачи автоматически попадает из Subject письма в Summary поле BTS;
- содержимое письма Body автоматически разделяется на текст для Description и прикрепления в BTS:
- распарсивание логов и настроек для последующего бизнес-анализа;
- расчёт конечной даты ответа автоматически производится по типу лицензии и критериям сообщения;
- автоматически в ТП формируются напоминания о неотвеченных сообщениях;
- обратная совместимость BTS с отправщиком писем;
- авто-ответ с отметкой о регистрации входящего сообщения (обязательная или настраиваемая отправка).
Любой бизнес-аналитик подтвердит, что по данным, полученным через встроенный сервис, можно сделать множество реальных прогнозов (или даже финансовых планов). Активность пользователей легко поддерживать массовой рассылкой новостей.
1.1.3. учёт обращений легко и быстро автоматизируется при наличии встроенного клиента. Внешние клиенты писем пока не разрешают совместное использование, поэтому учёт ограничен одним сотрудником ТП, а не распространяется на тестировщиков и владельцев продукта.
1.2. форум-сообщество и BTS на сайте производителя как часть системы встроенного клиента e-mail писем, но может нарушаться конфиденциальность публикуемых данных.
1.2.1. вход через интерфейс ПО возможно осуществить при наличии определённого интерфейса (главное меню, единый футер web-страниц, и другое) в продукте и доступа в Интернет с машины пользователя.
1.2.2. единый ID пользователя на портале производителя и в форуме пользователей, экспертов.
1.2.3. закрытость/открытость самого сервиса влияет на доверие пользователя при публикации внутренних данных. Но открытые форумы или их часть могут способствовать рекламе продукта.
1.2.4. самописные (ресурсы, цена, поддержка) порталы гибкие в настройке и управлении, но могут быть дороги в обслуживании.
1.2.5. учёт обращений всегда возможен в автоматическом режиме, но ограничен общедоступными параметрами сообщений.
1.3. группа в общественных сетях, облачная BTS как любое готовое решение не всегда имеет необходимый набор возможностей. В большинстве случаев требуется постоянная оплата сервисов.
1.3.1. открытая исключает конфиденциальность, обилие жалоб и неотвеченных сообщений снижает рейтинг производителя, но вполне может быть бесплатным рекламным субъектом.
1.3.2. закрытая группа нуждается в модераторе (подключение участников, контроль конфиденциальности), малополезна в качестве рекламного щита.
1.3.3. линк с сайта производителя ПО или из интерфейса продукта будет не только полезным, но и удобным путём обращения пользователя в ТП.
1.3.4. QR-код, линк в документации пользователя необходим в современном мире для ускорения общения. Некоторые сотрудники ТП даже считают его наличие хорошим тоном.
1.3.5. оплата внешних сервисов может быть завышена или абсолютно отсутствовать. Этот критерий весьма важен при выборе между самописным и внешним сервисом.
1.3.6. привязка к внутреннему учёту обращений уже существует в некоторых утилитах. Как пример, между Slack и Jira имеется экспорт, либо можно дописать на Python.
1.4. интернет-канал телефонных сетей весьма важен для современных пользователей.
1.4.1. с дубляжем на сайте сети канал расширяет восможности продукта, связывая интерфейс ПО с возможностью быстрого общения.
1.4.2. общие группы телефонных сетей аналогичны закрытым группам соц.сетей по многим параметрам.
1.4.3. индивидуальные звонки являются наилучшими каналами для передачи конфиденциальных данных.
1.4.4. видео-звонок расширяет возможность общения, но не приемлем для продуктов, установленных на том же самом устройстве, если не поддерживает расшаривание экрана.
1.4.5. учёт обращений требует дополнительных сервисов, которых пока нет на рынке.
1.5. голосовой звонок чаще выбирают пользователи-экстраверты. У сотрудника ТП, кроме экспертизы технической, должны быть на высоте навыки общения, знания иностранных языков, готовность к сменной и круглосуточной работе.
1.5.1. авто-набор телефонного номера имеется почти во всех интернет-браузерах, но вполне возможен и будет полезен в десктопных интерфейсах (About окно, главное меню) или хелпах.
1.5.2. многоканальный сервис позволяет иметь множество пользователей, но требует не только технической возможности, но и достаточного числа сотрудников.
1.5.3. запись разговоров важна как для обработки обращения, так и для последующего учёта.
1.5.4. учёт звонков требует дополнительных сервисов, которых пока мало на рынке.
1.6. прикрепления к сообщению при баге ПО очень нужны программистам и ТП для актуализации, вполне помогут бизнес-аналитикам составлять прогнозы на востребованность будущих новшеств. Самописные утилиты для отправки сообщений в ТП должны автоматически формировать полный комплект.
1.6.1. скриншот считают первоочередным источником для конкретизации источника проблемы.
1.6.2. логи бывают разные - от открытия приложения до бага, от запуска ОС до добавления в список задач текущего ПО, автоматически собираемые системой или специально формируемые продуктом. Их важность велика не только для исправления бага, но может содержать полезную информацию для бизнес-анализа. Критичным моментом стоит считать соблюдение законов о конфиденциальности данных.
1.6.3. макрос шагов, видео с экрана весьма удобные вещи, но случается, что утилиты для передачи сообщений в ТП ограничивают типы вложений по объёму или неопознанному содержимому.
1.6.4. настройки ПО, ОС, РС (железо) иногда помогают выяснить причины бага, весьма полезны своим набором данных для анализов и прогнозов бизнеса. Особое внимание стоит уделять конфиденциальности и прозрачности.
1.7. письменно на бумажном носителе обратиться в ТП могут те, кому нужны неоспоримые артефакты в юридическом смысле.
1.8. личное обращение без средств связи чаще используют юзеры ближнего круга (альфа- и бета-тестеры, владелец продукта, и т.д.)
1.9. авто-сообщение при баге считаю наиболее удобным способом передачи данных в ТП.
1.9.1. нотификация и подтверждение отправления должно происходить только с согласия пользователя ПО. Также хорошей практикой считаю уведомление отправителя о получении его сообщения службой ТП.
1.9.2. редактирование текста сообщения в ТП - весьма полезно, если у юзера есть возможность более подробно описать предшествующие багу шаги.
1.9.3. контроль, редактирование прикреплений обязательны для спокойствия пользователя, поскольку конфиденциальные данные могут быть зашифрованы так, что нарушат закон о невмешательстве в персональные действия.
1.9.4. отложенная отправка сообщеня бывает удобна в случае временного отсутствия связи с ТП.
1.9.5. дубляж на e-mail отправителя или сохранение отправленного контента весьма важно для учёта на стороне пользователя. Это поможет ему не спамить ваш отдел ТП повторными однообразными багами.
2. Обновление ПО вторая обязанность ТП. За качество (вовремя, требуемая версия за оговоренную плату) поставки новых версий ПО ответственны сотрудники ТП.
2.1. самостоятельно обновить ПО юзеру должно быть позволительно при любом раскладе работы ТП.
2.1.1. контроль оплаты является важным моментом бизнеса, аналогичен присказке "вечером деньги, утром стулья". Сам юзер в момент приобретения обновдения должен видеть прозрачно процесс движения денежных средств и объём поставки.
2.1.2. версионность вверх и вниз должна не только контролироваться инсталлятором, но и поддерживаться деинсталлятором.
2.1.3. совместимость ПО и ОС, версий ПО и плагинов должна быть собрана тестировщиками и разработчиками в процессе исследования ПО, а итоги этих анализов должны информировать пользователя в открытых источниках (ReadMe, Release Notes, ...).
2.1.4. инсталляция и настройка должны являться прозрачными процессами, чтобы юзер сам мог контролировать версионность и совместимость.
2.1.5. получение апдейта (нашёл-скачал, линк в спам-письме) необходимо максимально упрощать, чтобы избегать проблемы несовместимости системы и ПО, своевременно подстёгивать пользователя к приобретению новых версий.
2.1.6. апдейт из первых рук или от посредника может сильно разниться, поэтому владелец продукта обязан контролировать дилеров не только в плане получения прибыли, но и вовремя актуализировать версии.
2.2. автоматически получать и запускать апдейт - это наилучший способ удовлетворять клиентов.
2.2.1. период для сканирования обновлений должен быть напрямую связан с длиной спринта группы разработки. В качестве отрицательного примера могу процитировать маркетолога ConquestSS, который рекомендует юзерам сканировать наличие апдейтов ежедневно, тогда как версии ПО выпускаются весьма нерегулярно (раз в квартал или три года).
2.2.2. видимый/скрытый режимы проверки и установки должны выбираться и переключаться для продуктов, умеющих работать в непрерывном режиме. Но лучшей практикой считаю вариант скрытого поиска обновления и запуск инсталлятора только после юзерского одобрения.
3. Обучение пользователей, внедрение, бета-тестирование некоторые считают прерогативой отдела аналитиков, но на мой взгляд отдел ТП для того и формируется, чтобы пользователи работали в продукте так, как это запрограммировано разработчиками.
3.1. вебинары, лекции, курсы можно проводить и удалённо, и на стороне пользователя. Конференции и семинары на нейтральной стороне весьма способствуют привлечению новых юзеров. Сотрудник ТП является лучшим презентатором ПО, потому что знает внутренности продукта, легко догадывается о требованиях пользователя, обладает высоким уровнем навыков общения.
3.2. встроенный в ПО хелп (текст, картинки, видео) является нейтральным способом передачи знаний от разработчиков пользователям. Содержимое этих документов формируется на понятном юзеру языке, не спамится рекламой. Не даром повсеместно она вызывается по первой горячей клавише и зовётся "помощью".
3.3. обучающий режим ПО весьма полезен тем, кто ленится читать инструкцию пользователя.
4. Оплата сервисов - дело двустороннее. Производитель ПО может единожды вложиться в сторонние сервисы, но при этом со своих пользователей взымать плату за предоставление ТП.
4.1. бесплатный/триальный период обычно предоставляется в рекламных целях. Соглашусь с ТП, что он должен быть минимальным, поскольку это прямое недополучение ими платы за оказываемые услуги.
4.2. периодичный сервис (годовая оплата All-included) можно назвать "окладным" способом оплаты работы ТП. За предоплаченный период у юзера может и не случиться проблем, разработчики не опубликуют новую версию, но пользователь уже отдал деньги за "будущие" услуги.
4.3. по критериям (общение бесплатно, апдейт за деньги) сервис можно назвать "сдельным", то есть ТП получает свою долю за конкретно предоставленные услуги.
4.4. внешний сервис оплаты или встроенный "кошелёк" выбирает владелец продукта для сокрытия или прозрачности денежных потоков, проверенные сервисы для сохранности операций. ТП может подсказывать маркетологам направления развития, контролируя объёмы общения с пользователем.
Огромная просьба к тем, чья экспертиза в ТП больше моей, дополните или исправьте вышеописанный набор знаний.
Комментариев нет:
Отправить комментарий