вторник, 17 июля 2012 г.

Support Request - "Прежде всего сядь и ПОДУМАЙ!"

Как обычно происходит support, или поддержка пользователей?

Обычно есть некая горячая линия, которая отвечает на вопросы конечных пользователей. Но, помимо них, есть еще и непосредственный Заказчик. Который вначале проводит приемочное тестирование, а потом уже отдает продукт своим пользователям.

Кто же общается с Заказчиком?

1. Аналитики

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

Но бывают и другие варианты...

2. Тестировщики

Ну а кто еще так знает продукт, как тестировщик? :) Логика опять налицо. Тестировщик - последняя стадия продукта, его последний этап. Он знал его на этапе требований, а теперь он докапывается до сути реализации. Ну кому еще отвечать на вопросы "а какие параметры можно отправлять через soap-запрос в этом методе?"...

Разумеется, бывают и другие варианты. Особенно в agile - командах, где нет четко выраженных аналитиков или тестировщиков. Но нас то интересует именно второй вариант, правда ведь?

Чем хорош такой подход?
  • Разнообразие - ты не ограничиваешься рамками "сел и потыкал", ты порой сам пишешь и согласовываешь ТЗ (ну а что делать, если оно непонятно написано?). Спектр твоих обязанностей расширяется и разнообразия в работе хватает с головой.
  • Быстрый feedback - обратная связь всем нужна, всем важна. Как иначе узнать, понятное у вас описание в википедии или не очень? У Заказчика нет Аналитиков/разработчиков под рукой, ему похуже будет...
  • Рука на пульсе - ты всегда знаешь, какие баги есть на предпродукционной платформе, удачно ли прошел релиз? Ведь кто "яйца на бочку" кладет ((c)Андрей Мясников), подтверждая, что ошибок в релизе нет, он - готов? Тестировщик! Кому, как не ему, первому узнать о проблемах пользователя?
  • Быстрый ответ - Заказчик тоже хочет быстрой обратной связи. И если у него есть проблема, он хочет знать, откуда она и когда ее поправят. Уверена, что тестировщик тоже очень хочет это знать, тут их интересы совпадают.
  • Соответствие ожиданиям - вы сталкивались с ситуацией "сломанного телефона"? Когда реализовали одно, а выяснилось, что нужно было совсем другое? Ситуация была очень ярко показана в ролевой игре в летней школе тестировщиков. А, чтобы такой ситуации не было, тестировщику надо знать, что нужно Заказчику. Какие у него возникают вопросы и пожелания. Как он пользуется системой...
В общем, сплошные плюсы. Назначаем тестировщика ответственным за customer@support и радуемся жизни. У менеджеров появляется время на более важные дела, а тестировщики держат руку на пульсе.

Казалось бы, все хорошо? НО! Подумайте сами о минусах такой почты...

1. Как обрабатывается заявка? Чтобы она не потерялась "где-то в почте у коллег", создается task в баг-трекере. В который аттачатся письма, в котором идет обсуждение, что ответить, что сделать итд.

Теперь представьте себе длинную переписку. И ее отображение в комментариях... Тут, как говорится, "лучше один раз увидеть".

2. А если тестировщик забыл приаатачить письмо? Дел много, главное - ответил, остальное ерунда. По прошествии времени сидит, смотрит на задачу - "блин, что-то же делал,а что?". Лезет в почту, ищет, аттачит... Время - деньги!

3. Тестировщик заболел / ушел в отпуск. Его Заказчика радостно передают другому. У этого другого информации - все, что в джире было. А ведь половины и не было (чтобы не раздувать комменты). Что делать? Куда бежать?

В общем, так подумаешь, подумаешь... И поймешь - надо Заказчиков в баг-трекер переводить!

Создать специальный тип задач - Support Request. И пусть пишут вопросы туда. А ответственные (читай - тестировщики) будут отвечать. Но одно дело - ответить на 2 строчки, а другое дело, переслать письмо, где эти самые две строчки окаймляют "Кто? Кому? Кто в копии? Тема письма", а также подписи.

Всем хорошо! Все плюшки подхода остались, а минусы решились! Добавилась информативность - теперь вы всегда в курсе, что происходит на проекте, даже если не входите в почту его support-a. И легко можете заменить коллегу.

Но! Опять это "но", будь оно неладно.

Ребята! Подумайте заранее. Ну если у вас уже есть такая почта. И в джире (возьмем как пример баг-трекера) уже есть куча тасков, созданных по этим письмам. Подумайте заранее о возможном переходе Заказчика в джиру!

