Привет, DZEN! Меня зовут Данил Картушов!
В этом посте я расскажу, почему и как именно pet-project'ы могут стать ключом к вашей карьере.
Надеюсь, что после этого поста ты сможешь раскрыть свой потенциал к обучению и по-новому взглянуть на процесс обучения.
Начнем!
Содержание
[1] Предисловие
[2] Practice First подход
[3] Успешный успех Пет-проектов
[4] Этапы пет-проекта
[5] Мотивация
[6] Как это все поможет найти работу?
[7] Послесловие
[8] Приложение
Предисловие
Помнишь мем о том, что в IT невозможно попасть без опыта, то новичкам места нет и после университета остаётся только путь на завод?
И ты знаешь, в каждой шутке есть доля правды. В наше время недостаточно пройти даже десяток курсов. Можно и не найти работу, ведь требуется приложить колоссальные усилия, делать гораздо больше, чем просто решать задачки на семинарах и смотреть лекции.
Конечно, решение отдельных задач — это отличный способ освоить конкретные навыки. Но, занимаясь только этим, ты как будто собираешь кубики лего или детали пазла без единого плана. Ты упускаешь важную составляющую — понимание взаимосвязи между всеми элементами, композицию!
Ведь на работе ты собираешь или будешь собирать и интегрировать в общую конструкцию, взаимодействовать со всей системой. Но как же быть, если на работу тебя еще не взяли, но и опыта после курсов еще нет?
И вот тут-то на сцену выходят pet-проекты — это твоя мини-версия будущей работы или альтернативного пути, где ты можешь испытать себя в роли тимлида, исследователя или разработчика. Ты можешь представить свой проект на конференции или превратить его в свой стартап!
Представь уровни погружения в знания как треугольник Маслоу. Звучит необычно? Но посмотри, как это работает:
- На первом уровне мы находимся с лекциями. Это верхний слой нашего треугольника, где всё начинается с контекста. Тут работает твоя интуиция, образы, визуал. Ты улавливаешь абстракции, но часто возникают вопросы. Например, как поведет себя модель без определенного параметра или с добавлением регуляризации?
- Следующий уровень — семинары. Здесь ты применяешь полученные знания на практике. Это момент, когда теория становится осязаемой, ты её «ощупываешь», подтверждаешь и закрепляешь. По моему опыту, это ключевой этап для запоминания.
- Третий уровень привносит кейсы из бизнеса, хакатоны и подобное. Теперь ты не просто знаешь теорию, ты видишь, как она решает реальные задачи в конкретных условиях. Это погружение в контекст, в историю, которая стоит за каждой задачей.
- На четвертом этапе находятся пет-проекты. И не просто какие-то, а те, что решают реальные проблемы пользователей, напоминающие микро-стартапы. Это твой шанс попробовать себя в роли создателя, исследовать и применить накопленные знания для решения практических задач.
- И, наконец, последний уровень — работа. Нет лучшего способа усвоить навыки, чем применять их каждый день, решая реальные рабочие задачи. Работа дает непревзойденный опыт и понимание, как применять знания на практике.
Practice First подход
А ведь действительно можно заметить, как классическое обучение сейчас очень сильно отстает и существует в отрыве от практики. Знаешь тот классический подход в большинстве курсах, он пропускает примерно 50% важной информации. Неудивительно, что многие новички после курсов часто обращаются с вопросами в духе: “А что почитать дополнительно?”, “Какие лекции стоит посмотреть?”, “А этому меня не учили...”.
Это связано с тем, что ты приобретаешь отдельные детали пазла, но не соединяешь в целую конструкцию! Не получаюшь подкрепления в виде реального опыта и понимания того, как и когда их применять. Не возникает вопрос: существуют ли альтернативные решения? В конечном итоге теряется важная часть мыслительного процесса и бизнес-контекста.
Я для себя открыл уникальный подход: как минимизировать затрачиваемые усилия и достигать лучших результатов. Иными словами, попытки охватить весь спектр машинного обучения кажутся нецелесообразными. Ведь когда возникает потребность в конкретном знании или инструменте, например, в линейной регрессии или понимании механизма Self-Attention, ты непременно столкнёшься с этим на практике. Именно тогда и появляется время для изучения, которое становится приоритетной задачей. Погружение в детали в такой момент позволяет усваивать информацию наиболее эффективно.
Я называю это Practice First подход, но ты можешь предложить в комментариях свой вариант!
- Этап 1 — Сфокусируйтесь на проблеме. Представим, что интерес к изучению NLP возник не на пустом месте. В первую очередь стоит разобраться, какие актуальные задачи может решить NLP.
- Этап 2 — Переходите к действию. Несмотря на кажущуюся очевидность, важно начать решать проблему практическим путем. Это дает ясность в том, какие шаги предпринять дальше.
- Этап 3 — Столкновение со сложностями. В процессе работы наверняка возникнут моменты, когда будет ощущаться недостаток знаний. Именно тогда и проявится необходимость в теории, указывая на то, что следует изучить для преодоления препятствий.
Знаешь если ты действительно хочешь освоить этот навык я в конце приложу еще материалы, что бы ты мог лучше разобраться в анализе ошибок и practice first подходе.
Успешный успех Пет-Проектов
Знаешь, мне очень нравится одна фраза, которая действительно заставляет задуматься:
Хороший проект — это ваш будущий стартап.
Но давайте разберёмся, почему именно? Если мы берём на себя решение какой-то проблемы, то почему бы не предложить её решение пользователям? В конце концов, именно это и отличает успешные стартапы: они решают реальные проблемы реальных людей.
Классические пет-проекты, с которыми я сталкивался, отличаются от большинства начальных этапов стартапов именно наличием конкретной проблемы, на решение которой они направлены.
В отличие от стартапов, которые быстро разворачивают новые функции, стараются быть удобными для пользователя и обладают высокой гибкостью, пет-проекты не несут прямой обязанности результативности, однако могут эволюционировать в стартап при наличии упорства и правильном подходе к развитию.
Корпоративная среда имеет свою уникальность — четкие бизнес-требования и специализация создают определенные рамки и ограничения, выйти за которые часто невозможно. В то же время, пет-проекты представляют собой прекрасную возможность для тех, кто стремится исследовать новые горизонты в своей профессиональной деятельности.
Этапы пет-проекта
Мы наконец то дошли до практической части и с этого момента, я расскажу тебе о том как на мой взгляд действительно должно происходить формирование пет-проектов.
- Поиск проблемы и проблематики — многие, особенно новички, упускают этот важный момент. Наличие проблемы — это уже большой успех. Это означает, что есть задача для решения и аудитория, которая сталкивается с этой проблемой и, возможно, готова платить за её решение. Принцип “What? Why? How?” может оказаться здесь очень полезным.
- Идея и систем дизайн — кследующим шагом является поиск идей и решений, а также составление и поддержка дизайн документа на протяжении всего проекта. Дизайн-документ позволит предвидеть будущие проблемы, как некий roadmap, и создать единое видение проекта в команде. Также рекомендуется создать Customer Journey Map и User Story Mapping.
- CustDev и PoC — Затем необходимо опросить людей о наличии проблемы и необходимости её решения. Важно выяснить, с чем сталкиваются эти люди. А с чем сталкиваются эти люди. Создайте Proof of Concept, например в Jupyter или с использованием GPT, чтобы проверить осуществимость решения.
- MVP и проверка гипотез — После этого создается минимально жизнеспособный продукт (MVP), который уже могут использовать люди. На этом этапе можно проводить A/B тесты, опрашивать пользователей и тестеров, проверять различные гипотезы.
- Запуск Пилота — Пилотный проект представляет собой законченную деятельность с подтвержденной основной гипотезой. Это проект, который уже можно смело показывать публике. Однако всегда есть возможность находить новые гипотезы и идеи в рамках проекта.
- Продвижение — Отличным заключительным этапом будет рассказать о своем проекте. Выступить на конференции, написать статью на Хабре и так далее. Возможно, именно с этого момента к вам начнут поступать интересные предложения о работе!
Организация github/gitlab
Организация репозитория проекта на начальном этапе играет ключевую роль. Если твой проект будут рассматривать другие, то крайне важно, чтобы он был понятным и воспроизводимым.
Сегодня уже становится базой, что на собеседованиях могут задавать вопросы на основе твоего GitHub профиля или резюме. И если управление версиями и работа с репозиториями еще не стали частью твоей повседневной рутины на работе, скоро это обязательно произойдет!
Вот несколько моих личных шагов, которые я регулярно выполняю при создании репозитория. Делясь ими, я как бы отдаю часть своего сердца:
ReadMe
Одним из ключевых элементов, по которому можно оценить проект, является файл ReadMe. Лично мне нравятся сдержанные ReadMe, которые одновременно содержат всю необходимую информацию.
Вот рекомендации, что должно быть в твоем ReadMe, чтобы оно было максимально информативным и полезным:
- Название и используемые инструменты в хот баре, чтобы наглядно показать, какие технологии и инструменты применялись в проекте.
- Описание проекта: здесь важно ответить на вопросы: Что это за проект? Для кого он создан? Зачем он нужен? Такое описание поможет быстро дать понять суть проекта потенциальным пользователям и коллегам.
- Инструкция по установке: подробно опиши процесс установки проекта. Для разработчиков (dev, contributor) желательно предоставить отдельные инструкции, включая особенности установки зависимостей, настройки среды и т.д.
- Ссылки на документацию, поддержку и контакты для связи: укажи, где можно найти дополнительную информацию о проекте, как получить поддержку и куда обращаться с вопросами. Это упростит коммуникацию с пользователями и другими разработчиками.
Структура
Если ты посмотришь большинство крупных опенсорс проектов. то увидишь, что по большому счету они одинаковые по своей структуре.
Ведение веток
Github actions
Теперь, когда ты начал активно использовать ветвление и Git, благодаря советам умного человека, перед тобой открываются возможности, предоставляемые github actions. Этот инструмент позволяет автоматически выполнять различные действия в твоем проекте при событиях push и merge/pull request.
При выполнении действий, которые ты укажешь для определённых веток (например, при dev/* или *fix/**), будут запускаться тесты на воспроизводимость, а также линтеры и форматтеры кода. Кроме того, при каждом MR в ветку main к этому могут добавляться дополнительные действия, такие как публикация пакета.
Подробнее про это ты можешь узнать погуглив CI/CD
Воспроизводимость
Poetry — это один из удобных инструментов для управления зависимостями и пакетами в проектах на Python, обеспечивающий удобное версионирование. Poetry позволяет легко устанавливать пакеты и управлять ими для различных версий Python.
Pyenv — великолепно дополняет Poetry. Pyenv может локально установить нужную версию Python или определенный снапшот исключительно для вашего проекта, обеспечивая необходимую версию среды исполнения.
Docker — незаменим для контейнеризации. Docker гарантирует, что ваш проект будет собран и запущен в изолированной среде, тем самым исключая возможные проблемы совместимости с операционной системой.
Читаемость кода
Названия функция и аргументов — распространённая ошибка заключается в использовании непонятных или абстрактных наименований для функций. Название функции должно отражать её назначение или содержимое объекта. Избегайте использования слишком общих обозначений типа i, x, c, b, param, func и т. п.
Докстринги — не менее важной частью являются докстринги. Это подробное текстовое описание, документация ваших функций и классов. Они необходимы, во-первых, для автоматизации документации, во-вторых, для удобства других разработчиков. По традиции, как и многие, я использую формат докстрингов Numpy.
Линтеры и форматтеры — учитывая, что невозможно помнить все правила PEP8, руководства по стилю numpy и прочие, были разработаны линтеры и форматтеры. Они автоматизируют процессы проверки качества кода и могут исправлять большинство ошибок. Недавно я начал использовать Ruff, который объединяет в себе множество полезных функций.
Документация
Всем известно, насколько удобно быстро прочитать докстринги к коду, однако это всё ещё не делает документацию полноценной. Согласитесь, было бы значительно удобнее иметь под рукой своеобразную книгу, где подробно изложены инструкции по сборке проекта. В такую книгу можно было бы включить информацию о взаимодействии с API, базами данных, а также дизайн-документацию и многое другое.
Для создания и управления такой документацией существует несколько инструментов:
- Sphinx— мощный инструмент, созданный специально для документирования кода, который поддерживает генерацию множества форматов вывода из reStructuredText.
- GitBook— платформа для создания красивой документации, которая интегрируется с Git, позволяя легко обновлять и синхронизировать содержимое.
Мотивация
Возможно, те идеи, которые ты будешь реализовывать, окажутся сложными для решения в одиночку, и в какой-то момент этот процесс может показаться неинтересным. Есть несколько способов не потерять мотивацию:
- Найти ментораНайди кого-нибудь из мидлов или сеньоров, кто хорошо разбирается в нише вашего проекта, и попроси его раз в месяц или две недели проводить для вас код-ревью и давать обратную связь.Где найти ментора? Всё достаточно просто — финалисты хакатонов, чаты, сообщества, митапы, авторы телеграм-каналов. Можешь даже мне написать!Как это поможет в мотивации? Теперь у тебя есть кнут и пряник от ментора: твой труд подкрепляется обратной связью (которую тоже нужно уметь давать). Ты активируешь дофамин! В приложении оставлю ссылку на лекцию про dopamine mindset & control motivation.
- Работать в команде Некоторые проекты лучше и интереснее делать вместе. Это позволяет освоить работу в команде, распределить роли и ускорить выполнение проекта, проводить кросс-ревью. В итоге появляется больше идей.Сколько в идеале должно быть людей в команде? По моему опыту, идеальный состав — это 3-5 человек. Так никто не останется без работы.Как распределять задачи? В рамках обучения наиболее эффективно давать задачи тому, у кого меньше всего знаний по проекту, а проверять — человеку с наибольшими знаниями. Так ты закрываешь нижний порог знаний. Также советую использовать метод MoSCoW для распределения приоритетов, что сильно поможет вашей команде!
- Взаимодействовать с пользователями Проводите CustDev, проверяйте гипотезы. Пользователи подскажут новые локальные проблемы и интересные направления для проектов. Это бесконечный цикл решения проблем и оптимизации старых процессов, создания новых функций. Твоя главная метрика — это мнение и комфорт пользователей.
- Рассказать о своем проекте общественности Не ограничивайтесь только пользователями. Попробуйте рассказать о своем проекте на конференциях, в социальных сетях, на Хабре. Так ты можешь получить мнение более квалифицированных людей и др.
Как это все поможет найти работу?
Резюме
Если ты всё ещё не умеешь правильно составлять резюме, то вот тебе гайд. Важно грамотно оформлять результаты по правилу XYZ: "Делал X с помощью Y и получил Z".
Часто вспомнить и сформулировать результаты работы бывает сложно — мы не привыкли фиксировать результаты, в команде это не обсуждается или просто забывается из-за прошедшего времени. Попробуй обратиться к коллегам за инсайтами и конкретными цифрами. Также можно перечислить все свои задачи и указать, к каким результатам они привели. Иногда озарение приходит и при чтении чужих резюме — поищи в LinkedIn, чтобы вдохновиться, как другие описывают свой опыт.
Всё это нужно уметь грамотно оформить на английском языке по формуле XYZ, которая в одном предложении звучит как «Accomplished [X] as measured by [Y], by doing [Z]». Где X — это всегда глагол действия: Managed the project, Led a team of, Grew revenue, Developed a tool... Y обозначает количественную или качественную меру: resulting in, which improved engagement by _%, that reduced testing time by _%... А Z выражает, как именно были достигнуты такие результаты: by working with..., optimizing sales process, conducting situational analysis.
❗Важно, когда пишешь о результатах, использовать метрики:
- Удалось улучшить Recall на 20%.
- DAU вырос на 200 человек.
- И так далее.
Существуют так-же различные чаты по оценке резюме
- Сингулярити (и другие, например, сообщества ODS).
- Чаты по вакансиям.
- Отправить HR, с которым ты уже знаком или ранее сталкивался.
- Отправить руководителю отдела или кого-либо из профессионалов в интересующей тебя сфере.
Послесловие
Спасибо, что дочитал до конца! Я надеюсь, твой проект получится действительно крутым, обязательно делись своими результатами в комментариях.
Если тебе действительно понравился такой контент, подписывайся на мой телеграм-канал. Там я публикую разборы различных архитектур ML-моделей и просто интересные находки в области RecSys, Gen AI, NLP, LLM. В общем, это канал о моём пути в 99-й квантиль ML-инженеров! Пиши, не стесняйся ✌️
Приложение
Design Doc
Шаблон и инструкция по дизайн документа
https://github.com/IrinaGoloshchapova/ml_system_design_doc_ru
Анализ рынка
https://practicum.yandex.ru/blog/chto-takoe-analiz-rynka-i-kak-ego-provesti/
Customer Journey Map
https://practicum.yandex.ru/blog/customer-journey-map/
User Story Mapping
https://habr.com/ru/companies/akbarsdigital/articles/699950/
Git Hub
Про менеджмент веток
Про нейминги веток
https://www.scaler.com/topics/git/git-branch-naming-conventions/
Documentation
Как составлять документацию
https://www.writethedocs.org/guide/writing/beginners-guide-to-doc
Как использовать MkDocs
https://habr.com/ru/companies/rostelecom/articles/570098/
Про навыки
10 популярынх ошибок в ML
https://habr.com/ru/articles/718942/
Анализ ошибок
https://habr.com/ru/articles/760550/
Про мотивацию
https://www.youtube.com/watch?v=QmOF0crdyRU
Метод приоритезации MoSCoW
https://www.productplan.com/glossary/moscow-prioritization/
Agile
https://vc.ru/marketing/518920-gayd-po-agile-kak-rabotat-nesmotrya-ni-na-chto-na-primere-marketinga
Составление резюме