Не раз и не два каждая уважающая себя компания подумывала о том, как бы сделать самую хорошую и оперативную техническую поддержку пользователей.
Размышляя о методах, формулировках и других деталях, главным вопросом оставался один — КТО должен это делать?
Ведь это должно быть эффективно и полезно как пользователям, так и компании.
Кастинг «МОДЕЛЕЙ»
Размышляя над кандидатурами, обычно рассматривают:
• Community manager.
• Специально выдрессированная обезьянка.
• Немногим реже — программист.
• С некоторой долей вероятности попадает ПМ.
• И чаще всего — тестировщик...
У многих возникает вопрос праведного гнева —почему и тут тестировщик?
Причин может быть несколько:
• «Тестировщик — всезнайка» — он знает больше всех о самом продукте и о его уязвимостях.
• «Тестировщик — винтик-шпунтик» — оперативно среагирует на озвученную проблему.
• «Тестировщик — сыщик» — он примет меры,дабы исправить эту проблему в кратчайшие
сроки, или найдет того, кто это сделает.
• «Тестировщик — проводник» — может разобраться и объяснить пользователю на
понятном для него языке, как исправить проблему, даже если она не на стороне продукта.
Рассмотрим вариант «Community manager» (он же СМ):
• «СМ — робот» — как правило, он ничего не знает о самом продукте, только общие понятия.
• «СМ — ответственный» — узнав о проблеме, он о ней кому-то, наверное, сообщит. Кому — потом можно искать долго и нудно.
• «СМ — злобный буратинка» — он не поможет пользователю решить его проблему, если
проблема на стороне пользователя. А иногда, даже если и поможет, то все может обернуться
еще хуже и уж лучше б не помогал.
Следующий вариант «Программист»:
• «Программист — обычный» — знает продукт только в части своего кода.
• «Программист — иностранец» — он не умеет говорить на языке обычных людей о продукте.
Если и объяснит что-то, пользователь не поймет.
• «Программист — вредитель» — узнав о проблеме, он может исправить ее молча; может передать другому программисту; может отправить тестировщику; может решить, что это
не проблема, и т.д.
Остальные кандидаты — конструктор из характеристик СМ-а и программиста. Небольшой опрос показывает, что в российских и украинских компаниях, тестировщик сам занимается
технической поддержкой или находится в тесном сотрудничестве с ней.
Где это не так — можно только посочувствовать или поставить памятник. На выбор...
Подводя небольшой итог, согласимся с тем, что кандидатура тестировщика является наиболее подходящей для выполнения роли технической поддержки. Теперь давайте рассмотрим, какие подводные камни его ждут на этом пути и какую пользу можно извлечь.
ТЕСТИРОВЩИК — ОН ЖЕ ТЕХНИЧЕСКАЯ ПОДДЕРЖКА
Для начала рассмотрим ситуацию, когда тестировщик работает сразу на два фронта: и программу тестирует, и с пользователями «поболтать» не забывает.
Ложка дегтя
У тестировщика могут возникнуть некоторые проблемы, если он будет заниматься технической поддержкой пользователей и тестированием одновременно.
Первая — время.
Допустим, что его предусмотрели.
Вторая — встреча с кучкой пользователей- кристалликов, являющих собой единый айсберг, который отправил на дно известный всем кораблик...
Кристаллики бывают:
• «Пользователи — незнайки» — сообщают не о проблеме, а о сферическом вакууме, который
является непонятно чем, и на понимание этого вы тратите и время, и нервы ресурсы.
• «Пользователи — скромняжки» — некорректно сообщают о проблеме, и вы вынуждены искать кучу вариантов, вытаскивать из них информацию всевозможными пытками методами (кнут, пряник, клещи и т.п.).
• «Пользователи — бедняжки» — сообщают о проблеме, которая находится явно не на вашей
стороне, и вы должны помочь этим милым и трогательным или озлобленным личностям с ней
разобраться.
• «Пользователи — тролли» — особый индивид- вредитель, который придумывает баги и честно сообщает вам о них, а вы возвращаетесь к трате нервов ресурсов и времени.
Список может пополняться и варьироваться, но это основа того, с чем вы можете столкнуться.
Бочка пользы
Казалось бы, да к черту такие танцы с бубном, на кой оно бедному тестеровщику, когда работы по горло! А полезно это может быть по нескольким причинам:
• Оперативная реакция — если пользователям что-то создает дискомфорт, они мгновенно
поднимут бурю негодования, что позволит вам локализовать и устранить проблему в
кратчайшие сроки.
• Баг-халява — нет таких программ, где не существует бага/уязвимости, которая приносит
пользователю радость и халяву, а тестировщику бессонную ночь и валерьянку. Будет здорово,
если о таком виде «жука-уникального-с-планеты-Халявного-Зла» сообщит честный
пользователь.
• Баги-собственники — привязываются аки верный питомец исключительно к своему
персональному пользователю-хозяину. Найти баг можно в тот момент, когда ваше созвездие
сменило галактику в 45-й день месяца, совпавшего с лунным затмением, которое
бывает раз в 130 лет и... И счастье, если его сдаст пользователь.
ТЕСТИРОВЩИК И ТЕХНИЧЕСКАЯ ПОДДЕРЖКА — ВМЕСТЕ НА ВЕК!
Допустим, все-таки есть «СМ-уникум», который знает продукт, может ответить и помочь пользователю, а всю полученную информацию передает вам лично.
Идеальная схема.
Или нет...?
мая твая не панимает
Главная проблема всех времен и народов — коммуникация, игра в испорченный телефон.
Вот посадим мы их всех на лавочку, как в детстве играли, и посмотрим, что получится.
По порядку рассчитайсь!
1. Пользователь1.
2. СМ.
3. Тестировщик.
4. «Человек-исправлятор».
Допустим, Пользователь1 передает проблему СМ-у, тот — дальше по цепочке. До тестировщика дойдет наиболее полная информация, а к человеку-исправлятору попадет
уже локализованная проблема. Такую схему можно использовать только при условии, что пользователи идеальные, формулируют проблемы четко, а СМ не растеряется, когда вместо Пользователь1 — появится Пользователь 2, 5, 250, 1032, и т.д.
Усложним задачку, посадим вместо Пользователя1 — Скромняжку.
В этой схеме тестировщик будет переспрашивать, задавая дополнительные вопросы СМ-у,
СМ — скромняжке, скромняжка — ответит СМ-у, СМ... И все это с разным интервалом времени... Аааа, остановите этот замкнутый круг!!!
Представим, если там пользователь-бедняжка или, того хуже, тролль, а если все вместе и в количестве пару- тройку тысяч... Схема не подходит, ибо в ней возникнет вопрос, куда
тратится куча ресурсов, кто в ней слабое звено и тянет компанию на дно и пр.
И сколько еще б не было подходов и схем, в каждой имеется своя уязвимость, своя бага, если хотите.
Что в сухом остатке?
Тестировщик = техподдержка — идеал для небольших и средних компаний. В больших возникнут проблемы, там лучше набирать уже специально обученных людей. Идеальной схемы не существует, и как бы мы ни пытались охватить все проблемы, каждому необходимо
собрать свой конструктор из подходов и методик. Ведь каждая компания и ее продукты уникальны, и вряд ли кто- то знает, что подходит именно вам.
Ну и помните, талантливый человек талантлив во всем, неважно, тестировщик он, программист, специально обученная личность, ПМ или community manager.
