Мы не команда разработчиков программного обеспечения

Как выглядит команда Data Science? По сути, в EagleView основной функцией является реализация масштабируемых алгоритмов, часто основанных на машинном обучении и глубоком обучении, которые могут применяться к изображениям временных рядов (и высокого разрешения) размером в педабайты. Эти алгоритмы не только улучшают унаследованные возможности, но и создают новые продукты. Но что нам нужно, чтобы это произошло? Как создать команду для исследования, разработки, развертывания, обновления и масштабирования новых подтверждений концептуальных идей? Как нам развивать таланты и способности, сводя к минимуму выгорание? Как мы отслеживаем этот рост с точки зрения производимых продуктов и приобретенных навыков? Я все еще прорабатываю детали, но несколько идей были согласованы с командой.

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

(1) Мы не команда разработчиков программного обеспечения. Но мы создаем программное обеспечение.

(2) Мы не ученые-исследователи. Но мы проводим массу исследований.

(3) Формально мы даже не занимаемся данными. Мы - академики прошлых лет и разработчики программного обеспечения с сертификатами AWS.

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

Мы не являемся командой разработчиков программного обеспечения. Как выглядит команда с разным набором навыков, разрабатывающая модели машинного обучения, которые являются постоянными, управляемыми по версиям и приводят к масштабируемым продуктам? Репозиторий кода. Репозиторий кода. Репозитории кода. Репозитории кода, указывающие на веса модели, сохраненные в сегменты s3; репозитории кода, указывающие на эталонные наборы данных обучения; репозитории кода, которые представляют собой не что иное, как файлы README.md, документирующие статусы и инструкции использования командной строки python. И да, код тоже есть, но у нас он несколько запутан и больше похож на хаотичную игровую площадку (зарегистрируйтесь почаще! Получите зеленые квадраты производительности на GitHub!). Мы обнаружили, что должно быть два репозитория: беспорядочная «песочница» и серьезное репозиторий для развертывания, которое хорошо работает с Cloud Ops.

Еще нам нужны jira (к сожалению?) И гибкое управление проектами. Я испортил 6 способов планирования спринта за последние 3 месяца. Несомненно, самый удачный подход (который предполагает наименьшее количество обид и наибольшее участие) - это создание общего Evernote в Slack с основными владельцами / менеджерами проектов в утро планирования спринта. Владельцы записывают свои истории / цели спринта в бюллетень. Эти цели должны относиться к небольшому набору приоритетов дорожной карты компании. Затем мы все сидим как целая команда в течение 1–1,5 часов в тот же день, и каждый физически записывает связанные задачи (раскрашенные по цвету владельца) на стикерах. Каждый кладет свои стикеры на эту сетку белой доски (благодарим MetaLab за вдохновение. У вас это чертовски хорошо получается):

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

Судя по незначительным усилиям в Google, большинство традиционных программных команд отнимают БОЛЬШУЮ часть дня на сессиях планирования спринтов. Я не могу заставить себя сделать это в коллективной команде (возможно, я делаю это неправильно). Но как часть первоначальной небольшой группы специалистов по обработке и анализу данных в стартапе, приобретенном EagleView, мы не участвовали в спринте: спринт казался слишком долгим и роскошью, которой у нас не было (введите Канбан, но это уже другая статья). Потенциально каждый день казался новым доказательством правильности концепции. Однако при создании и развитии нашей нынешней команды спринт хорошо оказывается очень важным по ряду причин: (1) приверженность команде, (2) индивидуальное понимание задач, (3) общение и прозрачность, (4) подотчетность и (5) масштабирование продукта ML.

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