Чтобы было понятно, о чем идет речь, сразу скажу, что наш сервис — биржа копирайтинга ContentMonster.ru. В данный момент, на ней выполняется более 300 заказов сутки и постоянно работает более 400 авторов. Работаем мы над его созданием уже больше полутора лет, и за это время набили некоторое количество «шишек», большую часть из которых можно было избежать. Скорее всего, если бы совершенных ошибок не было, то росли бы мы быстрее, пользователей было бы больше, а психика устойчивей. Итак, начнем.
1. Запуск апдейта в пятницу.
Для того, чтобы проект радовал своим постоянным ростом, нужно над ним неустанно работать. Пользователи ждут новый функционал, просят сделать необходимые для них фичи, намекают, что еще немного и они обидятся и уйдут к конкурентам. Мы постоянно записываем пожелания пользователей в отдельный список, делаем самые насущные на данный момент задачи и заливаем обновления на рабочий сервер.
Опытным путем было установлено, что лучше всего заливать обновления утром во вторник. Во вторник системой пользуется наибольшее по сравнению с другими днями недели количество людей и вероятность того, что ошибка проявится – максимальна. Среда и четверг немного хуже, но тоже годятся – пользователей почти столько же, но вероятность отловить ошибки до выходных меньше. Самое плохое время заливки – вторая половина пятницы. В этом случае «нескучные выходные» практически гарантированы.
Для себя мы выработали жесткое правило: если не успели залить до обеда в четверг, откладываем запуск до следующей недели.
2. Вовремя не продлили домен.
Наша система использует несколько разных доменов. На одном из них расположена система проверки уникальности текстов (все тексты, написанные авторами, проверяются на уникальность перед отправкой заказчику).
Однажды вечером, из-за непродленного домена, проверка уникальности остановилась, а за ней и вся система — тексты просто не отправлялись заказчикам. Данная ошибка достойна нуба, но она имела место и ничего с этим фактом уже не поделать.
Вывод очевиден: тщательно следить за состоянием оплаты доменов, и прочих онлайн услуг, используя специальный софт в виде календарей или планировщиков. Продлевать домены при первой возможности, а не откладывать все на последний момент.
3. Тестировать новые функции «вживую» на рабочей системе.
Однажды, в момент тестирования новой системы API биржи, значительная часть рабочей базы данных была удалена. Все закончилось хорошо (ежечасный бэкап помог), но неприятный осадок остался на всю жизнь – очень неприятное ощуещение, когда нажимаешь на кнопку и удаляется огромный кусок базы. Данная ситуация возникла из-за того, что недотестированные функции были залиты на рабочий сервер.
Кроме того, все происходило в час ночи, когда нашего программиста, конечно же, не было на рабочем месте… без программиста восстановить все удалось, но стоило немало времени и нервов.
Простое и очень важное правило отпечаталось всю жизнь: тестировать, тестировать и еще раз тестировать перед заливкой! И производить важные технические изменения в тот момент, когда все члены команды в рабочем режиме.
4. Осторожнее с массовыми операциями.
В начале работы сервиса, при операции по выплате гонораров авторам оплата была сделана дважды. В результате пришлось в личных сообщениях просить авторов вернуть деньги. По ощущениям – не очень приятно. Все копирайтеры, кроме одного, деньги вернули.
В результате родилось правило: всегда делать выборочную сверку данных перед нажатием на кнопку «Оплатить».
5. Массовый спам.
Настоящий epic fail случился с email-рассылкой около месяца назад: первые 500 заказчиков получили по 500 (пятьсот) писем с новостями системы. Как и следовало ожидать, столько мата в свой адрес мы не получали за все время существования сервиса. Оказалось, скрипт работал в системе отладки, и, не сделав тестовую рассылку, мы этого не заметили.
Вывод: перед любой рассылкой, обязательно предварительно делать тестовую на 10 емайлов, включая несколько своих ящиков.
6. Много проектов в работе одновременно.
Наверное, каждому создателю собственного сервиса однажды в голову приходит «гениальная» мысль о новом супер-мегапроекте, который «уж точно выстрелит» и поэтому «его надо срочно делать, пока такой же не появился». И вот мы бросаемся регистрировать домен, проектировать систему и создавать новое детище. В результате в лучшем случае завтра мы просыпаемся с мыслью о том, что вчера мы какую-то ерунду придумали и имеем на руках не нужный нам домен, в худшем — тратим n -человекодней на создание системы, забивая на основной проект.
Сейчас я скажу банальную вещь: качественно развивать сразу несколько серьезных проектов невозможно. Распыление сил неминуемо приводило к снижению темпов роста всех проектов. Сейчас у нас есть несколько ненужных доменов и два крупных проекта, которые мы пытаемся развивать одновременно.
Мы стараемся бороться с этой импульсивностью и, по крайней мере, не начинать новые проекты в первые несколько дней после возникновения идеи. Идеи по новым сервисам записываем в отдельный список – пусть отстаиваются.
7. Разработка сложных функций и опций, которые реально не нужны.
У каждого из нас в голове много иллюзий – заблуждений относительно реальности. Часть этих заблуждений относится к продукту, который мы делаем. Именно иллюзии заставляют нас разрабатывать и внедрять функции, которые в конечном итоге не востребованы. Это очень разочаровывает и приводит к потере времени и упущенным возможностям. Мы неоднократно вводили функции, которые не используются или используются очень слабо. Например, прямые переводы в системе.
Поэтому нужно перед созданием нового функционала опрашивать пользователей, нужно ли им вообще нововведение. Очень хорошо зарекомендовала себя следующая модель – делать только то, о чем просит сразу много людей и не обращать внимания на единичные запросы (особенно если их реализация связана с большими трудозатратами). Если хочется ввести что-то «революционное» — то, о чем пользователи еще не подозревают, желательно посоветоваться с экспертами.
8. Затягивание релиза.
Мы могли сэкономить несколько месяцев, если бы сразу запустили бета-версию бесплатного варианта биржи, не доводя до совершенства ненужные функции.
Вывод: показать публике (ограниченному кругу лиц) новую разработку как можно раньше после начала кодирования. Пусть она будет еще сырой, но зато мы узнаем о правильном векторе развития уже в самом начале.
9. Покупка рекламы без учета цены конверсии.
Некоторая реклама была довольно эффективна, но большинство вкладываемых в нее денег были потрачены впустую. Вот ошибки в этой сфере, которые привели к значительным денежным потерям:
— потеряны деньги на контекстной рекламе, которая не давала конверсии (вначале мы просто не удосужились настроить систему учета конверсии).
— покупка постов в блоге с ориентацией на количество подписчиков feedburner (такой рейтинг можно накрутить).
— покупка постов у блогеров, которые не пользовались нашим сервисом (такие посты получались не интересными и рекламными, совершенно другой эффект дают посты реальных пользователей)
— прикрепленная тема на форуме Searchengines.ru давала очень мало трафика и также не окупилась.
В итоге, несколько месяцев назад, мы на время вообще решили отказаться от покупной рекламы и это никак не повлияло на рост, который происходит, в основном за счет вирусных факторов.
Много сделано ошибок, будут и новые, ведь работа над проектом продолжается. Остается только учиться хотя бы на своих ошибках (а лучше изучать аналогичный опыт других людей) и не допускать их повторения в будущем, а также пытаться прогнозировать новые. Ведь не допускает ошибок только тот, кто ничего не делает.
Автор: alexlazarev
