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

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

Но на практике большинство pet-проектов работают против своих авторов, превращаясь не в демонстрацию скиллов, а в коллекцию недоделанных попыток.

В этой статье разберёмся, как пет-проекты могут вам навредить и что с этим делать.

Что не так с пет-проектами и их восприятием?

1. Мифическая панацея

GitHub со звёздами и коммитами часто воспринимается как замена коммерческому опыту. Но беда в том, что тимлиды смотрят туда не ради коммитов, а чтобы понять: как человек мыслит, как решает задачи, презентует результат.

Но чаще всего я сталкивался с брошенными репозиториями без описаний и пет-проектом без названия, в котором когда-нибудь будет Redux, но точно не сегодня. Возможно позже. А, возможно, никогда. 

Стоит развеять миф: пет-проект не может быть альтернативой реальному опыту. Поскольку коммерческий опыт не ограничивается одним кодом. Это и командная работа, горящие дедлайны, ответственность перед пользователями и коллегами, стандарты и компромиссы. А пет-проект, при всей его возможной сложности, это поле экспериментов без внешнего давления. Круто, но на боевой опыт не тянет. 

Пет-проект стоит рассматривать как дополнительный плюс (особенно если качественно сделан) или хорошее подспорье. 

На сильный эффект рассчитывать не стоит, особенно если вы опытный разработчик, а не выпускник университета.

2. Незаконченность

У меня есть несколько заброшенных идей, которые когда-то казались мне интересными. Думаю, такие брошенные идеи есть у всех. И это нормально. Но нужно уметь с ними работать, особенно если они находятся в общем доступе. 

Вопрос не в том, что разработчик когда-то не доделал, а в том, как он сейчас это презентует. Если разработчик начал делать бота для телеги, поиграл с API, сохранил код и забыл - это не пет-проект, а обычный кусок кода. Сюда же относятся и репозитории а-ля «my-final-portfolio-v4», в котором есть только пустой index.html. 

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

Неразобранный гит с большой долей вероятности производит не то впечатление, на которое мы рассчитываем. 

Не всегда наличие пет-проекта — это плюс. Всё зависит от того, что именно там представлено. 

Никто не требует и не ждет идеального pet-проекта. Но если вы его показываете — он должен быть внятным.

3. Отсутствие цели и результата

Допустим, проект всё же есть. Здесь- то и скрыта следующая ловушка, в которую чертовски легко угодить. Это цель. 

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

Вот простой тест для пет-проекта:

• Есть ли README?

• Понятна ли задача?

• Есть ли MVP?

Если на большинство вопросов ответ «нет», тогда проект стоит либо доработать, либо скрыть. 

4. Самообман

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

Вместо реальной пользы пет-проект дарит усыпляющее самоуспокоение. А уже на собеседованиях происходит столкновение с суровой реальностью - множество незавершённых проектов тянет на дно, заставляя выдавать ответы, больше похожие на школьные отговорки: «я все это время занимался пет‑проектом».

Пет-проекты хороши, пока они приносят практическую пользу, а не становятся причиной губительной прокрастинации.

Хороший pet-проект — какой он?

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

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

Это скажется на восприятии вашей кандидатуры. Особенно если претендуете на роль в стартапе или в компаниях с инженерной культурой.

Чтобы понять, какой проект действительно стоит показать — пройдёмся по критериям хорошего пет-проекта. Я выделяю для себя 5 пунктов:

• Ограниченный по цели. Один фокус — одна задача.

• Законченный. MVP + описание + логика = минимальный набор.

• Документированный. README и комментарии.

• Обновляемый или архивированный.

• Осмысленный. Вы можете объяснить, зачем он нужен и кому.

Это и хочет увидеть работодатель, переходя на гитхаб. Они не ищут там идеальный код. Они ищут мыслящего разработчика, но точно не коллекцию пустых каталогов. 

Именно поэтому GitHub, забитый десятками заброшенных pet-проектов, может сыграть против вас. Но это не значит, что всё потеряно.

Как «реанимировать» или правильно запустить pet-проект

Главное — подойти к делу с хирургической точностью.

1. Устройте ревизию

Просмотрите свои проекты и подумайте: какие действительно хочется довести до конца, а какие проще перенести в приват или удалить.

2. Выберите одного-двух «фаворитов»

Лучше один рабочий проект, чем десяток «почти готовых». Сосредоточьтесь на простом, но завершённом варианте, который можно показать другим.

3. Добавьте историю

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

4. Попросите обратную связь

Покажите проект коллеге, другу-разработчику или в профильном чате. Иногда один комментарий помогает понять, куда двигаться дальше.

5. Задайте себе срок

Если через месяц-два проект не двигается, смело переносите его в архив. Это не поражение — просто он выполнил свою задачу и дал вам опыт. 

Вместо вывода

Пет-проекты — это инструмент. Но как и любым инструментом, им нужно уметь пользоваться. Если подойти к нему без цели и структуры, он может сработать не в вашу пользу. 

Проект — это аргумент. Он должен говорить о вас то, что вы хотите донести. Если он этого не делает, возможно, лучше его переписать или не показывать вовсе.

Pet-проект может стать дополнительным плюсом в вашу пользу, а может остаться цифровым мусором. Всё зависит от того, насколько он завершён и осмыслен. Следите за своими проектами. А еще можете подписаться на мой телеграм канал о карьере в IT!