Исследования в стартапах: Qbaka

Многие согласятся, что сегодня интернет-проекты разрабатываются в основном для кого угодно, но не для веб-разработчиков. Люди различных профессий, социального статуса, вкусов и возраста обязательно найдут для себя интересный сервис в сети. Но те, кто создаёт эти сервисы, также порой нуждаются в определённом функционале, который бы облегчил их рабочий процесс. JavaScript — самый популярный язык программирования для придания интерактивности страничкам в интернете. Так почему же не упростить жизнь веб-технологам и разработчикам, которые создают сервисы, достойные нашего внимания?

Дигибу узнал, какие исследования проводил Qbaka — сервис для обнаружения ошибок в JavaScript на сайтах.

Qbaka
Андрей Мима

Рассказывает Андрей Мима

Создатель стартапа Qbaka, г. Санкт-Петербург

Как у вас родилась именно такая идея проекта и удалось ли вам заполнить пустую нишу?

Мы сложили вместе две идеи:

  • Первая идея — это похожий функционал, отслеживающий ошибки, но предназначенный, кажется, для Flash. Его писал мой друг Даниил. А я вспомнил, что подобная система используется «ВКонтакте» для отслеживания ошибок в JavaScript.
  • Вторая идея — система мониторинга ошибок уже со стороны пользователей, которую когда-то создавал другой мой товарищ, работая в одной компании. И я подумал, что хорошего мониторинга ошибок не хватает как раз для такого языка, как JavaScript, где это особенно актуально.

Ниша практически пустовала. Почему? Это отчасти загадка для нас самих. Автоматический мониторинг ошибок на сервере существовал давно, хотя и удобные инструменты, подключаемые как SaaS с веб-интерфейсом стали доступны недавно. Ошибки же в клиентских системах (таких как JavaScript, Flash) не мониторились, что создавало уйму проблем: приходилось узнавать у пользователей, где и при каких обстоятельствах произошли сбои при использовании того или иного сервиса.

Есть предположение, что только сейчас интернет дозрел до такого рода сервисов — насыщенные интерактивностью сайты стали заполнять интернет не так давно (около 5 лет назад), чуть позже они начали использовать системы аналитики (спустя год-два). А теперь стал актуален и автоматический мониторинг ошибок. Количество сайтов с насыщенным JavaScript превысило критическую массу, и уже нельзя сказать, что есть сайты со сложными интерфейсами. Есть сайты без них.

Есть ли у вас конкуренты и каким образом вы их искали?

Есть. Хотя на момент начала разработки их практически не было — все существующие системы решали немного другую задачу. Либо они были безобразно плохи в реализации. Первично мы искали конкурентов в Гугле. Чуть позже нам прислали в Твиттер ссылку на основного конкурента — стартап, который существовал на тот момент уже полгода и успел хоть немного стать известным. А под самый запуск из разных источников узнали ещё о двух новых проектах, которые разрабатывались параллельно с нашим. Теперь среди стартапов конкуренция высока. Но приятный бонус в том, что веб-сервисы ещё не знают, насколько полезной может оказаться штука вроде Qbaka. У нас есть хороший шанс успеть рассказать им об этом первыми.

Изучали ли вы ситуацию с похожими сервисами за рубежом?

Если в рунете сервисов, подобным нашему, нет, то в западном интернете есть несколько молодых проектов, начавших раньше нас, но ещё не успевших захватить рынок. Кроме того, есть много сервисов, которые решают похожую задачу для ошибок на сервере. Например, мы сами очень любим и используем New Relic и хотим попробовать заключить с ними партнёрство — наши инструменты идеально дополняют друга друга, и вместе они полностью покрывают все ошибки, которые могут случаться при использовании сайтов.

Есть ещё способ решать эту задачу бесплатно — через Google Analytics, причём некоторые так и делают. Это был бы серьёзный конкурент, но, к счастью, у них совсем другой профиль, а решение этой задачи через аналитику очень неудобно и ограничено по возможностям. Мы смотрим и перенимаем опыт у похожих по сути инструментов (фактически, инструмент любого мониторинга может быть полезным ориентиром). Например, мы сделали в Qbaka возможность совместного использования проекта, потому что поняли, что похожие системы часто используются не одним человеком.

Какие особенности вашего продукта помогают вам выделяться? Вы сразу их планировали или некоторые родились у вас в процессе разработки?

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

Ещё мы умеем показывать у каких именно пользователей произошла ошибка — этого не умеет ни один из конкурентов. Мы храним отдельные ошибки, а не только суммарную информацию о них — вы можете посмотреть всю информацию, тогда как у конкурентов она теряется. Уделяем большое внимание и качеству, и продуманности деталей самого сервиса — мы собираем даже те ошибки, которые случились до того, как загрузился наш модуль. А если наш модуль по-какой то причине оказывается недоступен, это никак не скажется на работе вашего сервиса.

