Два года разработки — и два месяца работы: почему белорусский конкурент Jira чуть не закрылся

08 декабря 2017, 09:00

В течение двух лет белорусская команда программистов вела разработку новой системы управления проектами — конкурента Jira и Trello. Но спустя всего два месяца после запуска продукт оказался на грани ликвидации и даже успел попрощаться с пользователями: инвесторы разочаровались. Затем случилось невероятное — СЕО и идейный вдохновитель Александр Сергеев в считанные дни выкупил код системы, сменил инвестора, сократил команду (с 35 человек до 10) и стартовал новый проект HYGGER. Тем временем американская компания Atlaz, для которой разрабатывался одноименный продукт, продолжит работу над своими проектами.  

Читать далее...

В основе HYGGER — «старый» код, который разрабатывался белорусской командой на протяжении двух лет, и база данных: от пользователей не потребуется перемещаться на новую платформу «вручную», вдобавок они получат бесплатный месяц в подарок. 

В интервью dev.by Александр Сергеев открыто рассказал, что произошло и что будет дальше: эта информация может быть очень полезна другим белорусским продуктовикам — тем более, что если всё пойдёт по плану, они получат «зелёный свет».

Основная фишка новой системы управления проектами по методологии Agile в том, что она применима не только в командах технарей (как Jira или белорусский продукт Targetprocess), но и в любых других. Разработкой системы занималась команда из 35 человек. Продукт запустили 18 сентября 2017 года, но спустя всего два с половиной месяца инвесторы вышли из проекта. На тот момент потенциальными пользователями системы были 7984 компании (они прошли полную регистрацию).  

Причиной кризисной ситуации стали разногласия между партнёрами в понимании будущего проекта.

Предыстория

CEO Александр Сергеев задумался об идее проекта, когда на рынке было два крупных игрока: сложная Jira для программистов и упрощённая Trello для «нетехнарей». 

— Мне нравились оба инструмента, но в Jira, например, много избыточности и наследства — старого функционала, который не нужен современным командам, а в Trello нет многих необходимых функций (Agile, спринтов, репортов по спринту). В Jira могут работать только технари. Клиенты, маркетологи, офисные сотрудники, менеджеры по продажам не в состоянии понять Jira. Поэтому мне пришла идея объединить эти два инструмента. Я понимал, что это дорогая разработка, но выход Atlassian на IPO и её оценка в $4,5 миллиарда подтолкнули нас к старту. Плюс сигналом послужил тот факт, что рынок разработки ПО растёт и расширяется.

Сначала команда хотела сделать улучшенную версию Trello для небольших команд (до 30 человек), а вторым шагом — доработать продукт для средних команд (до 200 человек), который уже станет конкурировать с Jira.

— Обе задачи достаточно объёмные. Только кажется, что Trello — простой инструмент, но это не так. Точнее, отчасти это так, но для пользователя — юзабилити в Trello действительно на высоте. А нам, чтобы эту простоту повторить, пришлось реализовать море фич. Вы только откройте карточку и посмотрите, что там с ней можно сделать! Мы добавили то, чего нет в Trello, например, backlog-доски для приоритизации идей и фич (то, что нужно менеджерам по продукту), roadmap для высокоуровневого планирования (для любых менеджеров). Мы делали не просто отдельный продукт, а экосистему, которая поможет расширять функционал за счёт различных плагинов. Планировали сперва сделать базовый софт, а потом отдельным продуктом Wiki. 

На бета-тестировании команда получила позитивный фидбек и поняла: не только разработчики новой системы считают, что Jira сложная, а Trello недостаточно функциональная.

Спустя два года разработки, в сентябре 2017 года, продукт запустился — и через два с половиной месяца оказался на грани закрытия. 

Сокращённая команда переезжает в новый офис. Фото: dev.by

Что пошло не так. Мнение инвестора

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

Работа над новой системой объединила выдающуюся команду и продемонстрировала отличное качество разработки: хороший код и интерфейс, считают инвесторы, это мнение было высказано в ходе открытой дискуссии на страничке Александра Сергеева в Facebook, за которой следил в том числе dev.by (сейчас пост удалён). Однако проект «сжигал» слишком много денег, и первые месяцы работы показали, что возврата инвестиций придётся ждать слишком долго. 

Ключевой ошибкой в ходе дискуссии было названо недостаточное изучение потребностей будущих пользователей — то есть отсутствие «правильного Customer Development» на старте разработки. Из-за этого разработчики недостаточно хорошо понимали, что именно нужно рынку и нужно ли. Второй важной проблемой инвесторы считают затягивание сроков разработки с 14 до 22 месяцев: дополнительное время стоило создателям около $1 млн.

В первые два месяца после запуска отток зарегистрированных пользователей оказался в разы больше притока: примерно 15-20 компаний регистрировались каждый день, в то время как 70-100 переставали пользоваться продуктом. На момент закрытия у проекта было около 10 платных клиентов и 105 платных сотрудников. При тренде в 5 платных клиента в месяц выход на самоокупаемость мог бы произойти через десятки лет, полагают инвесторы.  

Рекомендация инвестора стала цитатой дня в Facebook

Было бы правильней не вести долголетних разработок, обещая сотрудникам и акционерам морковку будущего счастья, уверены инвесторы: если после запуска продукта через 2-3 месяца продукт не принят рынком и у вас нет чёткого плана по исправлению ситуации — немедленно закрывайте стартап: «Честно скажите: мы старательно работали и мы крутые, но мы сделали красивую хрень, которая не нужна пользователям».