А если не подумать? Зачем Заказчику вообще этот переход? Все за тем же - чтобы можно было следить, решают ли твои проблемы, чтобы можно было ссылаться на "а вот в этом письме (в этой задаче) мы говорили о том, что...", чтобы можно было отслеживать ход работ, в конце концов.

Так вот. Все Заказчику видеть явно не надо. Только свой проект и только такие запросы. Но старые запросы ему видеть интересно. А иначе какой смысл? Часть переписки - в джире, а часть - в почте.

Итак! Добавили права, открывать доступ к багам. В принципе, в той же джире это сделать несложно. Казалось бы. Особенно, если в заголовке задачи честные тестировщики указывали магические буковки "CR", ну или что-то похожее, чтобы можно было найти махом все задачи с приаттаченными письмами. В той же джире можно выделить все эти таски и парой щелчкой мышки поменять им уровень доступа.

Ура? Агащаз. Сначала багу открой и почитай комменты.
А что мы пишем в комментах?

"Хихи, наконец-то они поняли, что это неудобно"
"Да вы что? Это нереализуемо! Нафик всех!"
"Ма-а-а-а-аш, посмотри, плиз, тут можно что-то сделать?"
"По-моему, они нас динамят..."
...

Ну и всякие мелочи аля "Закрывающему потестить то-то" или "пофиксил тут-то", которые Заказчику, опять же, не нужны.

Так вот. Вместо того, чтобы потом отслеживать все эти комменты и выставлять на них ограничения (видят только коллеги), подумайте об этом заранее. И в тасках, в которые аттачите переписку с Заказчиком, весь флуд сразу ограничивайте на видимость. На всякий случай. На будущее. Пригодится.

PS - Начитавшись Демарко, вдохновившись мистером Томпсоном, я решила если не каждый день, то хоть иногда находить умные и/или полезные идеи в течение рабочего дня и записывать их...

PPS - А пряча в джире флуд 6 часов подряд, я не могла промолчать... 

7 комментариев:

  1. Гм.
    Давно изобрели такую штуку как саппорт. Саппорт не в смысле ответов на звонки - первая линия, а техподдержка, которая решает проблемы клиентов - линия вторая.

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

    ОтветитьУдалить
    Ответы
    1. Впочем, в небольших компаниях нельзя мыслить должностями, но ролями нужно.
      Есть роли - саппорт, тестер, разработчик, аналитик.
      И тестировщик по должности может временами выполнять роль аналитика и саппорта.
      Как и программист может иногда быть саппортом.

      Удалить
    2. А в некоторых компаниях есть еще и 3/4 линия...

      Удалить
    3. Волонтер, да, у нас, например, небольшая компания.
      И вторая линия - тестировщики, что удобно, почему - я описала.

      В прошлой компании была еще первая линия. А за вторую отвечали Аналитики. Те же звонки (только от Заказчика, не Пользователей), те же письма...

      А бедный тестировщик получает конечную багу по сломанному телефону и только после выпуска в продакшен узнает, что это вообще не то, что юзеры хотели)))

      Удалить
  2. Да, тут скорее решение проблемы первой линии, а не второй. Промежуточным результатом работы саппорта должен быть не таск с перепиской, а поставленная задача, которую уже можно передавать разработчикам. А заставлять разработчиков продираться через тонну переписки - дороговато выйдет.

    ОтветитьУдалить
    Ответы
    1. Ну... На самом деле:
      1. Разработчикам это бывает интересно
      2. Разработчики читают только описание и посл коммент, если НЕ интересно.
      3. А вот закрывающий задачу изучает переписку, порой находит нестыковки в "самом самом первом письме" и конечной реализацией :)

      Удалить
  3. Внутренний багтрекер - это круто, да!
    Он не связан с твоей почтой, он идет отдельным письмом, и в нем можно вести переписку, он сортируется по подразделам ключевого функционала, всегда можно найти по имени пользователя или нику, ты ничего не потеряешь, не потратишь дофига времени если пользователь корректно опишет проблему - вот тут минус, к форме отправки-обращения во внутреннюю связь должно быть несколько подменю, опять же ключевых проблем и инфы, которая вам нужна.
    таким образом у вас будут поступать сортируемые багрепорты, жалобы, с заполненной информацией, которая вам нужна для понимания проблемы.
    в 95% повторное обращение к пользователю с вопросами-уточнениями просто не понадобятся. Кроме как отписать - спасибо ошибка будет исправлена/уже исправлена.

    Ну и да, как вариант нужен человечек-жилетка, которому можно написать в почту с целью поплакаться на жизнь, правительство, умершего хомячка и тут еще ваш продукт свинью подбросил, ему бедному-несчастному. ))))

    ОтветитьУдалить