За время пандемии много стартапов лишились финансирования, но еще больше людей надеется сделать свой миллиардный бизнес. Портал Digital Report Russia опросил экспертов, как правильно подходить к формированию стартапов и чего опасаться людям, которые мечтают об инвестициях и будущих доходах. Сегодня на наши вопросы ответил исполнительный директор компании «Рексофт» Евгений Минеев.
Нужно ли стартапам фокусироваться на собственной разработке ПО или следует привлекать партнеров?
С момента своего создания «Рексофт» не раз выступал инкубатором стартапов или же их технологическим партнёром. Наиболее известные проекты, вышедшие из «Рексофт» — это интернет-площадка Ozon.ru и платёжная система Assist. Всего за свою историю компания активно работала более чем с 15 успешными стартапами, которые затем стали самостоятельными компаниями. Из последнего, мы выступили полноценным технологическим партнёром в проекте по созданию цифрового экспедитора AgoraFreight.com для организации он-лайн мультимодальных перевозок грузов. Поэтому у нас есть экспертный опыт, чтобы ответить на это вопрос.
Следует начать с того, что бывает два принципиально разных вида стартапов:
Технологические — как правило, они построены вокруг команды с сильной технической экспертизой. Для них привлечение внешних технологических партнеров может быть целесообразно в точках роста, когда скорость найма специалистов с рынка ограничивает развитие продукта. Учитывая довольно тяжёлый рынок труда в столицах, привлечение недорогого регионального ИТ-партнера может быть даже более выгодным с экономической точки зрения.
Есть и другой сценарий, где привлечение партнера может оказаться не только полезным, но и необходимым: это первые внедрения готового продукта в крупных заказчиках, каждый из которых имеет свою специфику. Погружение в нее требует длительного времени и определенного размера компании. Банально, но неизвестная небольшая компания без ИТ-партнеров просто не сможет добраться до топ-менеджеров крупных заказчиков, которые могут заинтересоваться и найти средства на внедрение нового решения. Для молодого стартапа эти ограничения могут носить фатальный характер, поэтому, зачастую, они ищут крупного ИТ-партнера для реализации первых проектов. Кстати, успешно отладив партнерскую схему, многие продуктовые компании в итоге вообще отказываются от самостоятельной работы с конечными заказчиками, сосредоточившись на развитии продукта.
Второй вид команд — это бизнес-стартапы, которые могут реализовывать новые бизнес-модели, опираясь на довольно тривиальные, в технологическом смысле, решения. Для них привлечение технологического партнера целесообразно с самого начала проекта, так как организация эффективного производства программного обеспечения — задача непростая даже для ИТ-компаний, а для бизнеса из другой отрасли она может оказаться и вовсе неподъемной. Производственных риски, умноженные на риски бизнес-модели, сводят вероятность успеха предприятия практически к нулю.
При какой схеме или бюджете привлечение партнеров будет выгодным, при каком — нет?
Бюджет меньше 15-20 миллионов рублей в год, скорее всего, сделает привлечение профессионального партнера невозможным и нецелесообразным. Это та граница, после которой можно рассчитывать на законченное изделие с соблюдением минимально допустимых стандартов качества.
Может ли привлечение партнера стать окном для утечки идеи, ведь стартапы боятся передавать свои наработки крупным ИТ-компаниям?
Это исключительно вопрос доверия. Сотрудничество с профессиональными аутсорсинговыми компаниями с именем и длительной историей на рынке влечет за собой такие риски в минимальной степени, так как, с одной стороны, они постоянно работают с интеллектуальной собственностью своих клиентов, и соблюдение профессиональной этики является «пропуском на рынок», с другой, запуск стартапов с их рисками, постоянным поиском инвестиций и непредсказуемыми результатами противоречит бизнес-модели таких компаний.
То есть там просто нет таких структур и людей, которым в голову может прийти идея украсть интеллектуальную собственность клиента и вывести ее на рынок под видом собственного продукта. Как правило, таким компаниям приходится решать противоположную задачу: найти и воспитать сотрудников с предпринимательским подходом для того, чтобы обеспечить рост собственного бизнеса.
Если технологическая идея покажется партнёру особенно успешной и масштабируемой, то скорее ИТ-партнер предложит свое вхождение в капитал стартапа или поможет с поиском потенциального инвестора.
Как правильно стартапам выстраивать свои отношения с ИТ-компаниями на рынке?
Если говорить про бизнес-стартапы, то отношения приходится выстраивать не столько с ИТ-компанией, сколько с конкретной командой, которую эта компания сможет собрать и предоставить. Между заказчиком и командой должна случиться в хорошем смысле «химия», которая позволит им работать как единое целое. Если этого не происходит, то проект ждут серьезные проблемы: от постоянной утраты компетенций из-за частой ротации специалистов до больших временных и финансовых затрат из-за неэффективности коммуникаций.
Первое, о чем необходимо задуматься заказчику, — это закрытие позиций «владельца продукта» и технологического эксперта на своей стороне.
Первый должен управлять развитием продукта и выступать посредником между предпринимателем — носителем бизнес-идеи и командой, второй — контролировать техническое ноу-хау, осуществлять приемку работ у подрядчика и, в целом, обеспечивать технологический процесс. В некоторых случаях эти роли совмещает один человек, но найти специалиста с бизнес-видением, хорошей коммуникацией и глубокой технологической экспертизой — это большая удача. Зачастую, помощь в поиске таких людей может оказать ИТ-партнер, которые реализует проект.
Если говорить о методологии разработки, то для стартапа крайне важно правильно распределить риски между заказчиком и подрядчиком: водопадная модель производства ПО с детальным техническим заданием, фиксированным бюджетом и сроками неизбежно приведет к конфликтам: требования будут непрерывно меняться, сроки и бюджет уползать в неизвестном направлении. Гибкие методологии в чистом виде сложны для заказчика с точки зрения контроля над бюджетом и сроками. Как правило, наиболее удобным является итерационный подход, где размер итерации подбирается таким образом, чтобы обеспечить баланс между гибкостью и предсказуемостью. Нужно быть готовым к тому, что схема взаимодействия может измениться несколько раз за время жизни продукта.
Также, в ходе разработки стартапа, крайне важно следить за жизненным циклом продукта. Переломной точкой является переход от фазы прототипа, где ключевыми требованиями являются скорость и гибкость разработки, к фазе продукта, где появляются первые пользователи, и необходимо следить за качеством и предсказуемостью вывода новых версий продукта. Этот момент является кризисным в жизни любого стартапа и требует перестройки процессов, стандартов качества, а зачастую даже смены части команды. Опытный ИТ-партнер поможет вовремя и аккуратно провести трансформацию проекта и заложить основы нужных процессов с самого начала разработки продукта.
