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

Определения

Но сначала несколько определений.

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

Опасность

Популярная викторина: какая самая большая опасность стоит перед вашей PSP?

  • а. Быть плохим продуктом
  • б. Плохой дизайн
  • c. Имея 0 тяги
  • d. Зарабатывая столько денег, ты сходишь с ума

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

Самая большая опасность, с которой сталкивается ваш побочный проект, - это отказ

Почему вам стоит закончить свой проект

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

Я заметил повторяющуюся закономерность в своей мотивации работать над чем-то.

  1. Меня что-то очень волнует, и я начинаю над этим работать.
  2. Работаю над ней около месяца, а может и двух.
  3. Проект усложняется, я не могу разобраться в правильном дизайне, прогресс замедляется. Мне скучно.
  4. Меня очень волнует что-то еще, и я готов переключиться. На этом этапе я обычно выхожу из проекта, говоря себе, что вернусь к нему позже, но это случается редко.

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

Ваш проект может достичь большего успеха, чем вы думаете, или даже стать источником дохода. Вы никогда не узнаете, если не раскроете его там. Создавая приложение для изучения языков Flamingo French, я думал, что оно будет довольно успешным. Не было.

Но потом у нас возникла идея протестировать некоторые языки, которых на самом деле не существует, и результаты оказались неожиданными:

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

Пока вы не завершите проект, вы, скорее всего, сильно недооцените объем работы, необходимой для его завершения. Вы думаете про себя: «В основном это сделано, просто нужно немного доделать». На эти последние штрихи может уйти больше времени, чем на его создание!

После того, как я закончил создание своего приложения для утренних страниц Blurrish (созданного с помощью электронов и vue), я решил загрузить его в магазин приложений Apple. Он уже работал на Mac, поэтому я подумал, что публикация в магазине приложений займет пару часов. Это заняло у меня неделю! (мне пришлось переписывать большие части кода из-за проблем с песочницей и подписью приложений). Я мог узнать это, только если попытался опубликовать приложение в магазине.

Я перефразирую Дэвида Гоггинса здесь:

Если вы думаете, что проект готов, он готов на 40%.

Вы узнаете это на собственном опыте.

Как завершить свой сторонний проект

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

Сдерживайте себя, чтобы не напрягаться

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

Ограничения имеют решающее значение. Наличие хорошего набора ограничений ограничивает бесконечное количество возможностей и даже делает вас более творческими.

Поскольку мы обычно воспринимаем ограничения как негативные, давайте добавим греческий префикс «eu» (как в euphoria, а не в Европейском союзе), чтобы напомнить себе, что они хороши.

Источник: викисловарь

К счастью, у нас есть некоторые ограничения, встроенные в определение PSP, и это именно то, что заставляет нас проявлять творческий подход. Мне нравится называть вещи, чтобы помнить об их важности. И еще мне нравятся аббревиатуры. Входит SCRUF.

SCRUF - простой, дешевый, многократный и быстрый

Метод SCRUF (никогда не упускайте возможности изобрести новую аббревиатуру) показывает самые важные ограничения для побочного проекта, который вы завершите:

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

Чем выше скорость записи каждого продукта, который вы публикуете, тем выше вероятность, что вы преждевременно отключите его. Используйте бесплатные услуги или услуги, стоимость которых начнется только тогда, когда ваш продукт будет приносить доход. Я думаю, что скорость сжигания 10–20 долларов в год - хорошее число, к которому нужно стремиться. В основном платите только за доменное имя (если оно вам нужно), а для всего остального используйте бесплатные вещи. Цель состоит в том, чтобы иметь несколько проектов, которые могут работать достаточно долго, чтобы убедиться в их успешности. Возможно, вы думаете, что платить 20 долларов в месяц - это немного, но если у вас работает 5–10 сторонних проектов, это может сложиться. Некоторые предложения по сокращению затрат:

  • Нет выделенного почтового сервера / GSuite. Вы можете настроить GMail для отправки и получения писем с адреса [email protected].
  • Используйте Netlify вместо Heroku для размещения вашего общедоступного веб-сайта - SSL предоставляется бесплатно.
  • Домен - получите самую дешевую версию - не должен стоить дороже 10–20 $.
  • Начинайте платить за обновления и надбавки только тогда, когда получаете прибыль.

