Рекомендации по созданию эффективных информационных продуктов

В бесчисленных публикациях с данными вам будет предложено делать такие вещи, как «использовать облако» или «проводить эксперименты». Расплывчатость этих сообщений не помогает. На пути к успешному информационному продукту нельзя "подсказывать и обманывать". У вас должен быть правильный образ мышления. Я был разочарован, читая эти сообщения, и решил написать свой собственный, но такой, который не будет представлен как сборник советов, приемов или правил, а как руководство. Выполнение всего этого не гарантирует успеха, но они могут быть вам полезны ...

Далее следует набор вещей, которые я недавно наблюдал на встречах с клиентами, а также во время работы над проектами. Этот пост вдохновлен прекрасной статьей Мартина Гудсона,« Десять причин, по которым ваш проект данных может потерпеть неудачу » и включает в себя мои личные взгляды на многие вещи, которые я сейчас вижу в проектах данных (это одна проблема прямо здесь ... мышление с точки зрения проекты вместо продуктов.)

1. Сначала подумайте о простом, а затем, если это действительно необходимо, усложняйте

Поскольку AlphaGo в прошлом году победила одного из лучших игроков в го, искусственный интеллект (также известный как глубокое обучение) стал горячей темой. Сегодня, если вы не занимаетесь искусственным интеллектом, вы не из крутых ребят. Слишком много клиентов спрашивают меня, как они могут использовать ИИ для крутых вещей. Проблема в том, что в большинстве случаев достаточно простой модели. Не зацикливайся на этом.

2. Определите MVP своего информационного продукта и выпустите его как можно раньше

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

3. Определите целевую архитектуру и рабочую нагрузку прямо сейчас

Многие клиенты заранее спрашивают меня об оптимальном размере требуемой среды данных. Например, они хотят знать, достаточно ли 1,5 ТБ памяти для их кластера Spark, прежде чем мы даже приступим к работе над проблемой. Я понимаю, что им это нужно для составления бюджета, но мой подход повторяется. Я лучше пойму, что мне нужно, пока буду работать над проблемой. Теперь все вместе: «Все изменится».

4. Используйте правильный инструмент для решения правильной задачи

Что может быть хуже, чем жаркие споры о том, какой инструмент лучше другого? Это типично, будь то R vs. Python, SAS, Spark, Dask, Flink, Kafka, RabbitMQ, Redis, Geode, TensorFlow, Theano, Torch и так далее… Но вот загвоздка: не существует единого инструмента, который мог бы решить все проблемы. Мой ответ: всегда работайте с тем инструментом, который лучше всего решает вашу проблему. Инструменты приходят и уходят, так что не слишком увлекайтесь каким-либо одним из них. (В частности, я смотрю на вас, САС.)

5. Создавайте значимые вещи

Иногда я работаю с клиентами, которые хотят создать бессмысленные функции. Вам не нужно использовать word2vec, если вы анализируете данные датчиков! Поэтому проведите исследование пользователей, прежде чем действительно вкладывать много денег и времени в создание той или иной функции. Если это не влияет на цели продукта и не влияет на них, не создавайте его.

6. Расставьте приоритеты в проектах, оказывающих наибольшее влияние на бизнес

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

7. Измеряйте свою модель и время от времени улучшайте ее

Есть пословица: «Не меняйте работающую систему». Но если вы будете этого придерживаться, то система может сбежать от вас. У меня было взаимодействие, когда модель использовалась более трех лет, а затем клиент понял, что полученные ею результаты больше не соответствуют проблеме. Это проблема с данными. Это меняется. И это особенно проблематично, если в коде вы делаете «выбрать все». 😉

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

8. Общение + сотрудничество = 🔑

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

Вот несколько полезных статей, которые я прочитал, которые помогут мне понять, как подходить к проекту / продукту данных:

И последнее, но не менее важное, коллеги по анализу данных, скажите мне:

Какие рекомендации вы используете для обеспечения успеха проекта?

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