Командный пет-проект – шикарный опыт
#career #petproject
Зная, что конверсия из поста про MLOps-курс https://t.me/new_yorko_times/96 в упомянутую там статью на Хабре – около 1%, опишу выводы из той же статьи чуть подробнее. Будет полезно всем, кто хочет командой попилить проект, будь то любой пет (как с chatGPT так и без) или командный проект в рамках скоро стартующего курса по MLOps.
- Поработать в команде над интересным проектом – очень крутой опыт, он и сам по себе полезен, и “продавать” его тоже можно на собеседованиях. Это может сравниться с командной зарубой в Kaggle соревновании – тут можно многому научиться, как работе с GitHub, так и навыкам планирования
- Очень важно иметь дедлайн, скажем, конец соревнования на Kaggle или окончание курса. Иначе мотивация бодро фигачить начинает падать
- Оптимальный размер команды – от 3 до 5 человек. Недаром и на Kaggle к этому пришли. Сверх этого – уже есть риск нанять балласт вместо паравоза
- Хорошо бы довести пет-проект до красивой демки, на которую можно и в резюме сослаться и в любой ситуации хоть в лифте показать. Вот наша http://cryptobarometer.org - барометр, показывающий тональность новостей о крипте
- Немного “галеры” привнести в душевный пет-проект не помешает: если обозначить цели (можно в формате OKR) и настроить базовые Scrum-ритуалы, будет более четкое понимание, кто что делает и куда команда движется. Но надо аккуратно, все же пет-проджект – это больше про веселье и полет фантазии
- Здорово в начале сотрудничества побрейнстормить: собраться и накидать идей, обсудить и приоретизировать (сервисы типа https://easyretro.io хорошо для этого подходят)
- Очень помогает делать мини-демки внутри команды. Даже если встречаться всего на час в неделю, имеет смысл начать с 20-минутной демки кого-то из участников (например, продемонстрировать продвижения с фронтендом или сервисом LabelStudio), а потом уже обычный стендап с обсуждением текущих задач.
- Мне помогло разделение активности на треки – инженерный и исследовательский. Первый – про API, докеры и куберы, второй – про прикладной рисеч а-ля active learning, помогают ли аугментации данных и т.д. В целом как Delivery vs. Discovery в корпорациях
- Также помогло четко расписать роли в команде, у нас это был один ML-инженер, два Data Scientist-a/аналитика/ML-исследователя, один Data Engineer и тимлид
- Неочевидным, но, как кажется, верным решением было подождать, пока кто-то один (тимлид, конечно) накидает прототип решения, с мок-версиями всех компонентов (например, базовый краулер и tf-idf вместо берта) и прописанным в коде взаимодействием компонентов. Имея такой прототип, можно было уже намного эффективнее распараллелить задачи по совершенствованию каждого компонента (иначе – затыки а-ля краулер готов, а база еще нет, active learning вроде готов, но неоткуда разметку брать и т.д.).
#career #petproject
Зная, что конверсия из поста про MLOps-курс https://t.me/new_yorko_times/96 в упомянутую там статью на Хабре – около 1%, опишу выводы из той же статьи чуть подробнее. Будет полезно всем, кто хочет командой попилить проект, будь то любой пет (как с chatGPT так и без) или командный проект в рамках скоро стартующего курса по MLOps.
- Поработать в команде над интересным проектом – очень крутой опыт, он и сам по себе полезен, и “продавать” его тоже можно на собеседованиях. Это может сравниться с командной зарубой в Kaggle соревновании – тут можно многому научиться, как работе с GitHub, так и навыкам планирования
- Очень важно иметь дедлайн, скажем, конец соревнования на Kaggle или окончание курса. Иначе мотивация бодро фигачить начинает падать
- Оптимальный размер команды – от 3 до 5 человек. Недаром и на Kaggle к этому пришли. Сверх этого – уже есть риск нанять балласт вместо паравоза
- Хорошо бы довести пет-проект до красивой демки, на которую можно и в резюме сослаться и в любой ситуации хоть в лифте показать. Вот наша http://cryptobarometer.org - барометр, показывающий тональность новостей о крипте
- Немного “галеры” привнести в душевный пет-проект не помешает: если обозначить цели (можно в формате OKR) и настроить базовые Scrum-ритуалы, будет более четкое понимание, кто что делает и куда команда движется. Но надо аккуратно, все же пет-проджект – это больше про веселье и полет фантазии
- Здорово в начале сотрудничества побрейнстормить: собраться и накидать идей, обсудить и приоретизировать (сервисы типа https://easyretro.io хорошо для этого подходят)
- Очень помогает делать мини-демки внутри команды. Даже если встречаться всего на час в неделю, имеет смысл начать с 20-минутной демки кого-то из участников (например, продемонстрировать продвижения с фронтендом или сервисом LabelStudio), а потом уже обычный стендап с обсуждением текущих задач.
- Мне помогло разделение активности на треки – инженерный и исследовательский. Первый – про API, докеры и куберы, второй – про прикладной рисеч а-ля active learning, помогают ли аугментации данных и т.д. В целом как Delivery vs. Discovery в корпорациях
- Также помогло четко расписать роли в команде, у нас это был один ML-инженер, два Data Scientist-a/аналитика/ML-исследователя, один Data Engineer и тимлид
- Неочевидным, но, как кажется, верным решением было подождать, пока кто-то один (тимлид, конечно) накидает прототип решения, с мок-версиями всех компонентов (например, базовый краулер и tf-idf вместо берта) и прописанным в коде взаимодействием компонентов. Имея такой прототип, можно было уже намного эффективнее распараллелить задачи по совершенствованию каждого компонента (иначе – затыки а-ля краулер готов, а база еще нет, active learning вроде готов, но неоткуда разметку брать и т.д.).