Вы садитесь за свой проект в десять вечера, потому что днём было некогда. Правите баг, замечаете второй, к полуночи переписываете модуль, который вообще-то работал. А наутро вспоминаете про дедлайн, который сами себе и поставили. Кажется, это уже не совсем хобби.
Вы садитесь за свой проект в десять вечера, потому что днём было некогда. Правите баг, замечаете второй, к полуночи переписываете модуль, который вообще-то работал. А наутро вспоминаете про дедлайн, который сами себе и поставили. Кажется, это уже не совсем хобби.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Обычно pet-проект начинается невинно: попробовать новый стек, собрать Telegram-бота, довести до ума идею, которая давно лежит в заметках. Первые недели он даже не похож на работу — задачу выбираете вы, решения принимаете вы, останавливаетесь когда захотите. А через пару месяцев у него появляются backlog, дедлайны, баги и чувство вины за каждый свободный вечер.
Разбираемся, как удержать личный проект в размере: сколько времени ему отдавать, что считать релизом, когда останавливаться и как уйти на паузу, чтобы через полгода не начинать всё с нуля.
У всякой увлечённости есть отложенная цена. В разборе процесса перехода хобби в подработку собраны данные: за особенно азартным рабочим днём чаще идёт день с выгоранием.
Дальше вступают сроки. Заказчик назначает, когда сдавать, и вместо личного исследования появляется бриф. В том же разборе есть наблюдение, которое неприятно узнавать про себя: увлечённые люди чаще соглашаются на меньшие деньги и более долгие часы. Работа сама по себе ощущается наградой, и торговаться как будто не за что.
С pet-проектом всё то же самое, только заказчик — вы. Пока что-то делается для себя, можно переписать архитектуру в три часа ночи и никому этого не объяснять. Но если проект должен одновременно стать портфолио, принести первые деньги, набрать пользователей и помочь сменить работу — он выполняет слишком много ролей сразу, и каждая тянет в свою сторону.
Поэтому две зоны стоит разделить. В первой проект работает на результат: освоить технологию, получить кейс в резюме, проверить идею, сделать вклад в open source. А во второй остаётся то, что вы делаете просто потому, что интересно, и никому не показываете.
Вторую берегите: переведёте в актив всё хобби целиком — пропадёт то состояние, ради которого всё и затевалось.
Универсальной цифры нет. Но граница нужна, иначе дело растянется на всё, что у вас есть, — это закон Паркинсона, «работа занимает всё время, отпущенное на неё». Он сформулирован в The Economist ещё в 1955 году.
Таймбокс — заранее назначенное окно — тем и полезен, что заставляет сделать главное, пока время не кончилось. Как верхнюю границу берут до двух часов в день, включая выходные. В сообществах разработчиков сходятся на том же: короткие регулярные сессии держатся дольше, чем редкие многочасовые штурмы.
Сразу оговоримся про эту цифру. Проверить её нечем: единой статистики по личным проектам никто не ведёт, а «два часа» — сложившаяся практика, и относиться к ней стоит соответственно. Поэтому смотреть надо на механизм: планка назначается по тому, что вы выдержите месяцами.
Если после работы остаётся час — растягивать до двух незачем. Пятнадцать минут через день дают больше, чем воскресный марафон на восемь часов.
Есть ещё правило «пяти часов»: час в день на осознанное обучение, чтение, эксперименты и разбор сделанного. Для pet-проектов — это ориентир. Если ваша цель закончить продукт, следите за этим часом: растягиваясь, он незаметно становится вторым проектом.
Самая опасная фраза: «потом ещё добавлю».
Вот как это выглядит на практике. Вы пишете сервис, который решает одну проблему. Через неделю добавляете авторизацию — без неё же несерьёзно. Потом Telegram-бота, чтобы приходили уведомления. Потом админку, чтобы не лазить в базу руками. Потом Docker. Потом Kubernetes, просто из интереса. Потом AI-функцию, раз уж на дворе 2026 год.
Каждая идея по отдельности разумна. Но вместе они превращают затею на вечер в продуктовую компанию из одного человека, у которого вообще-то есть дневная работа.
Треугольник управления проектами говорит скучную вещь, которую на своём проекте забывают первой: scope, время и деньги связаны. Времени у вас больше не станет, значит, уменьшать придётся объём.
Поэтому до первой строчки кода назовите один сценарий, который проект обязан закрыть. Одну проблему одного человека — своя собственная тоже считается. Всё остальное уходит в список coming soon.
Тот же приём против scope creep советует Systemology: сначала письменно закрепить границу результата, а новые идеи держать отдельно от обязательного объёма. У них это называется Critical Client Flow и придумано для первого проекта с клиентом, но на личном работает точно так же.
MVP часто трактуют как «сделаем кое-как, потом улучшим». Для pet-проектов полезнее другое чтение: минимальный релиз — это наименьшая версия, которая уже доказывает вашу идею или навык. Дальше всё зависит от того, зачем вы за это взялись.
Её ставят одной командой, а из README видно, для чего она. Этого достаточно: если через минуту после установки человек понимает, решает библиотека его задачу или нет, релиз состоялся.
README с командой запуска, лицензия и внятная польза для другого разработчика. В обсуждениях это регулярно называют достаточным основанием, чтобы публиковать, а не ждать идеальной версии. Идеальной и не будет: есть опубликованная, а есть та, которую всё ещё стыдно показать.
Здесь планка ниже всего, хотя задирают её обычно выше остальных. Полноценный SaaS строить незачем: хватит рабочего прототипа, репозитория, документации, пары тестовых сценариев и абзаца о том, какую задачу вы решали.
Дальше можно остановиться.
Критерии готовности обычно придумываются сами. Критерии остановки приходится назначать — и лучше сделать это, пока вы ещё ничего не вложили.
Я даю этому шесть недель и максимум 40 часов. Если после этого основной сценарий не работает, я не увеличиваю бюджет времени, а упрощаю задачу или закрываю проект.
Если после первого релиза за месяц не пришёл ни один живой пользователь, проект уходит в архив.
Если новые функции перестали давать мне новый навык, он больше не оправдывает время.
Последний вариант встречается чаще всего. Работу продолжают из-за уже вложенных часов, а не из-за того, чему она ещё учит.
Это ошибка невозвратных затрат: вернуть потраченное нельзя, но мозг считает его аргументом продолжать. Противоядие лежит на той же странице и называется моделью «вращающихся дверей» — представьте, что увидели этот проект сегодня впервые, ничего в него не вложив, и спросите себя, отдали бы вы ему следующие двадцать часов.
Вопрос стоит записать заранее. На холодную голову ответить на него куда легче.
Есть сценарий, о котором в начале не думают: проект оказался хорошим, но сейчас не время. Новая работа, переезд, ребёнок, большой релиз — и pet-проект исчезает на полгода. Возвращение стоит дороже, чем кажется. Первые вечера уходят на один вопрос: «что здесь вообще происходит».
Кейтлин Нокс, которая пишет о работе над длинными академическими текстами, называет это reinitiation overhead — накладными расходами на повторный вход. Её вывод: платить приходится один раз, если перед паузой упаковать проект самому.
Поэтому оставьте не просто TODO.md. Запишите три вещи:
Дороже всего обходится «почему». Через полгода вы не вспомните, зачем отказались от Kafka, чем не подошла её замена и на чём держится тот странный кусок кода в середине.
Можно буквально написать письмо будущему себе: «Если ты открыл этот файл, значит, проект снова жив. Вот текущее состояние, вот что не надо трогать, а вот первый шаг».
Тогда пауза перестаёт быть провалом. Вы просто закрываете вкладку — с возможностью открыть её позже.
Иногда дисциплина ни при чём: вы пока не умеете оценивать объём работы. Ничего странного — этому нигде специально не учат.
На Udemy есть короткий курс Understanding Project Scope Management — два PDU, то есть примерно два часа. Он о том, как описать границы работы и удержать их, когда появляются новые идеи. Инструменты оттуда переносятся на личные проекты, даже если вы не собираетесь становиться PM.
Покупать курс стоит по тому же правилу, что и делать pet-проекты: заранее решить, что изменится потом. Сертификат в LinkedIn — слабый результат. Хороший — если после курса вы за час опишете scope своего проекта и вычеркнете половину.
Проект легко оценивать по размеру замысла: кажется, что большой даст больше опыта. Но чаще получается наоборот.
Пока один разработчик год строит «настоящий продукт» и никому его не показывает, другой за то же время выкатил четыре маленькие версии, собрал отклики на три из них и по четвёртой понял, что тему пора закрывать. Опыта у второго больше — он четыре раза дошёл до конца.
Поэтому мыслить стоит короткими циклами: идея → маленькая версия → запуск → обратная связь → решение продолжать, изменить или остановиться.
Про то, как доводить начатое до конца и разгребать накопившееся, есть смысл почитать Getting Things Done Дэвида Аллена. Про маленькие устойчивые действия вместо периодических рывков — Atomic Habits Джеймса Клира: книга не про pet-проекты, но ложится на ту же мысль.
Достаточно держать в голове четыре вещи. Сколько времени вы готовы отдавать месяцами — по обычной неделе, а не по ударной. Что будет считаться минимальным релизом. При каких условиях вы остановитесь. И как сохраните контекст, если придётся уйти на паузу.
Если проект растёт, не двигайте срок — уменьшайте объём. Если уже потрачено много, это не причина тратить ещё: спросите себя про следующие двадцать часов. Если пора замораживать работу, не бросайте проект молча — оставьте карту возвращения.
И не мерьте успех строчками кода и выходными за компьютером. Тридцать часов с рабочим релизом и навыком, который можно показать работодателю, стоят больше двухсот, после которых проект всё ещё «почти готов».
Пусть личный проект оставляет вам результат, а не ощущение, что вы устроились на вторую работу — без зарплаты и с испытательным сроком длиной в бесконечность.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.