За последние 10 с лишним лет мы наблюдали за сотнями проектов по работе с данными и выявили закономерности, которые коррелируют с успехом.
Написано со Стивеном Петтинато.
Наука о данных парадоксальна: она названа самой сексуальной профессией 21 века, но при этом показывает уровень провала проектов 70–85%. И что удивительно, спрос на специалистов по работе с данными по-прежнему намного превышает предложение.
Такое сочетание высокого спроса и большого количества отказов противоречит здравому смыслу. Почему компании продолжают инвестировать в ресурсы данных? Компании продолжают инвестировать, потому что они должны. По данным McKinsey Research, разрыв между лидерами и отстающими в использовании данных увеличивается, и раскрывается лишь малая часть потенциальной ценности. Разочарование растет, когда компании инвестируют в команды обработки данных и не чувствуют, что получают хорошую отдачу.
Специалисты по данным тоже разочарованы. Отличительной чертой людей, занимающихся данными, является их сильное любопытство. Мы хотим знать, почему вещи работают на более глубоком уровне, чем большинство. Мы также хотим создавать продукты и давать рекомендации, которые оказывают влияние. Это душераздирающе, когда мы вкладываем большие средства в проект только для того, чтобы увидеть, как он не реализует весь свой потенциал.
Этот пост посвящен факторам, которые вы, специалист по данным, можете контролировать во время проекта. За последние 10 с лишним лет мы наблюдали за сотнями проектов по работе с данными и выявили закономерности, которые коррелируют с успешными результатами. И большинство из этих шаблонов существуют еще до того, как вы начинаете!
В первой части этого поста перечислены десять основных проблем, которые приводят к провалу еще до начала проекта. Во второй части представлен общий шаблон, который вы можете использовать.
Драйверы отказов
Проблемы, которые приводят к 90%+ отказу:
- Вы не можете ответить, почему мы делаем эту работу. И «потому что так говорит [вставьте важную заинтересованную сторону]» — не лучший ответ. Очень редко конкретная просьба от заинтересованной стороны является правильной проблемой для решения.
- Вы не можете ответить, почему эта работа имеет смысл, или обсудить альтернативную стоимость вашего времени. Чаще всего текущее «достаточно хорошее» решение остается «достаточно хорошим», даже если оно раздражение для команды. Помните, что «да» вашему времени — это также «нет» другим возможностям.
- Вы не понимаете, как измеряете успех. Уточните.
- Результаты нечеткие, нечеткие или нечеткие. Я вижу в этом признак того, что вы и заинтересованные стороны не согласны друг с другом.
- Ваши заинтересованные стороны не могут ответить ни на один из приведенных выше вопросов. Эта ситуация является еще одним важным признаком того, что вы и ваши заинтересованные стороны не согласны. И вы можете быть уверены, что ваше руководство разговаривает с вашими заинтересованными сторонами.
Проблемы, которые приводят к 70%+ отказов:
- Вехи не встречаются редко. Разделение проекта на небольшие части полезно во многих отношениях.
- Ваш раздел для заинтересованных сторон выглядит так же, как страница компании о нас. Слишком много заинтересованных сторон — это беспорядок. Слишком мало заинтересованных сторон неэффективны. Найдите то, что лучше всего подходит для вашей корпоративной культуры, и не бойтесь со временем сокращать.
- Вы не обсуждаете завершение проекта. Задокументируйте завершение, чтобы ваша команда могла учесть обслуживание при планировании проекта. Почему этот шаг приводит к провалу? Невероятно, как быстро вы можете перегрузить себя как организацию, если вы не четко определили приоритеты и то, на что вы тратите свое время.
- Вы поделились со мной набором слайдов. Хорошо, я признаю, что это дешевая попытка. Я успешно реализовал крупные проекты, которые начинались как слайд-презентация. А культура слайдов настолько глубоко укоренилась в корпоративной культуре некоторых компаний, что у вас просто нет выбора. Тем не менее, вы все равно можете подробно расписать свой план и использовать слайды для подведения итогов презентации.
- Ваш дизайн-документ указывает на то, что других внутренних ресурсов мало или совсем нет. Я скептически отношусь к представлению проекта, который мало зависит от текущей архитектуры и систем. Это предупреждающий знак о том, что вы дублируете работу или не получили достаточно отзывов о своем дизайне. Если система заказная, укажите, почему.
Вот шаблон проекта, который помогает решить вышеуказанные проблемы. Этот шаблон хорошо подходит для различных отраслей и составов команд, поскольку он фокусируется на основных принципах успешного проекта. Мышление на основе первых принципов, иногда называемое рассуждением на основе первых принципов, означает разбиение проблемы на ее фундаментальные компоненты и построение на их основе. Такой подход делает сложные проблемы более доступными и стимулирует творчество.
Шаблон проекта
Этот шаблон дизайна (ссылка на Github) поможет вам добиться максимального успеха в ваших проектах. Ценность этого шаблона заключается в том, что вы проходите через процесс, собираете отзывы, исследуете решения и корректируете их по мере обучения.
Предостережение. Будьте осторожны, чтобы не спутать заполненный документ с эффективным процессом.
Советы руководителя проекта:
- Будьте гибкими и корректируйте шаблон по мере необходимости. Этот шаблон является отправной точкой и руководством. Это не предписывающее направление.
- Не все отзывы ценны. Вы можете многому научиться из некоторых дискуссий. А иногда ничего не выигрываешь. Однако вы никогда не сможете узнать меньше, собирая информацию.
- Работайте над дизайном в команде. Хотя ваша работа как руководителя проекта состоит в том, чтобы владеть общей структурой и голосом, это не ваша работа — писать все самостоятельно. Вовлеките свою команду, назначив право собственности на разделы.
- Этот документ должен стоять сам по себе. Приятным преимуществом является то, что это помогает при адаптации, знакомстве с новыми заинтересованными сторонами и обзорах проектов.
Советы лидерам:
- Попросите вашу команду провести вас по документу после того, как вы внимательно его прочитаете. И не используйте слайды.
- Избегайте постановки OKR и целей, которые сосредоточены на заполнении этого документа. Существует тонкая грань между стимулированием вашей команды к сбору отзывов и продумыванию решений и вашей командой, заполняющей форму, чтобы поставить галочку.
- Предоставьте своей команде как можно больше контекста заранее. Невероятно демотивирует группа, которая неделями работает над дизайном только для того, чтобы услышать, что они пошли в совершенно другом направлении, чем вы ожидали. Это ваша вина, когда это происходит, поэтому, когда это происходит, признайтесь в этом и предлагайте лучшие ожидания.
- Стимулируйте свою команду обновлять этот документ на протяжении всего проекта. Кроме того, если позволяет ваша организационная культура, поощряйте свою команду делать проекты доступными для обнаружения, чтобы другие могли развивать их работу.
Постановка задачи
Этот раздел отвечает на вопрос: «Зачем мы делаем эту работу?» Поначалу мыслите расширенно, а не упрощенно. Например, задайте такие вопросы, как «В идеальном мире, где существуют эти данные и у вас есть отличный прогноз, что бы вы сделали?» Очень редко конкретная просьба от заинтересованной стороны является правильной проблемой для решения. Советы:
- Если вы не понимаете, зачем делаете эту работу, не делайте этого.
- «Гораздо лучше приблизительный ответ на правильный вопрос, который часто бывает расплывчатым, чем точный ответ на неправильный вопрос, который всегда можно уточнить». — Джон Тьюки
Экономическое обоснование и текущее состояние
Почему этот проект важен? Как решается эта проблема сегодня? Начало мысли:
- Какие бизнес-показатели улучшаются при выполнении этой работы? Как этот проект согласуется с более крупными целями компании?
- Что произойдет, если мы не сделаем эту работу? Чаще всего текущее «достаточно хорошее» решение остается «достаточно хорошим», даже если это раздражает команду. Помните, что «да» вашему времени — это также «нет» другим возможностям.
Показатели успеха
Как узнать, что проект успешен? Получите конкретику. Начало мысли:
- Будет ли это «увеличение коэффициента конверсии на 2%» или какое-то значимое изменение бизнес-показателя?
- Это серийная модель с минимальным процентом времени безотказной работы?
- Можете ли вы провести эксперимент, такой как тест AB? Какие еще показатели важны?
Извлеченные уроки
Чему вы научились на последнем этапе того же проекта? Или что вы узнали из предыдущего похожего проекта?
Требования
Каковы основные требования? Работайте с заинтересованными сторонами и придумайте ~ 3–5 пунктов, таких как:
- Создайте модель, которая предсказывает XYZ.
- Результаты моделирования должны быть доступны в хранилище данных и периодически обновляться.
- Владельцы бизнеса должны понимать, как запрашивать и использовать эти результаты.
Результаты
Каковы окончательные результаты? Работайте с заинтересованными сторонами над получением результатов, используя приведенные выше требования в качестве примеров, например:
- Презентация, объясняющая выходные данные модели, важность функций, исследовательские визуальные эффекты и рекомендуемые следующие шаги.
- Определенное расположение базы данных для результатов модели с документацией по частоте обновления данных.
- Обучение владельцев бизнеса тому, как запрашивать результаты и словарь данных.
Советы:
- Если вы не понимаете, что такое цели высокого уровня, продолжайте повторять. Часто высокоуровневые цели слишком высокоуровневы, и мы, как специалисты по данным, должны уточнить и сформулировать их, и это здорово, потому что мы владеем проектом и направляем его.
- Не начинайте проект без хотя бы одного четко определенного и согласованного результата с установленным сроком выполнения.
Расстановка приоритетов
Работайте со своей организацией в целом, чтобы оценить приоритет этого проекта по сравнению с другими проектами.
Ваша организация может сказать, что этот проект не стоит делать прямо сейчас или даже не стоит делать вообще. Задокументируйте это решение здесь и обсудите его с заинтересованными сторонами. Приоритеты могут меняться, и можно изменить дизайн или изменить приоритеты проекта на более поздний срок. Что не имеет отношения к этому решению о приоритетах, так это время запроса. Будьте осторожны с давлением со стороны заинтересованных сторон, потому что кто-то запросил что-то x месяцев назад.
Заинтересованные стороны
Кто является заинтересованными сторонами проекта? Перечислите имена и роли. Советы:
- Никакая разработка не должна начинаться до тех пор, пока область не будет окончательно определена. И будьте осторожны с расползанием масштаба во время проекта. Ничего страшного, если цель изменится, и мы подстроимся. Что ненормально, так это то, что существенное изменение масштаба не обсуждается и не согласовывается.
- Слишком много заинтересованных сторон — это беспорядок. Слишком мало заинтересованных сторон неэффективны. Найдите то, что лучше всего подходит для вашей корпоративной культуры, и не бойтесь со временем сокращать.
- Быть гибким. Вы узнаете, когда будете готовы начать; обратная связь помогает усовершенствовать дизайн и подход и позволяет людям инвестировать в результаты.
Этика
Ваш проект приносит вред? Начало мыслей:
- Может ли информационный продукт нанести вред пользователям или организации? Если да, то как можно снизить эти риски?
- Как вы собираете, храните и сохраняете пользовательские данные? Соответствует ли ваша система законам о данных, таким как GDPR и CCPA?
- Предвзяты ли результаты вашей модели и анализы по отношению к конкретным демографическим данным?
- Насколько прозрачна логика принятия решений в системе?
Архитектура системы
Как это будет выглядеть в конце? Будьте конкретными — диаграммы, изображения или рукописный дизайн, макеты панели инструментов и т. д. В идеале вы также можете ссылаться на уже существующие ресурсы.
Входные и выходные данные
Какие входные и выходные данные все? Именно где. Каталоги, форматы, schema.tablename и т. д.
Использование продукта
Как будет использоваться этот продукт данных? С какими системами и командами этот информационный продукт будет взаимодействовать на детальном уровне? Быть конкретной. Например:
- Данные перетекают из этой системы в X и Y и влияют на решение Z.
- Данные поступают в G и используются для H, K и J.
Algorithm/Mocks/Report
Переименуйте этот заголовок в соответствии с проектом. Эта часть является чем-то вроде сумки для захвата и зависит от проблемы. Начало мыслей:
ML модели
- Заманчиво потратить слишком много времени на это, поэтому эта документация жизненно важна, чтобы установить некоторые ограничения.
- Предлагаемый подход будет представлять собой итеративный подход, такой как «создание X и Y, обзор с командой и оценка на основе целевой метрики Z, если целевая метрика > запуск T%, в противном случае принять решение о следующих шагах».
Информационная панель или отчет
- Макеты необходимы, чтобы решить, соответствует ли это решение требованиям. Вам необходимо обсудить их с заинтересованными сторонами.
- Вместо конкретного макета итеративный подход заключается в создании X и Y, рассмотрении с командой, а затем принятии решения о следующих шагах.
- Какие расчеты/агрегации необходимы? Иногда это очевидно в макете.
Угловые шкафы
- Задокументируйте любые странные или существенные угловые случаи.
- Командный обзор важен, так как у каждого есть свой любимый уголок.
Вехи
Что вы доставляете и когда? Разделение проекта на небольшие части полезно во многих отношениях:
- Подробные тикеты с четкими пунктами, которые необходимо сделать, помогают сохранять концентрацию.
- Сообщайте о прогрессе более широкому кругу заинтересованных сторон.
- Установите ограждения, чтобы не сбиться с пути.
- Хорошо инкрементальны и допускают итеративный подход к проекту.
- Быть гибким. Слишком много деталей в заявке влечет за собой слишком много времени, затрачиваемого на ее написание; слишком мало делает билет расплывчатым и делает неясным завершение.
Закрытие
Чем заканчивается этот проект? Задокументируйте завершение, чтобы ваша команда могла учесть обслуживание при планировании проекта. Начало мысли:
- Некоторым проектам для продолжения работы требуется техническое обслуживание.
- Некоторые проекты могут подстегнуть другой проект.
- Некоторые проекты выполняются с результатом.
- Некоторые проекты передаются другим командам.
Первоначально опубликовано на https://www.jasongilbertson.com 14 марта 2022 г.
