Очень часто практик в области обработки данных случайно становится руководителем проекта. Возможно, их проектная группа слишком мала, чтобы иметь штатного менеджера проекта, или, возможно, даже при наличии такового специалисту по данным все равно придется ставить и нести ответственность за детализированные задачи, связанные с проектом более высокого уровня. веха. Например, в большой проектной группе специалист по данным может нести ответственность за задачу «разработки прогнозной модели ценообразования», которая сама состоит из более мелких задач, экспериментов, нюансов и зависимостей, которые слишком детализированы, чтобы соответствовать традиционной структуре управления проектами.
Когда приходит время действовать в качестве неофициального менеджера проекта, это обычно влечет за собой работу с несколькими движущимися частями, такими как взаимодействие с заинтересованными сторонами, установление ожиданий, понимание бизнес-ценности проекта или задачи и установление показателей успеха. По моему опыту, специалисты по данным с хорошими навыками межличностного общения обычно преуспевают в вышеперечисленном. Наоборот, один из факторов, который, по моим наблюдениям, ученые постоянно недооценивают, — это длительность задачи.
Это произойдет со всеми нами. Мы будем в восторге от проекта, когда основная заинтересованная сторона небрежно ответит: «Как вы думаете, сколько времени это займет?». И почти всегда мы недооцениваем время до завершения.
Ниже приведены два вымышленных персонажа, основанные на реальных историях, которые иллюстрируют распространенные ошибки в оценке времени.
Крис Кодер
Старшее заинтересованное лицо хотело, чтобы его коллега по науке о данных (назовем его Крис Кодер) обучил модель классификации релевантных и нерелевантных новостных статей из базы данных, купленной их компанией.
«Привет, Крис, сколько времени нужно, чтобы обучить модель распознавать релевантные и нерелевантные новости?»
«Ну, в зависимости от размера данных, мне нужно от одного до двух дней, чтобы их обработать, затем еще пару дней, чтобы настроить модель (начну с базового уровня). Исходя из этого, я могу генерировать прогнозы, чтобы основные заинтересованные стороны могли перепроверить их, и на основе этих итераций еще пара дней тонкой настройки и 1 день, чтобы задокументировать это и превратить в повторно используемый фрагмент кода».
По оценке Криса, для обучения модели потребуется около 7 дней или, возможно, 10 дней с мультипликативным коэффициентом. Однако на завершение этого конкретного проекта и получение окончательных результатов ушло пять месяцев, что вызвало большое разочарование у старшего заинтересованного лица.
Как Крис мог так неправильно оценить время, необходимое для завершения этого проекта? Так получилось, что Крис проигнорировал старую аксиому управления проектами, которая говорит нам, что работа отличается от продолжительности. Крис прикинул, сколько времени займет его работа. Он не учел тот факт, что для получения новостных данных ему потребуется доступ к таблице, которую ему могут предоставить только два человека после утверждения на инженерном совещании, которое происходит раз в квартал. Он не оценил того факта, что, как только он получил набор данных, таблицы были настолько дезорганизованы, что ему пришлось организовывать встречи с владельцами активов для объяснения. Он не оценил тот факт, что набор данных был настолько большим, что даже его визуализация заняла целый день, поэтому ему пришлось прибегнуть к помощи одного из своих рабочих «союзников», занятого дата-инженера, для его предварительной обработки. В конечном итоге он не оценил длительность зависимостей, что увеличило общее время до завершения проекта на порядок!
Элли-оценщик
Другой распространенный пример неправильной оценки длительности — это когда кого-то приглашают в проект на полпути, чтобы «помочь» коллеге, который, возможно, будет в отпуске в течение длительного времени. Или, возможно, старый проект, который нужно возродить, а команды, которая над ним работала, давно нет. Этот сценарий произошел с моей подругой Элли, которая, как известно, хорошо разбирается в управлении проектами. Вот разговор с ее менеджером.
«В прошлом году мы сделали проект по прогнозированию показов по временным рядам. Человек, который обучил модель, ушел, но теперь один из старших стейкхолдеров хочет обновить проект, включив в него новые данные. Я чувствую, что это должно занять всего один или два дня, что вы думаете?»
«Мне нужно взглянуть на проект как минимум два дня, чтобы попытаться понять шаги по обновлению данных, а затем я смогу вернуться к вам с оценкой».
Ответ Элли немного разочаровал ее менеджера, однако в долгосрочной перспективе сэкономил ей время. То, что можно было бы расценить как «трату двух дней» на попытки понять проект, дало хорошее представление о задаче. Если бы она не «потратила два дня впустую», то не заметила бы этого:
- Коду не хватало четкой документации. Она была не очень хорошо знакома с моделью, и прилагаемые презентации в формате Power Point не помогли прояснить, как воспроизвести результаты.
- Некоторые функции, казалось, были жестко закодированы, с очень небольшим объяснением того, почему они должны были быть такими.
- Обученная модель казалась специфичной для этого года, и ее нужно было переобучить, если она хотела, чтобы она была точной.
- В одной части кода говорилось, что «проверено Карлосом вручную», что означало, что другая заинтересованная сторона должна была проверить данные после обновления.
Каждый из этих шагов является ожидаемым риском и увеличивает общую продолжительность проекта (а также вероятность успеха в целом). Ни один из них не является полным блокировщиком, однако с ними нужно действовать. Четко сообщая об этом, она могла указать более точные сроки своему менеджеру, снизив ожидания.
Эти два примера показывают нам, что оценка вашей собственной работы обычно является лишь одним из элементов оценки исключенной продолжительности вашего проекта. Мы знаем, сколько времени уходит на обучение модели машинного обучения, создание графика или разработку базового приложения для браузера. Однако для оценки длительности задачи нам необходимо учитывать факторы, которые часто находятся вне нашего контроля. Вот список общих тем, ни в коем случае не исчерпывающий:
- Сколько времени потребуется, чтобы получить доступ к данным?
- Есть ли у меня необходимые разрешения? Кто те люди, которые могут предоставить мне доступ, и как быстро они могут это сделать?
- Насколько организованы данные? Есть ли словарь? Есть ли у меня доступ к владельцам активов, которые это понимают?
- Когда вы приступаете к проекту на полпути, насколько хорошо документирован проект?
- Если кто-то из вашей команды должен внести свой вклад в процесс, насколько они заняты и насколько надежны их сроки?
- Если вам нужен вклад заинтересованных сторон, то же самое.
Часто бывает полезно записывать задачи в таблицу, определяя, какие из них имеют решающее значение. Руководители проектов любят называть этот инструмент сопоставлением зависимостей. Конкретное программное обеспечение, которое вы используете, не имеет значения — разные команды будут использовать разное программное обеспечение для записи задач (или, если вы любитель стикеров, дерзайте!). Ниже приведен пример высокого уровня того, как можно рассматривать зависимости:
Составление точной карты зависимостей — сложная задача, и вам, вероятно, придется периодически обновлять ее, подстраиваясь под непредвиденные обстоятельства. С другой стороны, отсутствие карты означает недооценку продолжительности проекта. Карта должна быть видна основным заинтересованным сторонам и отражать ваши предположения о каждой задаче. Будьте уверены, что первоначально потраченное время на размышления о ваших задачах потрачено с пользой!
Вы можете быть самым быстрым специалистом по данным в мире с точки зрения написания кода и все же не уложиться в сроки, если не будете учитывать продолжительность ваших зависимостей.
Если у вас есть какие-либо другие инструменты, которые помогут вам оценить продолжительность проекта по науке о данных, пожалуйста, оставьте комментарий ниже!
NB: термины «случайный» или «неофициальный» руководитель проекта взяты из двух книг, которые я настоятельно рекомендую: Управление проектами для неофициального руководителя проекта Кэри Кагон, Сюзетт Блейкмор и Джеймса Вуда и Accidental Agile. Руководитель проекта: от нуля до героя за 7 итераций Рэя Фронхёфера и других авторов.
