Все больше и больше стартапов ищут специалистов по обработке данных, которые могут работать автономно и извлекать из данных ценную информацию. В принципе, это звучит здорово: инженеры и дизайнеры создают продукт, а специалисты по обработке данных обрабатывают числа, чтобы получить представление. На практике найти этих специалистов по данным и дать им возможность работать продуктивно — очень непростая задача
Прежде чем углубляться дальше, полезно отметить несколько тенденций в развитии данных и продуктов, которые проявились за последнее десятилетие:
Такие компании, как Google, Amazon и Netflix, показали, что правильное хранение и анализ данных может дать огромные конкурентные преимущества.
Теперь стартапы могут использовать и собирать огромные объемы данных об использовании. Мобильные устройства распространены повсеместно, а приложения постоянно отправляют данные. Инфраструктура больших данных стала зрелой, а это означает, что хранение и анализ крупномасштабных данных становятся доступными.
Широко принятая философия бережливого стартапа сместила разработку продуктов, чтобы в большей степени ориентироваться на данные. Стартапы теперь сталкиваются с проблемами определения ключевых показателей эффективности (KPI), разработки и внедрения A / B-тестов, понимания конверсии воронки роста и вовлеченности, построения моделей машинного обучения и т. Д.
Из-за этих тенденций стартапы стремятся развивать собственные возможности в области анализа данных. К сожалению, у многих из них есть неправильные представления о том, как создать такую команду. Позвольте мне описать три популярных заблуждения.
Заблуждение №1: ставить под угрозу инженерную планку статистических навыков — это нормально.
Чтобы специалисты по данным могли работать продуктивно и независимо, они должны уметь ориентироваться во всем техническом стеке и эффективно работать с существующими системами для извлечения релевантных данных. Единственное исключение — если стартап уже создал инфраструктуру данных. Но на самом деле очень немногие стартапы имеют свою инфраструктуру до создания команды по анализу данных. В этих случаях команде по обработке и анализу данных без сильных инженерных навыков или инженерной поддержки будет сложно выполнять свою работу. В лучшем случае они создадут не оптимальное решение, которое будет переписано другой командой для производства.
Чтобы проиллюстрировать это, возьмем пример построения панели KPI в Codecademy. Перед визуализацией данных в d3 мне пришлось извлечь и присоединить (а) данные пользователя из MongoDB, (б) данные когорты из Redis и (в) данные просмотров страниц из Google Analytics. Сам по себе сбор данных был бы практически невозможен без инженерного образования, не говоря уже о том, чтобы сделать панель мониторинга в реальном времени, модульную и многоразовую.
Заблуждение №2: это нормально, если вы нарушите шкалу статистики для инженерных навыков.
Правильная интерпретация данных — непростая задача, а неверно интерпретированные данные могут нанести больший ущерб, чем данные, которые вообще не интерпретируются (см. «Ошибочная статистика»). Создание полезных моделей машинного обучения (ML) сложнее, чем думает большинство людей. Популярное, но ошибочное мнение гласит, что проблемы машинного обучения можно решить либо путем применения некоторого алгоритма черного ящика (он же магия), либо путем найма стажеров, которые являются аспирантами. На практике при решении таких проблем принимаются сотни решений и компромиссов, и знание того, какие решения принимать, требует большого опыта. (Я расскажу об этом подробнее в следующем посте под названием «Машинное обучение сделано неправильно».) Для данной проблемы машинного обучения существуют десятки, если не сотни способов ее решения. Каждое решение делает разные предположения, и не очевидно, как ориентироваться и определять, какие допущения являются разумными и какую модель следует использовать. Некоторые могут возразить: почему бы просто не попробовать все разные подходы, провести перекрестную проверку и посмотреть, какой из них работает лучше всего? На самом деле у вас никогда не будет на это пропускной способности. Сильный специалист по данным может сразу же создать разумную модель, в то время как слабый может потратить месяцы на оптимизацию неверной модели, не зная, в чем проблема.
Заблуждение № 3: нанимать специалистов по данным, у которых отсутствует продуктовое мышление, — это нормально.
Представьте, что вы просите кого-то, кто не имеет целостного представления о продукте, оптимизировать ключевые показатели эффективности вашего бизнеса. Они могут преждевременно оптимизировать воронку регистрации, прежде чем удостовериться, что продукт имеет разумное удержание, что приведет к увеличению количества не удерживаемых пользователей. Некоторые думают, что разработка продукта на основе данных — это локальная оптимизация. Эта критика верна только в том случае, если те, кто руководит разработкой продукта с помощью данных, не могут думать о продукте целостным образом.
Подводя итог, можно сказать, что продуктивной команде специалистов по обработке и анализу данных требуются специалисты по данным, обладающие сильными знаниями в области инженерии, статистики и продуктового мышления. Это сложно. И становится еще труднее найти первого сотрудника в области науки о данных, который возглавит усилия по обработке данных в стартапе. Для стартапов, которые не могут позволить себе роскошь ждать и нанимать этих редких специалистов по данным, важно знать о сделанных компромиссах, особенно в плане найма. Прежде чем команда данных станет достаточно сильной во всех трех областях, убедитесь, что у них есть сильная поддержка навыков, которых им не хватает, и не ожидайте, что они будут работать автономно.
