Введение

Я работаю веб-разработчиком уже 8 лет, и до последних выходных я ни разу не выпустил законченный сторонний проект. Это не значит, что я не собирался, за эти годы у меня было много побочных проектов: от систем управления контентом до фреймворков, сервисов подписки и сетевых платформ. Но, как и у многих других разработчиков, мои сторонние проекты всегда отставали в сторону в какой-то момент между концепцией и релизом. Иногда из-за нехватки времени или отвлечения на новую захватывающую идею, которая страшила последние 10% или чаще, чем нет, в погоне за совершенством.

Соревнование

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

Однако на прошлой неделе я решил, что собираюсь бросить себе вызов. Я решил сделать что-то хорошее из работы из дома и выпустить пакет NPM для широкой публики в течение 7 дней.

Планирование успеха

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

Идея

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

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

Название

Отсутствие названия для проекта не является оправданием для того, чтобы не начинать. Без продукта или услуги для поддержки имя не имеет смысла. Это не значит, что я не ошибался в этом в прошлом, потратив дни на поиски идеального имени. Помните, что имя всегда может измениться — даже после релиза. Сосредоточьтесь на своем основном продукте/услуге и не отвлекайтесь на ненужные излишества. На самом деле, я бы предложил для начала выбрать слово наугад или даже число.

Пользовательский опыт и дизайн

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

Прототипирование

При прототипировании важно заранее определить потенциальные камни преткновения в вашем проекте. Создавайте прототипы этих элементов практически без дополнений и не увязайте в красивом оформлении прототипов — просто сосредоточьтесь на функциональности.

Рефакторинг

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

Документация

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

Уверенность в освобождении

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

Проект

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

Вывод

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

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

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

Если вы нашли эту статью полезной, пожалуйста, похлопайте ей и подпишитесь на меня на Medium и/или Twitter.