Кейс Arendata: как ИТ-стартапу избежать проблем роста

ИТ-стартап на высоко конкурентном рынке

Мы выбрали непростой путь. В России существует множество ИТ-компаний, разрабатывающих программное обеспечение. Но, в основном, это прикладные системы: например, ПО для бухгалтеров или логистики, приложения для электронного кошелька или подсчета калорий. Мы же решили сделать своим поприщем сложную системную разработку, не распространенную в нашей стране.

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

Принципы Кремниевой долины и мировых лидеров

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

• Понимать конкретную область, в которой мы собираемся работать;
• Иметь целостную идею. Такой идеей стало создание единой платформы данных из различных open-source-компонентов;
• Вовремя сделать первые версии продукта и на них проверить жизнеспособность идеи;
• Оперативно и четко оценивать ресурсы, которые потребуются для создания прототипов новых продуктов;
• Отказываться от нежизнеспособных идей.

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

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

Решая вопрос, как выстроить внутри компании разработку и что взять за ее основу, мы рассмотрели самые разные методики. Среди них Agile, Scrum, Kanban, методология парного программирования (это разные методологии динамичной разработки, которые определяют, как в компании будет строиться разработка программных продуктов). Однако вскоре стало ясно, что универсальной методики нет. Нужно строить собственную, выбирая из существующих наиболее релевантные подходы.

В целом, выйдя из американской компании-разработчика Pivotal, мы до сих пор используем ее подходы к разработке программного обеспечения и поддерживаем с ней постоянные рабочие контакты.

Не менее сложным для нас оказался поиск принципа организации разработки. В его рамках мы изучили разные методики, и увидели много полезных практических советов по реализации методологии для реального проекта у шведского стримингового музыкального сервиса Spotify. Эта компания регулярно выкладывает в свободный доступ много интересных материалов, часть информации из которых мы взяли за основу, легко сумев ее применить.

Вот что мы почерпнули у Spotify:

• За каждую часть продукта должна отвечать своя команда. У нас есть платформа данных, состоящая из продуктов, за которые отвечают свои группы людей. При этом нельзя перемещать людей из команды в команду без их желания;
• Горизонтальное объединение людей со смежными ролями из разных команд. Например, разработчики, занимающиеся одним продуктом, регулярно общаются с разработчиками другого продукта, а DevOps-инженеры — с DevOps-инженерами. На еженедельных стендапах они обмениваются опытом. Кроме того, мы проводим внутренние митинги, на которых тимлид отслеживает качество выполнения задач;
• Тимлид указывает цели, но предоставляет автономность разработчикам;
• Все разработки строятся на базе open-source-модели: коммиты и pull requests делаются в соответствии с требованиями open-source-сообщества, документация ведётся на английском языке, код открыт на GitHub. Это происходит даже в том случае, если продукт пока не планируется отдавать в open-source;
• Делать частые, но небольшие релизы — не более нескольких ключевых изменений кода в одном релизе.

Пример доступных материалов от Spotify.

Проблемы роста стартапов

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

1. Отсутствие понимания рынка. Самая большая проблема для стартапа — это понять, будет ли его продукт востребован. Точно узнать это помогает простая методология: создайте прототип и протестируйте его на рынке. Так вы проверите и правильность выбора целевой аудитории, и верность понимания её потребностей. Мы видели, как рядом с нами проваливались компании, не понявшие рынок и принявшиеся реализовывать идеи, основываясь лишь на каких-то косвенных признаках их востребованности. Например, погнавшись за популярным трендом.
2. Попытки создать идеальный продукт. Распространенная ситуация: у стартапа есть идея, и он долго рожает в муках продукт. Но, когда выходит с ним на рынок, выясняется, что нишу уже заняли конкуренты, рынок за такой продукт платить не готов, рынку нужно немного не то. Для стартапа крайне важно быстро облачить свои идеи в некий продукт, который можно показать рынку и начать собирать обратную связь. Мы шли и продолжаем идти по такому пути: четко идентифицируем корневую боль потенциальных клиентов — те решения, за которые они готовы платить, но сейчас их либо нет на рынке, либо они присутствуют в ограниченном количестве. Если понимаем, что нам есть, что предложить, быстро описываем идею и показываем ее ограниченному кругу лояльных клиентов или партнеров, получаем от них подтверждение того, что мы правильно поняли боль, а затем разрабатываем прототип продукта. Но ни в коем случае не показываем продукт в состоянии, когда его уже сложно поменять. Порой у нас возникает идея какого-то продукта, но мы не можем её реализовать, например, потому что не получается подобрать вовремя профильных специалистов или ответить на какие-то вопросы при построении стратегии. Время идет, и идея сама собой отмирает, так как теряется ее актуальность.
3. Размытость фокуса. Фатальная ошибка — стараться объять необъятное, не имея четкого представления и стратегии развития продукта. Это особенно заметно в условиях структурированного рынка. Хорошо, если ваша идея сфокусирована на проблеме в одном сегменте: например, вы решили продавать мебель для медицинских клиник. Хуже, когда идея решает понемногу проблемы из нескольких сегментов. Результатом этого становится размытое позиционирование: вместо решения конкретной проблемы стартап утверждает, что может все. Такие заявления всегда настораживают потенциальных клиентов: тот, кто говорит, что умеет все, на деле не умеет ничего. Поэтому лучше начинать с простой идеи с четким позиционированием и выявленными болями целевой аудитории.
4. Отсутствие кадров на рынке. Кадры — это та проблема, с которой мы столкнулись еще на старте и которая осталась актуальной до сих пор. Осознав, что нам сложно набирать профессионалов на рынке, мы начали готовить профильных специалистов сами. Определили набор базовых компетенций сотрудников, чтобы быстро учить их решению наших задач. А также разработали ряд курсов, которые используем как для обучения собственных новых специалистов, так и сторонних.

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

• Наша команда выросла до 60 человек, и продолжает активно развиваться.
• Среди наших клиентов десятки крупнейших компаний России и Казахстана. В их числе безусловные лидеры по инновациям в своём сегменте: X5 Retail Group, ПАО «Газпром нефть», Счётная палата РФ, НЛМК, ПАО Ростелеком.
• Построили развитую сеть партнёров-интеграторов (более 12), которые внедряют наши решения.
• Заключили технологические альянсы с крупнейшими ИТ-компаниями: IBM, Accenture, Mail.ru, Яндекс.
• Сделали первые шаги за пределы России: наши продукты успешно внедряют компании в Казахстане и Турции.
• Крупнейшие cloud-провайдеры выбрали нашу платформу в качестве основы для построения сервисов данных в своих облаках.
• Подразделения компании находятся в Москве, Санкт-Петербурге, Хабаровске, Твери, Ростове-на-Дону, Владивостоке. Это позволяет нам обеспечивать поддержку бизнес-критичных систем заказчиков в формате 24×7.
• Количество наших коммитов в open-source проекты превысило сотни. Так, в 2019 году Arenadata стала вторым крупнейшим коммитером в международный проект аналитической СУБД Greenplum опередив, например, Alibaba Group.

Короткие рекомендации

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

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

Тем, кто сейчас задумывается об открытии своего проекта, я рекомендую прочитать вот такие книги:

• «Стартап. Настольная книга основателя», Дорф Боб и Бланк Стив;
• «Спроси маму. Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?», Фитцпатрик Роб;
• «Думай медленно. Решай быстро», Даниэль Канеман;
• «От нуля к единице. Как создать стартап, который изменит будущее», Блейк Мастерс и Питер Тиль.

Источник публикации: РБК