Эта часть изначально была опубликована в Maddyness. Посмотреть оригинал статьи можно здесь.
Ульрик Стиг Хансен
Большинство основателей стартапов согласятся с тем, что преимущество первопроходца за счет сокращения времени выхода на рынок является неотъемлемой частью их долгосрочной стратегии успеха.
Один из лучших способов сократить время выхода на рынок — это купить, а не создавать инструменты, необходимые для повышения производительности вашей команды.
Теоретически большинство основателей и технических директоров понимают эту концепцию. Появление GitHub устранило необходимость во внутренних инструментах контроля версий. Stripe сделал построение внутренней платежной инфраструктуры делом прошлого. И никто больше не создает внутренние инструменты обмена сообщениями или списки адресов электронной почты — зачем беспокоиться, если вы можете купить Slack?
И все же многие стартапы, ориентированные на ИИ, продолжают создавать свою инфраструктуру данных собственными силами. Они считают, что их вариант использования особенный и специфический, поэтому для него требуются внутренние инструменты, и они должны нанять команду инженеров-программистов для их создания.
Поверьте мне, это не так, и вы этого не сделаете.
Создание внутренней системы данных занимает месяцы. Это удлиняет время, необходимое для выхода на рынок, и результат не даст вам преимущества перед конкурентами.
С повышением точности моделей машинного обучения и снижением вычислительной мощности основное конкурентное преимущество стартапа, ориентированного на ИИ, заключается в наличии доступа к обилию реальных данных и обучении их модели. Быстрый выход на рынок означает получение доступа к большему объему данных. Доступ к этим данным улучшит вашу модель, и именно это даст вашему продукту конкурентное преимущество.
Всего за последние несколько лет рынок программного обеспечения для инфраструктуры данных значительно расширился, поэтому инженерам-программистам редко приходится создавать инструменты собственными силами.
Стартапы, ориентированные на ИИ, по-прежнему стремятся создавать инструменты собственными силами, но, в конечном итоге, использование собственных инструментов приведет к пустой трате ценных инженерных ресурсов, которые можно было бы лучше потратить на подготовку модели машинного обучения к выходу на рынок.
Приложение к внутренним инструментам
Не так давно все приходилось создавать с нуля, и покупка решений для инфраструктуры данных у внешнего поставщика была невозможна.
В результате многие компании, занимающиеся приложениями ИИ, основанные в конце 2010-х годов, используют устаревшую инфраструктуру — не потому, что это хорошее бизнес-решение, а потому, что они уже заплатили за разработку инфраструктуры. Мысль состоит в том, что они создали инструменты, инструменты работают для их текущего варианта использования, и прекращение использования инструментов было бы пустой тратой денег.
Добро пожаловать в заблуждение о невозвратных затратах.
Это краткосрочное мышление не учитывает расходы, необходимые для обслуживания пользовательской инфраструктуры, и затраты на расширение этой инфраструктуры в случае возникновения нового варианта использования. С точки зрения бизнеса, создание собственных инструментов связано с дополнительным риском, что члены команды, создавшие инструменты, часто обладают институциональными знаниями, необходимыми для их обслуживания. Если они уходят, это знание уходит с ними.
Создание внутренних систем является сложной задачей, их обслуживание обходится дорого, и часто они не отвечают потребностям конечных пользователей. Поверьте, я бы знал. В течение многих лет я работал в крупных финансовых организациях. Эти компании нанимали высококвалифицированные команды инженеров и ежегодно тратили миллиарды долларов на свои внутренние технологические системы. И знаешь, что? Их внутренние системы все еще отстой.
В наши дни на рынке часто есть продукт, который дешевле и на порядки лучше, чем внутренний инструмент. То, что что-то было сделано определенным образом, не означает, что мы должны продолжать делать это таким же образом. Собственные инструменты были лучшим решением своего времени, но это время прошло.
Сосредоточьтесь на продукте
По своей сути, большинство компаний, ориентированных на ИИ, сосредоточены на создании моделей машинного обучения, которые могут извлекать ценную информацию из данных. Чтобы вывести свои продукты на рынок, эти компании должны обучать модель на данных до тех пор, пока она не сможет делать точные прогнозы на основе данных, которые ранее не публиковались. Вся подготовка, необходимая для обучения модели — очистка данных, приведение необработанных данных в читаемое состояние, управление конвейерами данных — входит в компетенцию инженера данных.
Хороший дата-инженер — дорогое, но стоящее вложение. Однако, чтобы получить максимальную отдачу от своих денег, компаниям необходимо убедиться, что у инженеров есть лучшие доступные инструменты, чтобы они могли работать эффективно и результативно.
Часто инженеры-программисты не создают собственные инструменты с расчетом на инженеров данных, поэтому эти инструменты не отвечают их повседневным потребностям. Работа с неоптимальными инструментами означает, что инженерам данных приходится тратить время на малоценные действия (такие как написание синтаксических анализаторов для преобразования одного формата данных в другой или изучение Javascript и Django для инструментов веб-разработки) и устранение проблем с инфраструктурой. Эти отвлекающие факторы ограничивают их способность сосредоточиться на улучшении продукта.
Как основатель стартапа, я хочу, чтобы мои инженеры сосредоточились на нашем продукте, и я стремлюсь направить наши инженерные ресурсы на то, чтобы сделать наш продукт лучше. Я не заинтересован в том, чтобы наша команда тратила свое время на создание внутренних инструментов, когда мы можем покупать решения проблем, с которыми мы сталкиваемся.
В последнее время нашим разработчикам нужно найти способ воспроизвести ошибки в нашей кодовой базе внешнего интерфейса. Это сложная проблема, и ее решение позволит нам лучше обслуживать наших клиентов. Через несколько месяцев мы решили, что для этой задачи нам придется построить внутреннюю инфраструктуру.
К счастью, примерно в то же время мы также наняли нового инженера по интерфейсу, который случайно сказал нам, что его предыдущий работодатель использовал программное обеспечение под названием Rollbar для решения той же проблемы.
Покупка сделана. Задача решена.
Создание этого инструмента было бы катастрофической тратой времени, потому что это потребовало бы значительных ресурсов и ограничило бы нашу способность сосредоточиться на более важных вопросах, связанных с продуктом.
Всего несколько лет назад внешние решения не были доступны для большинства проблем обработки данных. Теперь стеки программного обеспечения появляются каждый день, предлагая специализированные решения, поэтому принимайте разумное решение и не дорожите созданием и использованием собственных инструментов.
Ульрик Стиг Хансен — соучредитель компании Encord. Он занимается кодированием с 14 лет. Он начал свою карьеру в сфере курсов развивающихся рынков и валютных операций в JP Morgan. Он имеет степень магистра. получил степень бакалавра компьютерных наук в Имперском колледже Лондона.
Команды машинного обучения и обработки данных любого размера используют приложения Encord для совместной работы, функции автоматизации и API-интерфейсы для создания моделей, аннотирования, управления и оценки своих наборов данных. Загляните к нам здесь.
