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

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

Если вы хотите поддержать это, поделитесь этим в Twitter, LinkedIn или Facebook.

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

1 Каскад ошибок в данных, смотрите, как ваши данные или ваш проект данных умирает

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

Общая идея очень проста: «интеллектуальные продукты, продукты, использующие (аналитические) данные, полагаются на длинную цепочку шагов. Сбор данных, эмиссия, прием, множество преобразований, возможно обучение и конфигурации производных моделей и т. Д. это настоящая трубка в том смысле, что качество остается неизменным. Ошибки каскадируются на более поздние стадии конвейера. Они могут прыгнуть на 1 или 2, но они спускаются каскадом вниз. В результате, отказ от обеспечения качества на уровне программного обеспечения приводит к множеству проблем с качеством на последних этапах - этапах реальной ценности ».

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

Это показывает мне, например, что вам нужно хорошо подумать, прежде чем внедрять продукты с большим объемом данных в отдел аналитики / технический отдел, который имеет низкий стандарт данных. Потому что, что бы вы ни делали, вы должны рассчитывать на то, что любой информационный продукт будет работать на 60-80% -ное качество, что бы вы ни делали. Это совершенно нормально, если вы хотите создать функцию PYMK. Но это не так, если вы хотите предварительно отсортировать электронные письма для службы поддержки клиентов. Они, вероятно, в конечном итоге будут проводить больше времени, чем раньше.

Ресурсы

2 переключение контекста против фокусировки

По моему опыту, группы данных были брошены в место, где они заботятся о множестве различных «продуктов», некоторых вещах в области науки о данных, возможно, о некоторых реальных приложениях, хранилище данных, графическом интерфейсе пользователя для отчетности, некоторых специальных отчетах и ​​т. Д.

Это, в свою очередь, приводит к тому, что они часто делают несколько разных вещей в рамках одного рабочего шага / SCRUM-спринта, который затем растягивает эти вещи немного дольше. Мне очень нравится визуальное объяснение Хенрика Книберга, почему это действительно плохая идея.

Посмотрите видео, но я повторю его аргумент, потому что считаю его важным. Возьмите свои задачи, такие как проведение специального анализа, затем его обновление и включение изменений, создание прототипа модели машинного обучения и т. Д. Все это состоит из шагов 1–2–3, пока не будет достигнута реальная ценность для бизнеса. Теперь у нас есть два варианта работы над несколькими вещами:

  • Вариант 1 (переключение контекста). Параллельно выполните шаги 1 всех задач вместе, затем шаги 2, затем шаги 3.
  • Вариант 2 (One Piece Flow): последовательно, сначала выполните первую задачу, затем вторую, затем третью…

В чем разница?

  1. Большинство групп данных используют вариант 1, несколько «тем» в рамках одного спринта / квартала.
  2. Во втором примере время выхода на рынок в 2–3 раза больше.
  3. Вариант 1 завершает все элементы позже (кроме 3, который выполняется одновременно)

Плохая новость: в реальном мире есть переключение контекста. Вариант 2 имеет только 2 переключателя контекста, тогда как вариант 1 имеет их много (каждый день, в рамках ежедневных встреч, в уточнениях,…). Таким образом, вариант 1 на самом деле занимает больше времени, чем вариант 2.

Я настоятельно рекомендую вам взглянуть на свой рабочий процесс и количество переключений контекста, которые вы делаете в течение каждого дня разработчика, дня / спринта / квартала каждой команды,…

Ресурсы

3. Прекратите исправлять (некоторые) ошибки данных

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

Только переключение задач + фактическое исправление вещей, которое всегда занимает больше времени, чем предполагалось, отнимает время у других вещей. От других видов деятельности, создающих ценность.

Мне нравится схема Брэндона Чуса, изображенная выше, потому что она проста и на самом деле довольно применима в большинстве сценариев хранилищ данных / машинного обучения / анализа данных. Важная часть: если, например, какой-то источник данных неверен и влияет на 5% или менее ваших конечных пользователей, тогда вы ничего не делаете! Поместите его в свой бэклог и держите там, расставьте приоритеты, как и любую другую функцию.

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

Ресурсы

P.S .: Я делюсь важными вещами, а не самыми свежими. Я делюсь книгами, исследовательскими работами и инструментами. Я пытаюсь дать простой способ понять все эти вещи. Но я склонен к самоуверенности. Но вы всегда можете нажать кнопку отказа от подписки!