Seopult Cybermarketing Click.ru Seopult TV Trustlink Webartex.ru UpToLike.ru Blog.Seopult.ru Форум
15 апреля 2011

Рождение проектов: оптимальный подход

Ожидания пользователей и реальность

Интерфейсы современных веб-сервисов открывают интернет для самых широких народных масс — для дилетантов в 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 — для небольших сервисов это нереально, — а в ответственном подходе к запуску проектов.

Комментарии

  • Lighter

    Думаю, что нет смысла сравнивать Anywayanyday и Посошок. Первый — крупнейший сервис по продаже авиабилетов с прямым доступом к предложениям авиакомпаний и возможностью создания своего API на базе системы Галилео (Travelport), посошок же, как и многие другие подобные сайты, используют готовые модули поиска с небольшой возможностью изменения цветовой гаммы через CSS.
    Это просто разные весовые категории и разные направления: одни являются продавцами билетов, другие их агентами (хотя у агентов зачастую можно купить билеты дешевле).
    Для того, чтобы выйти на уровень AnyWay, нужны очень большие вложения, минимально — порядка 4-5 миллионов для того, чтобы только начать подобный бизнес, только создание самой основы бизнеса.
    Поэтому быть агентом дешевле — но при этом выше модулей, подобных Посошку не прыгнешь…

  • Дмитрий

    Посох такой же прямой продавец билетов от Галилео как и AWAD. Даже интересно, чей же агент посошок?

  • Андрей

    Да, не совсем правильный первый комментарий и частично согласен со 2м. Anywayanyday и Посошок одинаковые фирмы — они агенты по продаже авиабилетов авиакомпаний. Обе используют GDS — Галилео (теперь уже Travelport). Посошок работает на 10 дольше Anywayanyday — который появился 3 года назад, купив разоренный Avantix. Движки отличаются только дизайном и функционалом. У посошка видов оплат в 10 раз больше, офисы в разных городах и видов услуг больше, и ж/д есть, трансферы и отели. Похожая компания Посошок, но более крупная ДАВС http://www.davs.ru . Принципиальное отличие у всех дизайн у Anywayanyday дизайн и фeнкционал не рассчитан на взрослую аудиторию, а в формах Посошка и ДАВС разобраться легче. Вот и остается выбирать, что лучше красивые человечки и самолетики на разноцветной форме, или понятный всем возврастным категорям дизайн и функионал.

Расписание вебинаров и
мастер-классов
29 Март 2017 Среда 11:00
Евгений Костин,Руслан Байбеков
Как продвигать сайт в Яндекс и Google: работа с внешними ссылками
30 Март 2017 Четверг 12:00
Алексей Штарев,Виталий Кравченко,Александр Ожгибесов
Онлайн-конференция CyberMarketing-2017
4 Апрель 2017 Вторник 11:00
Евгений Костин
Базовый курс по интернет-маркетингу: введение
5 Апрель 2017 Среда 11:00
Николай Коноплянников
Видеомаркетинг для бизнеса от А до Я