Как создать успешный pet-проект. Инструкция для будущих «цукербергов» и «дуровых»

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

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

Александр Гузенко

Старший разработчик IT_One

Идея и концепция

В идеале у вас должна быть какая-то боль, которую вы можете минимизировать или вовсе от нее избавиться. В моем случае мне надоело захламлять личные сообщения в соцсетях, закладки в браузере и playlist в Youtube информацией, которую через несколько недель уже не найти (я много чего хочу прочитать/посмотреть, но руки до этого доходят редко).

Часто идеи появляются в результате общения со знакомыми. Возможно, у них есть задачи, которые вы можете решить. Главное — разобраться в проблеме и поверить в разработку. Иначе можно быстро потерять мотивацию.

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

Поиск решения

Предположим, вы нашли боль, которую можно минимизировать, и у вас в голове созрел гениальный план. Не торопитесь бежать кодить — это ловушка, не повторяйте моих ошибок (о них чуть позже)! Сначала проанализируйте своё решение: точно ли оно будет работать или просто сделает из одной проблемы другую, попробуйте найти пограничные кейсы. Пообщайтесь с людьми, у которых такая же боль, расскажите им о своей идее и поинтересуйтесь их мнением. Свежий взгляд часто бывает полезным.

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

Планирование

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

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

Я рекомендую создать документ в Word и набросать все свои мысли на нескольких страницах. Потом еще несколько раз по ним пройтись, структурировать, возможно, сделать небольшую документацию своего будущего проекта.

В моем случае документ, где я систематизировал все свои мысли, получился таким:

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

Аналитика и инструменты

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

Далее нужно решить, какие технологии использовать. В этом тоже поможет детальный план проекта. Обязательно подумайте над масштабированием. Может лучше сразу какие-то части вынести в отдельные модули, для переиспользования в дальнейшем. Если проект большой, настройте линтеры, создайте ряд правил, руководствуясь которыми вы будете вести разработку. Например, использовать convensional commits, git flow, определенные правила для линтера, аллиасы в коде, структуру проекта и т. д.

Если проект требует разработки в малознакомых вам областях, заранее освойте их хотя бы на базовом уровне. Если вы фронтендер и вам надо будет писать бэкенд — изучите различие SQL и NOSQL баз данных, какие есть серверные языки программирования, их преимущества и недостатки.

Если вы бэкендер и вам нужен будет фронтенд хотя бы немного сложнее простого сайта-визитки — изучите фронтенд фрэймворки и библиотеки: React vs Angular vs Vue.

Для незнакомых вам областей всегда учитывайте сложность освоения. Например, фронтендеру будет гораздо проще освоить Node.js на сервере, чем Java. Для бэкендера может быть легче освоить Angular или React(конечно, это сугубо моё мнение, которое может отличаться от вашего). Идеально, если у вас есть знакомый программист, который в случае чего сможет вам подсказать. Сложностей будет достаточно, поэтому постарайтесь как можно больше упростить себе жизнь еще на этапе планирования.

Так же лучше использовать типизированные языки (например, TS вместо JS).

Определитесь с версиями используемых библиотек и фрэймворков. Учтите, что последние версии не всегда могут быть совместимы с другими инструментами. Но и слишком старые использовать тоже не стоит — возможно, в будущем, вам потребуется обновить версию и это может занять много времени, если между версиями были breaking changes.

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

Старайтесь придерживаться распространенных принципов, таких как KISS, DRY, SOLID и т.д.

Зачем столько сложностей?

Может показаться непонятным зачем ставить себе ограничения. Но благодаря им вы добавляете порядок в свой проект. Представьте, что бы происходило на дорогах, если бы не было ПДД?

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

Такие долгие приготовления могут деморализовать — «я хочу писать код и решать проблему, а не тратить недели на прочтение документации и описание сферического коня в вакууме»! Но, поверьте, опыт показывает, что если подойти к большому и сложному проекту без должной подготовки, то велик шанс быстро выгореть. Большой план можно разбить на маленькие подзадачи и видеть прогресс. А отсутствие плана и отслеживания результатов снижает мотивацию.

Если есть возможность, попробуйте сделать MVP (Minimal Viable Product). Пусть без красивого оформления и с покрытием какого-нибудь одного базового сценария, но если он будет работать, то значит вы на верном пути!

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

Например, на этапе MVP одна из механик моего проекта имела следующий внешний вид:

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

И, наконец, финальный вариант, который я заказал на фрилансе (с дизайном у меня туго, поэтому эту часть я решил делегировать) выглядит еще круче:

Резюме этапов создания проекта

1. Найдите боль.
2. Найдите решение.
3. Проработайте его, поспрашивайте знакомых, узнайте их мнение.
4. Покритикуйте свое решение. Вы должны трезво понимать все недостатки и ограничения.
5. Формализуйте идеи в виде какого-нибудь документа.
6. Проанализируйте рынок на наличие уже существующих решений.
7. «Прогоните» несколько сценариев использования вашего приложения.
8. Составьте стек технологий.
9. Обозначьте все ограничения, которых вы будете придерживаться для поддержания порядка кодовой базы.
10. Постарайтесь минимизировать сложности в процессе разработки еще на этапе планирования.