15 Августа 2015 Kuoll 1 421 10 В избр. Сохранено

Как и зачем делают пивот? Пример Kuoll

В Kuoll мы разрабатываем веб-платформу, которая позволяет записать действия пользователей в виде проигрываемой записи. Последние 4 месяца мы поменяли позиционирование приложения и нам пришлось корректировать продукт. Интересно зачем?

Мнение автора может не совпадать с мнением редакции

Привет всем, меня зовут Дмитрий Кайгородов, мне 30 лет. Я работаю разработчиком программного обеспечения более 10 лет и, большую часть этого времени не понимал, почему нет сервиса для полноценной автоматизации баг-репортов (отчётов об ошибках). В мае 2014 года начал разработку продукта.

Запустили сервис, разместив видео на YouTube в октябре 2014 года. Ссылку на видео запостил в Facebook группе минских тестировщиков. Получил почти 500 просмотров. Около 50 регистраций. Сходил на несколько компаний, которые разрабатывают ПО. Рассказывал про продукт, собирал обратную связь, предлагал купить. На основе обратной связи сделал пивот.

Пивот

Зачем? Оказалось, что компании, которые разрабатывают ПО под заказ (наша первая аудитория)

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

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

Для того, чтобы сделать пивот, понадобилось переписать продукт. Было: расширение для браузера chrome, которое позволяет записывать любой сайт. Стало: скрипт, который разработчик веб-приложения встраивает в страницы сайта. Теперь мы поддерживаем разные браузеры, в том числе мобильные. Разработка новой версии началась в мае 2015.

Про Kuoll

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

Обычный сценарий таков:

пользователь веб-приложения замечают ошибку, он переходит на страницу поддержки, вводит описание проблемы (например: "ничего не работает, за что я деньги плачу!???”). Отправляет свой запрос.
Веб-приложение предлагает записать действия, которые приводят к ошибке.
Пользователь соглашается, начинается запись, пользователь повторяет разрушительные действия. Жмёт “готово" — отчёт об ошибке отправляется разработчику веб-приложения.

Программист получает запись и видит на ней:

ползунок для перемещения по записи (как при проигрывании видео) и страницу — сохранённый html и css показывает страницу так-же как её видел конечный пользователь.
сетевые запросы/ответы XHR
события браузера и цепочки вызовов

Здесь можно посмотреть как работает Kuoll:

В результате программист может проанализировать проблему и исправить её, даже не имея возможности воспроизвести ошибку. Программист теперь не должен гадать, что имел в виду пользователь. Пользователь быстро получает исправление ошибок и отсутствие советов типа: “опишите, пожалуйста, ошибку подробнее”. Менеджер имеет более эффективный и управляемый процесс, а владелец — сокращение расходов. Поэтому:

Заходите на сайт, регистрируйтесь https://www.kuoll.com/signup.html, пробуйте и оставляйте отзывы.

-----------------------------------------------------

К сожалению, после публикации статьи spark меня сразу заблокировал. Я написал администрации, надеюсь после выходных меня разблокируют. После этого я смогу ответить на комментарии. Можете также оставлять комментарии здесь: https://www.facebook.com/kuollapp. Кстати, комментарии на редкость содержатетельные, спасибо. Сейчас редко где такие в интернете увидишь )

В избр. Сохранено