Кто она — ваша целевая аудитория и как именно вы её изучали?

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

Наша аудитория — это веб-компании и веб-разработчики. Разработчики будут использовать наш сервис, компании за него платить. У нас не массовый сервис. Скорее, B2B. С другой стороны, узкоспециализированным его назвать сложно — представьте себе число сервисов в интернете, и почти каждый из них может быть потенциальным клиентом.

Сложность аудитории в том, что нужно достучаться до людей, принимающих решения. Разработчик в веб-сервисе не может сам оплатить и начать использовать наш продукт — он должен предложить его тому, кто отвечает в компании за бюджет. И хотя наш сервис и будет крайне дешёвым для любой компании, привлечение новых клиентов в такой продукт намного сложнее, чем, например, в социальную сеть.

Однако мы всё же опросили два раза большую группу знакомых разработчиков:

  • Первый раз мы спрашивали, интересен ли такой сервис в целом.
  • Второй — задавали более детальные вопросы, покрывающие основные сложные решения из жизни «Кубаки»:
  1. Нужен ли сервис их компании?
  2. Могут ли ошибки на их сайте приводить к убыткам?
  3. Сколько допустимо брать денег в месяц за подписку на «Кубаку»?
  4. Как часто обновляется код на их сервисе?
  5. Какие фишки они хотели бы видеть в нашем функционале?
  6. Как они узнают новости о подобных сервисах и рассказывают ли друзьям-разработчикам о них?
  7. А также обрадовались бы они, получив письмо с описанием ошибок на их сайте и предложением использовать «Кубаку»?

Последний вопрос задавался, чтобы понять, допустим ли такой способ распространения. Но это всё было вторично по сравнению с чётким пониманием того, что, зачем и для кого мы делаем.

Менялся ли ход разработки по мере изучения целевой аудитории и конкурентов?

Когда мы брались за сервис, то очень чётко представляли себе решаемую проблему, пути решения и как именно наш сервис будет использоваться. Мы сами являемся веб-разработчиками с многолетним опытом и пишем этот сервис почти как для себя. Да, новое появлялось в процессе: мы учитывали пожелания первых пользователей, чтобы сделать сервис ещё удобнее для них (например, нас попросили сделать поиск по пользователю, чтобы можно было посмотреть все ошибки, с которыми он сталкивался — скоро такая возможность у нас появится). Но глобальных изменений не происходило. Разве что пока мы отказались от идеи ловить ошибки в Flash — изначальные планы предполагали поддержку сразу двух сред. Но JavaScript оказался намного актуальнее сейчас.

Посоветуйте что-нибудь начинающим стартаперам в плане исследований. Что им следует учесть?

Мой совет стартапам: не переоценивайте ценность своей идеи. Я слышал столько идей, которые заведомо провальны, но их авторы были настолько вдохновлены задумкой, что это притупило их здравый смысл.

Очень сложно придумать абстрактную идею, которая окажется актуальной. Взять, например, Твиттер — кто бы мог подумать, что такое «выстрелит». Намного больше стартапов решают конкретные задачи, реализуют повседневные потребности людей. Вот тут уже проще анализировать и понять, нужно ли это хоть кому-то и как это будут использовать. Не бойтесь задавать себе сложные вопросы. Но неприятные ответы на них не всегда означают, что идею надо забросить. Чаще всего достаточно её немного видоизменить, сфокусироваться на чём-то конкретном в ней. Опросите случайных людей на улице, будут ли они вашими пользователями.

Смотрите вокруг себя. Лично у меня есть секретный блокнот. Туда я записываю идеи стартапов, которые рождаются из повседневных потребностей. Что можно было бы улучшить в вашей жизни благодаря технологиям? Лишь отдельные гении способны придумать, что людям захочется писать короткие публичные сообщения в интернете. Вокруг столько более простых и при этом нерешённых проблем! Любая из них может оказаться стартапом. Реальная проблема — это неплохое начало для хорошей идеи.

Не знаете какая пицца вкуснее других в городе? Стартап. Кончились деньги и хотите подработать частным извозом, а люди заказывают такси? Стартап — социальное такси. Ищете сантехника? Стартап — каталог специалистов рядом с домом. Все эти идеи уже работают, но есть ещё тысячи нереализованных.

Исследуйте мир, постоянно обращайте внимание на несовершенство того, что делают люди. Думайте, как можно облегчить жизнь или сделать её веселее. И будьте гибкими. Возможно, не все любят хоккей так же, как мы. И если ваш сервис будет посвящён не только хоккею, но ещё и, скажем, футболу — вот тут и может настать ваш звёздный час.