TL; DR; Специалисты по анализу данных обычно имеют предвзятое видение проекта и должны уделять больше внимания более широкой картине. Это серьезное препятствие для достижения высших должностей и успеха в организации. Эта статья о том, почему важно больше думать о твердом плане.
Недавно я написал сообщение Три навыка, которые понадобятся старшему специалисту по данным. Он получил огромный отклик от читателей (10 тысяч просмотров за ~ 3 дня). Это побудило меня поделиться еще одним менее известным уроком (или иногда хорошо известным, но которого избегают) исследователей данных.
Они относятся не только к науке о данных, но и могут быть полезны для программных проектов. При правильной контекстуализации это может принести пользу любой проницательной технической команде. Также следует отметить, что большинство примеров, которые я рисую, относятся к командам корпоративных аналитиков, поскольку именно там я проводил большую часть своего времени. Наконец, эти выводы в основном основаны на моем собственном опыте и у меня нет формального опыта в области управления проектами. Так что, если вы найдете более эффективные способы решения некоторых проблем, которые я поднимаю в статье, поделитесь ими! Чтобы другие могли учиться у них.
Мнения и склонности, которые я разделяю здесь, являются моими собственными и не отражают мои нынешние или предыдущие компании. Но я благодарен своим менеджерам в страховой компании QBE в Австралии за советы и наставления, которые они мне предоставили.
Специалисты по обработке данных - плохие планировщики
Хорошо! начнем с самого простого; планирование спринта. Холодная правда в том, что специалисты по данным ленивы даже планировать свой день должным образом, а тем более спринт (мне искренне жаль, что я противодействую более организованным и менее хаотичным специалистам по данным - я знаю, что вы существуете!). И изо дня в день я вижу летающие комиксы, твиты, показывающие, насколько разработчики ненавидят планирование / JIRA и т. Д. За каждой шуткой скрывается горькая правда!
Но это же не шутка! Если ваша команда не умеет планировать, то вы можете позволить проекту плыть по течению, он не закончится хорошо. Если вы все же сбежали, скорее всего, это потому, что кто-то другой планировал за вас. И если вы действительно уверены, что никто не делал так много панорамирования, и это все равно получилось ... что ж, второго раза не произойдет!
Королевство далеко-далеко ...
Вот как многие специалисты по анализу данных думают, что их проект работает.
Не говоря много, позвольте мне рассказать вам историю.
Кислый укус из моего личного опыта
Чтобы подчеркнуть суть дела, я собираюсь использовать свой личный опыт. Несколько лет назад я работал над интересным проектом машинного обучения. Я действительно гордился этим, и каждый раз, когда мой коллега спрашивал о моем проекте, я становился таким увлеченным и объяснил от спринта к спринту, что я сделал.
Через несколько дней мой менеджер заглянул на одну из сессий по планированию спринта, просто для быстрой проверки. И, о боже, не стал ли это быстро превратиться в одну из моих самых запоминающихся встреч. Я уверенно объяснял, что мы сделали и что планируем достичь. И мой менеджер вмешивается и спрашивает: «Чего мы собираемся достичь в итоге?». Я не мог придумать ничего, кроме как заполнить этот неловкий момент случайным лепетом и заиканием.
Момент лампочки
Именно тогда у меня было прозрение. Вот несколько мыслей, извлеченных из этого поучительного момента!
Мы с менеджером смотрели на проект с совершенно противоположных сторон. Это не обязательно должен быть менеджер, это может быть владелец продукта или конечный покупатель. Вот что произошло на самом деле.
Почему ваш проект заблудился?
Да, планирование заключается в том, чтобы избегать неловкого молчания (щебетание сверчков на заднем плане) на ваших встречах с заинтересованными сторонами. Но почему мы не можем перейти от А к Б спринт за спринтом? Вот несколько причин из личного опыта!
- Смещение объема. Заинтересованные стороны сказали: «Мне нравится работа, которую вы проделали над функцией X, можете ли вы сделать то же самое для A, B, C)». Без дальнейших размышлений или консультаций вы соглашаетесь работать над этим. Уже слишком поздно, когда вы понимаете, что у вас нет времени работать над основной функцией, которую вы планировали реализовать.
- Технический долг. Вы добавляете слишком много излишней уверенности в свою тарелку и беретесь за задачу (например, новую функцию для вашей модели, больше данных для обучения), которая действительно должна быть в очереди.
- Отсутствие связи. Я вижу, как разработчики говорят: «Если я выполняю свою работу вовремя, зачем мне приходить на встречи». Ненавижу ломать его, но все меняется. «Работа», которую вы считали важной в начале проекта, сейчас может не быть приоритетом. Вы являетесь частью команды, есть и другие, которые зависят от вашей работы, и вы обязаны делиться своими обновлениями.
- Внешние факторы. Ваш организационный аппетит может измениться. Ваша компания может пересмотреть цели, или ваши заинтересованные стороны могут увидеть новую технологию, которую необходимо включить в качестве функции, и т. Д.
Здесь я рассмотрю два урока. Один обращается к тому, как избежать первых трех причин. Второй касается последнего.
Урок 1 для хорошего плана: имейте постоянную обратную связь
Самое ценное, что могут предложить заинтересованные стороны, - это свежий взгляд.
Заинтересованные стороны не заботятся о том, как вы туда попали, а о том, куда вы собираетесь
Чтобы избежать дорогостоящих ошибок, связанных с отказом от функций продукта или, что еще хуже, от проектов в целом, вам нужно хорошо планировать.
Обзор спринта спешит на помощь
Я не могу не подчеркнуть важность наличия обратной связи на протяжении жизненного цикла вашего проекта. К счастью, если вы следуете гибкому рабочему процессу, такому как scrum-фреймворк, вам не о чем беспокоиться. Для этого и нужен обзор спринта. scrum.org описывает обзор спринта как сеанс, на котором:
Скрам-команда и заинтересованные стороны анализируют, что было достигнуто в ходе спринта, что изменилось в их среде, и совместно обсуждают, что делать дальше.
Есть причина, по которой обзор спринта явно присутствует во фреймворке. Если у вас нет этого цикла обратной связи, вы получите проект, который никто не ценит.
Недооцененный обзор спринта
Я видел, как некоторые команды сбрасывают со счетов ценность обзоров спринтов, оправдываясь вроде «нам нечего показать на этой неделе, так что давайте пропустим». Это первая волокита! Если вам нечего показать после двух недель усилий, это настораживает. Вот несколько причин, по которым это происходит.
- Вы делаете смелые предположения, что то, над чем вы работаете, будет «без сомнения» принято заинтересованными сторонами.
- Вы недооценили требуемые усилия, поэтому работа, которая, как вы думали, займет 1 спринт, на самом деле занимает 2
- Честно говоря, тебе нечего демонстрировать. Например, вы можете сосредоточиться на улучшении модели машинного обучения в спринте. В этом случае, пока модель не обучена и не оценена, показывать особо нечего.
Здесь важно знать, почему вы пропускаете обзор спринта! Это связано с навыком критического мышления из моей статьи: Три навыка, которые вам понадобятся как старшему специалисту по данным.
Планирует не владелец продукта?
И да и нет…
- Определения ролей размываются по мере роста
Да, можно так сказать. Но по мере продвижения по лестнице вы увидите, что определения этих ролей становятся нечеткими и менее определенными. Ответственность и обязанности одной роли перетекают в другую. Таким образом, наступает время, когда вам придется носить множество шляп как разработчику, владельцу продукта и т. Д. В этом случае планирование становится совместным усилием. Например, владелец продукта может выполнять 60%, а вы, как старший / ведущий разработчик, - 40% планирования.
- Усилия, необходимые для продуктов машинного обучения, менее понятны
Еще один факт, затрудняющий разделение обязанностей, заключается в том, что машинное обучение - менее определенная область по сравнению с разработкой программного обеспечения. Например, вы можете быть уверены в возможности использования функции, в которой вы нажимаете кнопку и экспортируете PDF-файл. Но вы будете более скептически настроены, если кто-то скажет: «Вот некоторые данные, сделайте меня моделью машинного обучения».
- Роль специалиста по данным в обзорах спринтов
Ситуацию усугубляет то, что иногда будут владельцы продуктов (практически не имеющие опыта машинного обучения), которые думают, что разработка модели машинного обучения для некоторых произвольных данных является четко определенной задачей. Затем вы (специалисты по данным) должны вмешиваться в обзоры спринтов и объяснять, почему это не так.
- Общение заразительно
Поощрение такого рода двустороннего общения в обзорах спринтов имеет еще одно преимущество. Это заставляет специалистов по анализу данных избавиться от своего интровертного мышления и активно участвовать в этих сессиях, чтобы к концу достичь более реалистичного и плодотворного результата. Тогда они продемонстрируют те же навыки, что позволит им быть более прозрачными в том, что они делают.
Здесь вы можете увидеть, как наличие надежной обратной связи и участие технических участников в обзорах спринтов может помочь избежать смещения объема работ, несвоевременных обязательств по техническому долгу и вялых (да, это слово) специалистов по данным.
Следующим шагом будет не привнесение свежей точки зрения, а изменение вашей собственной точки зрения.
Урок 2: Преуспевайте в многоуровневом мышлении
Будь как лук ...
Цитируя один из моих любимых детских фильмов «Шрек»,
У лука есть прослойки. У огров есть слои. У лука есть прослойки. Ты понял? У нас обоих есть слои.
Почему я цитирую фильм, который не может быть дальше от реальности? Потому что, чтобы занять руководящие должности, вам нужно выйти за рамки технических сложностей. Вы также должны начать концентрироваться на более широкой картине. Как вы увидите, единой картины в целом тоже нет. Итак, это гарантирует необходимость многослойного видения… как лук.
Множество разных целей в организации
Вот рисунок, изображающий различные цели / задачи, которые существуют, когда вы работаете над проектом. Помните, что все они могут формировать путь, по которому вам нужно двигаться.
Тактические и стратегические цели
Эти вышеупомянутые цели попадают в одну из этих категорий. Стратегические цели будут долгосрочными (более 1 года), а тактические цели - краткосрочными целями, которые помогут вам достичь этих стратегических целей.
Почему важно мыслить многоуровнево?
Давайте теперь посмотрим, почему так важно придерживаться этого образа мышления.
- Передайте привет мировоззрению MVP
Разрабатывая продукт для науки о данных, вы начинаете с MVP; минимально жизнеспособный продукт. Затем на пути к переходу от MVP к полноценному продукту, зная цели на разных уровнях, вы оцените минимум усилий, чтобы довести продукт до заинтересованных сторон. Я не имею в виду создание частично функциональной информационной панели с кнопкой самоуничтожения. Я имею в виду только разработку необходимых функций.
- Предположим следующий сценарий
Корпорации платят большие деньги консультационным компаниям за разработку долгосрочных целей и их регулярный пересмотр (например, ежегодно). Допустим, вы работаете в страховой компании X, а X ставит перед собой высокую цель - внедрить машинное обучение во все операции с урегулированием убытков. Спустя год компания понимает, что даже с некоторыми решениями машинного обучения не наблюдается роста эффективности работы специалистов по урегулированию убытков.
Покопавшись, они понимают, что все еще используют файлы Excel и Word для обмена данными между множеством вовлеченных сторон. С помощью панели управления и базы данных эти процессы могут быть стандартизированы и иметь единый источник данных. Теперь стратегическая цель снижается с ML до «модернизации всех операций по урегулированию убытков».
- Это не хорошо
Как вы думаете, что будет с тем крутым проектом машинного обучения, над которым вы работали? Финансирование уйдет, и вы и ваша команда скоро будете заняты чем-то другим. Итак, если вы человек, у которого было многоуровневое понимание, вот как вы с этим справитесь.
- Во-первых, вы бы ожидали этого намного раньше (да, те общие собрания, которые вы выполняете одновременно, очень важны) и составили планы на случай непредвиденных обстоятельств, если все пойдет так.
- Во-вторых, ваш выход из проекта A будет намного более плавным - у вас есть несколько спринтов, чтобы подвести итог. Вы создадите простое сквозное решение (возможно, вычеркнете обещанную вами продвинутую модель машинного обучения и вернетесь к набору бизнес-правил - до тех пор, пока вы, конечно, не сможете вернуться к этому варианту использования). Поскольку вы сделали только минимально необходимое, пробелы и дыры, которые вам нужно исправить, будут намного менее серьезными по сравнению с тем, чтобы взять слишком много вещей и не выполнить их.
Как включить многоуровневое мышление в планирование спринта
Первое, что нужно понять, это то, что те цели, которые выходят за рамки вашей весны, не подлежат пересмотру, когда пришло время придумывать новые. Они должны быть активной силой, которая руководит вашим проектом. Поэтому важно думать о них при планировании спринта. Как ты можешь это сделать?
- Как должно выглядеть планирование спринта?
Я не знаю, какой способ лучше, но при планировании я использовал следующий метод.
- Подумайте о целях спринта (5 минут)
- Подумайте - совпадают ли цели спринта с нашими за 3 месяца (5 минут)
- Подумайте - согласуются ли цели спринта с нашими ежегодными командными целями / стратегическим видением (5 минут)
- При необходимости пересмотрите цели спринта
- Разбейте цели спринта на задачи и подзадачи
- Назначьте их участникам и оцените усилия
Таким образом, это занимает всего 15 минут каждые две недели, но имеет огромное значение. Если бы вы использовали такое мышление в своих планах на спринт, у вас могли бы быть разные типы занятий по планированию. Например,
- Планирование спринта (каждые 2 недели)
- Расширенное планирование спринта (каждые 3 месяца)
- Стратегические встречи (6 месяцев)
Повторюсь, я убедился, что это хорошо работает на собственном опыте. Но если есть более устоявшиеся / проверенные способы сделать эту работу, не стесняйтесь их использовать.
Вывод
Это все, что я хотел сказать. В общем, вот основные выводы.
- Планирования спринта недостаточно, чтобы эффективно добраться из пункта А в пункт Б.
- Не выбрасывайте обзоры спринтов. Постоянно делитесь обновлениями с заинтересованными сторонами и вовлекайте специалистов по данным в эти обсуждения.
- Примите многоуровневое мышление. Планируя спринт, выделите несколько минут, чтобы подумать о согласовании целей спринта с общей картиной.
Если вам нравятся мои рассказы о науке о данных и машинном обучении, подумайте о том, чтобы стать участником!
