22 февраля FoxDevs собрался небольшой компанией в традиционном месте проведения круглых столов – Алекс Кафе, чтобы обсудить одну из актуальнейших проблем – успешность IT-проектов. Мы решили пойти от противного и собрать “вредные советы” для стартапов.

Своим опытом делились ребята из набирающего популярность сервиса CrocoTime – Александр Бочкин и Дмитрий Иванов. Сейчас у CrocoTime появляется все больше и больше клиентов, среди которых есть и крупные компании, но такого успеха они добились не сразу. Проект несколько раз оказывался на грани закрытия. К великой радости команды им удалось преодолеть все трудности. По итогам нашей беседы родился список того, что не нужно делать в развивающемся проекте.

 

Not to do list

Совет первый. Не относитесь к своему проекту как к бизнесу. Просто программируйте.

Именно так можно надолго затормозить развитие проекта. Если не задаваться вопросом “Как заработать с помощью сервиса сейчас?” или не иметь четкого плана монетизации, выход на точку безубыточности может затянуться слишком надолго. Последствия очевидны. Очень важно вовремя начать трансформацию стартапа в полноценную самостоятельную компанию.

Совет второй. Не думайте о маркетинге. Ваш продукт и так купят – ведь он идеален.

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

Совет третий. Не нанимайте продажников и маркетологов.

Да, вероятно, вы – человек-оркестр. Вы хороший программист, дизайнер, маркетолог, “пробивной” человек, как и все предприниматели. У вас накопился немалый опыт, который является хорошим подспорьем вашему бизнесу. К тому же, руководители проектов – весьма ответственные люди, поэтому часто сами занимаются маркетингом, прямыми продажами и ведут разработку проекта. Так было и в CrocoTime (говорят, даже неплохо получалось). Но наняв настоящих специалистов для этой работы, команда ощутила, насколько лучше профессионалы справляются с возникающими проблемами.

 

Совет четвертый. Добавляйте много клевых новых фич.

 

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

Совет пятый. Компенсируйте количеством джуниоров отсутствие у них опыта (самый вредный совет).

Казалось бы, чем больше рабочих рук, тем быстрее продвигается работа. А учитывая проблемы с наймом продвинутых программистов, зачастую не остается выхода, кроме как нанять побольше подающих надежды молодых разработчиков и обучить их без отрыва от производства. Вполне жизнеспособный подход, но не для premium b2b-продуктов. Для пользовательского функционала ошибки допустимы, но если с данными работает не человек, а другая машина – нет. Для CrocoTime этот урок оказался самым тяжелым. Во-первых, “основной состав” проекта тратил слишком много времени и сил на обучение в ущерб работе над проектом. Во-вторых, в разы повысился риск ошибок, цена которых слишком велика (может приехать служба безопасности и “наказать” виновников). Поэтому иногда единственное решение – небольшая команда энтузиастов-профессионалов с запредельной мотивацией.

Совет шестой. Не придавать значения техническим ошибкам.

То, что баги есть всегда – факт. Вопрос в том, насколько серьезно к ним относиться. Философски считать, что “it happens” или педантично отслеживать каждую ошибку и тут же ее исправлять? Важно учитывать цену вашей ошибки для ваших клиентов. Если на вашем сервисе завязан чей-то бизнес, ваши сервера хранят важную информацию или от данных системы в буквальном смысле зависит судьба людей, ошибки вам могут просто не простить. Максимальные меры безопасности, предельное внимание к багам, высокая квалификация программистов – это должно помочь (разумеется, решить эти задачи весьма непросто).

Совет седьмой. Не использовать собственные инструменты, кастомизированные под нужды конкретного проекта. И не продумывать весь технологический стек.

В FoxDevs мы уже касались темы кастомных инструментов, разрабатываемых для внутреннего использования в фирме. Время – деньги, и часто изобретение велосипеда очень дорого обходится фирме. Дороже, чем платные решения. Однако важно уметь правильно оценивать свой проект и создавать собственные инструменты тогда, когда это необходимо.

В CrocoTime в определенный момент встал вопрос выбора инструмента для автоматического сбора багов. Готовое решение с настройкой под себя или собственное решение на основе доступных технологий?

Сначала попробовали внедрить систему автоматического сбора отчетов о сбоях на основе Google BreakPad. Проблема была в том, что приходило несколько тысяч отчетов. Поэтому следующим шагом стала автоматизация процесса при помощи Mozilla Socorro. На этот раз возникли проблемы с настройкой, которая требовала слишком много времени и сил. В итоге было написано небольшое решение на основе Google BreakPad, которое используется до сих пор.

Другой задачей, вставшей перед проектом, была необходимость обработки большого количества статистики. Статистика представляет собой временные интервалы, объединенные в цепочки. Их нужно “пересекать”, объединять результаты, суммировать и проводить другие “экзекуции”. Для таких нетипичных для оперирования реляционными данными задач в некоторых базах данных предусмотрены специальные интервальные индексы. Но они покрывают не все задачи. При этом объем данных очень велик, и оперативной памяти не хватает.

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

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

Совет восьмой. Не быть готовым потерять все.

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

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

 
Лена Зверева
Дмитрий Иванов