На сегодня инвесторы отказываются обсуждать проект, приняв решение не комментировать эту историю, а также «личные проекты Александра». Американская компания со штаб-квартирой в Сан-Франциско продолжит двигаться своим путём. 

Что пошло не так. Мнение СЕО

— У нас с инвестором был большой кредит доверия (работали вместе с 2009 года), но в какой-то момент начались разногласия и непонимание, — поясняет Александр Сергеев. — Поскольку инвестор не занимался продуктом, он не чувствовал его так, как я. Продукт не может приносить большую прибыль, когда в нём не доделана базовая функциональность — это как в калькуляторе нет единицы или двойки. Многим, например, не хватало интеграции с GitHub, Bitbucket, Dropbox, стори поинтов на спринт-досках, отчёта по скорости спринтов.

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

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

По словам Александра, отток зарегистрированных пользователей оказался в разы больше притока из-за широкого сегментирования рекламы на Facebook.

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

Статистика продукта, которая может быть полезна другим продуктовикам

Выводы: как учесть этот опыт и не повторить ошибки

Автор проекта Александр Сергеев считает, что делать пессимистичные выводы после 2,5 месяцев с момента запуска проекта рано и собирается продолжать работу над HYGGER, учитывая прошлые ошибки.

      1. Customer Development

— Любой новый проект должен начинаться Customer Development — исследования не интерфейсов, а людей. Мы пытались понять, какие проблемы есть в Jira и Trello, а это всё-таки разные вещи. Мы тестировали проблемы конкурентов, а не своё решение и насколько оно будет востребовано.  

Классический пример неправильного исследования: на выходе из магазина спрашивать у людей, какой хлеб они купили и почему. Люди придумают кучу оправданий: например, они любят чёрный цвет и т.д. Когда людям нужно что-то объяснить, они постфактум придумывают такое, чему потом сами сильно удивляются. Правильнее было бы повесить камеру возле прилавка и понаблюдать за ними. Причину выбора того или иного хлеба, конечно, сложно было бы определить только по видео, но в наших онлайн-системах мы можем проанализировать поведение пользователей и по записанным событиям понять некоторые причинно-следственные связи, почему они действовали именно так, а не иначе.     

Customer Development ещё до запуска проекта позволяет проверить три фундаментальные гипотезы: есть ли аудитория и рынок, является ли ваше решение лекарством, а не витаминкой, которую забывают принимать на второй день, и какие каналы продвижения наиболее эффективны для вашего сегмента. Одно дело, когда вам по телефону рассказывают о проблеме, а другое — когда вы видите её своими глазами.

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

Для выбора первостепенной функциональности в системе мы использовали модель Кано: первыми создавали ожидаемые функции, затем желаемые, а потом уже восхищающие. Дальше будем продолжать развивать функционал и конечно же внедрим в компании подходы customer development. Возможно, нас испортили деньги, мы позволяли себе то, что обычно не могут себе позволить стартапы — ту же рекламу дорогую на Facebook закупали во время бета-тестирования. Надо было выпустить как можно быстрее MVP, чтобы проверить, насколько продукт будет востребован аудиторией.

«Чёрный лебедь» может прилететь в любой момент. Поэтому желательно заранее продумать, какие лебеди могут прилететь и предусмотреть, чтобы их ждали с накрытым столом, и они, покушав, сразу же улетали.

2. Тест на совместимость партнёров по бизнесу

Перед тем как стать партнёрами, сделайте все упражнения из этой книги и убедитесь, что у вас одинаковые взгляды на бизнес, обязанности, на ваш вклад и вклад партнёра. Пропишите сценарии и проработайте совместное будущее. Это как брачный контракт: стрёмно, но лучше разойтись на старте, чем через 9 лет совместного бизнеса.

Мнение белорусского конкурента: показатели противоречивые, но закрывать было бы рано  

Это самая невероятная история в белорусском продуктовом бизнесе за долгое время, считает Михаил Дубаков, чья компания Targetprocess занимается созданием системы управления проектами уже более 13 лет. 

Данные по работе проекта за первые месяцы, по его мнению, оказались «достаточно противоречивыми».

Он согласен, что в такой ситуации ликвидировать продукт не было оптимальным решением: у системы уже были клиенты и какая-то выручка. «Лично я бы не закрывал компанию на данном этапе, — говорит Дубаков. — Продукт скорее всего будет способен прокормить команду из десятка человек через год. Но это, конечно, не история типа Slack».

Возможно, стоило уменьшить команду до 6-8 человек, чтобы сократить издержки, предложить им опционы и продолжить работу в течение 6-12 месяцев, которые позволили бы «малой кровью» выйти на более весомые финансовые показатели. В общем-то, что и было сделано.

Другим продуктовикам он не советовал бы начинать проект силами 20-30 человек без инвестиций, поскольку «это очень рискованно»:

— Я бы начинал небольшой командой в 4-6 человек и увеличивал команду только после доказательств, что продукт покатил, то есть примерно через 3-6 месяцев после выпуска на рынок. Если брать, например, наш Fibery, то если через 2 года у нас ничего не получится, то убытки составят где-то $400 тысяч, а не 2-3 миллиона. Потому что команда — 5 человек. 

 

Текст: Диана Васильева, Наталья Провалинская

Фото: dev.by

Обсуждение