Ожидания пользователей и реальность
Интерфейсы современных веб-сервисов открывают интернет для самых широких народных масс — для дилетантов в IT, не видящих разницы между сайтом и браузером. Но любой интернетчик быстро научается отличать «крутой» проект от «отстойного». Например, после пары заказов авиабилетов на anywayanyday.ru нормальный человек будет плеваться от pososhok.ru — аналогичного по функционалу, но убогого со всех остальных ракурсов.
VS.
Именно поэтому стартап должен с первого дня паблик-доступа к проекту предлагать отлаженный, проверенный, вылизанный сервис и такую же оболочку сервиса.
Однако очевидно, что любой сложный проект неизбежно будет содержать в конце первичной разработки немало ошибок и недочетов. Их может выявить только интенсивное тестирование.
Этапы запуска
Баг-тестирование (внутренний тест)
Не стоит пытаться выбить из программистов идеальный продукт с самого начала. Это одна из главных ошибок! Разработчики и их «приближенные» склонны действовать по сценариям, нетипичным для целевой аудитории. Например, общеизвестны проблемы с редактированием собственного текста: мозг «достраивает» логические мостики, даже «исправляет» элементарные орфографические ошибки. То же самое характерно и для сложных проектов: ошибки, глюки, баги, недоработки и «тупости» действительно эффективно вылавливают только посторонние. Перекрестное тестирование внутри команды (один программист тестирует код и функционал, созданные другим) частично решает эту проблему, но не устраняет полностью. Поскольку баг-тест проводится внутри команды девелоперов, следует применять, в основном, методику white-box (с доступом к исходному коду).
Задача внутреннего теста (smoke testing) — подготовить продукт к альфа-тестированию. Смысл в том, чтобы альфа-тестеры могли до конца выполнять требуемые сценарии, не натыкаясь на критические ошибки и отключенный функционал. На этом этапе необязательно делать сверхусилия для «бриллиантовой огранки» проекта: все равно альфа-тест выявит огромную кучу недостатков, с которыми нужно будет бороться — причем, бывает, радикальными методами типа полной переделки каких-то крупных элементов. Но, конечно, лучший вариант — представить к альфа-тесту версию продукта, в которой нужно дорабатывать только юзабилити, но не переделывать коренным образом основной код.
α — Альфа-тест
Если команда стартапа состоит не только из разработчиков, альфа-тест можно доверить сотрудникам других подразделений компании, представителям инвестора или собственному отделу QA (quality assurance). Но обычно в группу альфа-тестеров (вполне достаточно 10-20 человек) включают наиболее лояльных пользователей — «друзей», готовых составлять отчеты по недостаткам сырого продукта. Более профессиональный подход — обращение в компанию, занимающуюся юзабилити-тестированием и проверкой качества. Альфа-тест должен быть закрытым, «вход только по паролю». Не стоит знакомить широкую аудиторию со всеми ужасами недоделанного сервиса.
Цель альфа-тестирования и сопутствующей доработки — выпустить бета-версию продукта, которой могут пользоваться обычные, не подстегнутые дополнительной мотивацией представители целевой аудитории.
β — Бета-тест
В бета-версии уже не должно быть лакун типа страниц без контента, нерабочих кнопок без объяснения причин и так далее. Бета-версия отличается от релиза только внутренними алгоритмами, оптимизацией кода, компоновкой блоков, полнотой функций (при этом ВСЕ отключенные функции должны быть описаны и заявлены, а все кнопки, которые пока не нажимаются, обязаны выводить «объяснительную записку» о том, что они будут делать в релизной версии).
Результат бета-тестирования — подстройка сервиса по данным систем аналитики (поведение пользователей, страницы выхода и т.п.) и письмам в техподдержку.
Также на этом этапе необходимо провести нагрузочное тестирование, чтобы понять, какой трафик сможет принять веб-ресурс. В фильме «Социальная сеть» есть жизненный пример: Цукерберг яростно борется с другом-инвестором, решившим вывести свои активы и отключить серверы Facebook. «Мы растем со скоростью 200 000 аккаунтов в сутки потому, что сайт ни разу не падал!»
Релиз
Очевидно, что все вышеозначенные этапы не приближают день запуска в публичный доступ (и, соответственно, старта монетизации в том или ином виде). Однако практика показывает, что системный подход приносит плоды: лучше запуститься 1 сентября и наращивать базу пользователей (или ежесуточный трафик) на n человек в сутки, чем выложить сырую версию продукта 1 марта и печально следить за постепенно угасающими 0,01n в сутки.
Пример из практики SeoPult
Через эти стадии должен проходить как запускающийся проект, так и новые модули (функции, сервисы). Если говорить о SeoPult, то недавно мы представили новую услугу «Персональный менеджер». При внешней «однокнопочной» простоте с точки зрения пользовательского опыта, она заключает в себе новый программный модуль, целый отдел специально обученных сотрудников, полные регламенты консультирования и аудитов, несколько месяцев рабочего тестирования на выборке пользователей и сбор данных по реальной пользе для продвижения проектов пользователей.
- С начала разработки до выхода сервиса в публичный доступ прошло 5 месяцев. За это время, помимо интеграции нового функционала, удалось набрать и обучить команду поддержки.
- В течение 2 месяцев персональные менеджеры обслуживали 200 бета-тестеров из числа VIP-пользователей SeoPult. Все они остались довольны соотношением цены и качества услуги, а замеры позиций их сайтов показывают заметный рост.
Разумеется, только многоуровневое тестирование позволило сделать эту услугу действительно качественной. Если бы мы попытались запустить ее за две недели, с необученным персоналом поддержки и без регламентов, то вместо положительных отзывов получили бы мегабайты рекламаций.
Мы будем применять аналогичный подход для всех будущих модулей SeoPult и надеемся, что все разработчики присоединятся к нам в продвижении современной культуры и технологии стартапов в России. Идея не в том, чтобы привести тестирование к стандартам типа ISO 9126 — для небольших сервисов это нереально, — а в ответственном подходе к запуску проектов.