СУХОЙ - Не повторяйся, самое фундаментальное правило программирования. Может быть, даже определение программирования. Не повторяйте свою собственную логику и не повторяйте работу других людей без надобности.

Несколько предложений:

  • Сделайте его кроссплатформенным. Используйте кроссплатформенные библиотеки, такие как cordova, react native или electronic. Создание и поддержка двух отдельных кодовых баз для Android и IOS или Mac + Windows + Linux - огромная трата времени (и огромное нарушение DRY).
  • Используйте структуру пользовательского интерфейса - вместо того, чтобы изобретать CSS для компонентов пользовательского интерфейса, которые многие люди использовали раньше, используйте структуру пользовательского интерфейса. Если новый потрясающий пользовательский интерфейс не является основной функцией вашего продукта, лучше потратить время на другие области, чем css. Вашему приложению действительно нужен пользовательский CSS, на создание которого вы потратите неделю? Ваши пользователи действительно заботятся?
  • Стартовый проект - потратьте время на поиск хорошего стартового проекта, например, Проект Vue, запущенный в приложении Cordova с Quasar UI Framework. Это сэкономит массу времени на сборку и создание хорошего процесса разработки. (Перед выбором проверьте компоненты и производительность стека и инфраструктуры пользовательского интерфейса в вашей ОС TARGET.)

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

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

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

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

Чтобы действовать быстро, нужно быть безжалостным. Отрежьте все, что не на 100% необходимо для использования первой версии. Хорошие примеры:

  • Вырезать серверную часть. Если вы сделаете приложение бессерверным, это не только сэкономит около 50% времени разработки на написание и отладку серверного кода, но и значительно упростит ваш клиентский код. Я не знаю, есть ли какие-то данные, подтверждающие это, но, по моим оценкам, вы сократите около 70% рабочей нагрузки, если сможете сделать свой проект бессерверным (я не имею в виду serverless.com, но фактически бессерверным. Как и в серверах вообще нет). Это не всегда возможно, но помните, что жесткие ограничения заставляют вас проявлять творческий подход и могут в конечном итоге дать вашему продукту преимущество над конкурентами.
  • Сокращение систем управления пользователями и входа в систему. Является ли профиль пользователя основной функцией, без которой ваше приложение не сможет работать? Если нет, отрежьте. Вы всегда можете добавить его позже.
  • Вырезать модульные тесты. Да, я только что это сказал. Стреляй в меня. Модульное тестирование - это не евангелие, и в нашем случае накладные расходы не окупаются. (Если ваш побочный проект не является приложением для регулирования температуры для ядерных реакторов. Тогда, пожалуйста, напишите модульные тесты.) По мере роста сложности вашего проекта и увеличения размера вашей команды вы можете захотеть добавить модульное тестирование или другую форму автоматического тестирования, но пока пропустите это. Если SO может справиться с очень небольшим количеством модульных тестов, то и ваш небольшой простой побочный проект тоже. Конечно, если у вас есть суперкритический фрагмент кода, вы можете защитить его от регрессий или ошибок с помощью модульных тестов. Я применил логику шифрования журнала этого пользователя в Blurrish, потому что повреждение записей журнала непростительно.

Резюме - рабочий процесс высокого уровня

  1. Выберите проект, используя SCRUF, чтобы убедиться, что он «завершен». Не выполняйте одновременно несколько задач, по одному проекту на этапе 1.
  2. Опубликуйте первую версию. Получите это там.
  3. Маркетинг, анализ, обратная связь - это может продолжаться при запуске следующего проекта.
  4. Поддерживать, расширять или отбрасывать - стоит ли над этим проектом работать больше? Если так, то отлично. Если нет, оставьте это и переходите к более интересным вещам.
  5. Повторение

У вас есть сторонние проекты, которые вы никогда не завершали? Сколько времени обычно у вас уходит на завершение стороннего проекта? Хотелось бы услышать отзывы / мысли :)

Первоначально опубликовано на https://www.learningsomethingnew.com/how-to-finish-your-side-project .