У меня есть один друг. Назовём его, изменив его имя, например, Сергей.
Сергей далёк от профессионального программирования. Очень далёк. Не важно кто он, но допустим, пусть будет учитель. И вот, Сергей, в силу некоторого интереса в программировании, решил запустить в интернете некоторый стартап, а в силу того, что Сергей учитель, для школьников.
И вот он учится программировать, создавать различные веб-приложения, и по мере изучения, создаёт свой проект. Точнее, не совсем создаёт. Он начинает что-то изучать, потом в силу того, что у него что-то не выходит, он не знает что ему делать дальше или в силу того, что он разочаровывается в своём детище, он сразу же бросает свой проект, не сделав ничего существенного. Это было бы не страшно, если бы он не делал так на протяжении уже десяти лет.
Помню, когда я был ещё студентом, на первом курсе нам рассказывали про циклы разработки, кажется, что они нигде толком не понадобились, но моему другу не хватает именно этого знания. Но ни в одном учебнике по программированию, ни в одном курсе, нет такой информации. Быть может, именно этого ему не хватает? Или ещё какого знания, которому уделяют мало внимания? А может всё из-за того, что он учитель и проф. деформация мешает ему?
Очень хочется помочь своему другу и главное, себе, часто, когда работаю над какими-то собственными проектами случается так, что многое из того, что хочу создать, я бросаю, не знаю куда дальше идти или понимаю, что слишком зарылся в частности, совсем позабыв о каких-то более общих и важных вещах. Может, у Сергея такая же проблема?
Как правильно подходить к созданию своих собственных проектов, особенно, если работаешь не в команде, а один?
Проект не надо заканчивать. Его надо запускать как можно быстрее и потом итеративно развивать.
Не удивительно, что ни в одной кинги по программированию про это не пишут. Ведь к собственно навыку написания кода это отношения не имеет никакого.
Думаю, чтобы его как можно скорей можно было запустить, его нужно для начала как можно скорей создать. А с этим проблема. Я ведь говорю, у Сергея проблема даже в атомарных частях проекта.
Как можно скорее нужно создать Минимально Жизнеспобоный Продукт. Это будет где-то полпроцента от того продукта, что задумал ваш друг. Вот его надо запускать быстро, а потом уже наворачивать на него все свистелки.
Ну и не стоит забывать, что не каждому проекто суждено быть запущенным.
Проект в управленческой деятельности (соответствует англ. project от лат. projectus «брошенный вперёд, выступающий, выдающийся вперёд») — временное предприятие, направленное на создание уникального продукта, услуги или результата (см. PMBOK)[3]:3.
С проблемами надо бороться, а не отворачиваться от них. Ваш товарищ трус и/или лентяй, поэтому вместо того что бы решать проблему, просто прячет голову в песок.
А может всё из-за того, что он учитель и проф. деформация мешает ему?
плохому танцору ...
Как правильно подходить к созданию своих собственных проектов, особенно, если работаешь не в команде, а один?
При чем тут проект? Я так понимаю, что так, со всеми начинаниями у Сергея. "Не знаю как" - "ищу отмазку почему не делать". Не о проектах надо думать, а о подходе к жизни в принципе.
Не зря на ту или иную должность берут определенных людей. Не каждый может быть менеджером проекта, потому что надо встречать проблемы грудью и ломать им ноги, что бы больше не ходили в эту сторону.
artshelom, MMP — minimal marketable product (он же в некоторых статьях minimal sellable product). Такой минимальный набор возможностей продукта, за который люди готовы платить.
Потому что программист, менеджер проекта, бизнесмен-стартапер - это все разные профессии, для которых нужен свой комплект навыков, знаний и опыта.
Цикл разработки не для того, чтобы закончить проект. Цикл разработки для того, чтобы быстрее выпускать новые версии продукта. И да, совершенно естественно, что такая информация отсутсвует в учебниках по ИНФОРМАТИКЕ или ПРОГРАММИРОВАНИЮ, это ближе к менеджерам.
Но менеджеры и бизнесмены тоже не всегда могут взлететь со своим проектом или своим бизнесом.
1. Нужно иметь представление принципа работы сайта и знать (хотя бы CMS! или) язык программирования для возможности изменения логики.
2. Научиться идти от простого к сложному: от выявления логических взаимосвязей между сущностями до написания кода, реализующего всю логику.
Прежде чем делать свой веб проект нужно хотя бы примерно посчитать сколько денег он будет приносить и как будет осуществляться монетизация.
Многие проекты закрываются из за того что не приносят прибыль поэтому становятся неинтересны создателям.
Если с этим проблем нет, то потом наступает этап проектирования и выбора технологий.
Если технологии выбрали, то потом проектируется API, либо с помощью swagger(OpenApi) либо просто markdown в блокнотике или кому как удобнее.
Когда API готово, то проектируется БД.
Когда проектирование API и БД готово начинается непосредственно разработка.
Начинать программировать когда проект API или БД не готов плохая идея т.к. по мере программирования может выясниться что где то что то не так или чего то не хватает, хотя это можно было выяснить на этапе проектирования.
P.S. Для изучения этой темы подойдет любая книга по Software development life cycles . На русском Жизненный цикл программного обеспечения. Есть ГОСТ на эту тему.
Евгений Шустрый, это больше экономический вопрос, т.е. нужно посчитать предполагаемую прибыль, расходы, чистую прибыль и т.д. как описано в учебниках экономики.
В интернет бизнесе основной доход либо от показа рекламы, либо от оплаты со стороны клиентов сервиса.
В случае с рекламой нужно считать доход от рекламы, в случае с платным сервисом нужно считать доход от клиентов.
К проекту надо подходить с охотой, хотением чего либо достичь, я к примеру разрабатывал торговую площадку для игры, на тот момент я даже не думал смогу ли я создать ее вообще, у меня просто была цель, если что то не получалось, пробовал импровизировать своими средствами, уж если совсем плохо то ГУГЛ, слегка подрос в разработке и понял что моя площадка, это костыль, ибо написание местами было ужасное, в общем вывод из всего этого, делая проект ты получаешь знания и развиваешь навык программирования, главное не отступать, идти к поставленной цели с поднятой головой :)
Очень мало людей могут довести проект в одиночку. Почитайте Ицхак Адизес, про 4 типа людей необходимых в каждом проекте. Очень сложно содержать в себе одновременно и инь и янь (это не у него, я от себя).
Ищите единомышленников, которые будут дополнять то чего не хватает у вас.
Для начала нужно подписаться/скачать видео курс по выбранной технологии. Их море на Udemy, Pluralsight, Lynda.
Большинство современных курсов обучают технологии в форме создания одного законченного проекта. И нужно проделать этот проект на своей IDE. Прямо один в один: диктор напечатал "vааdin-grid-cоlumn width="60px" flеx-grоw="0"". Ставите видео на паузу и впечатываете эту строчку в своей IDE. Важно именно напечатать, а не скопипастить: так ваши руки запомнят, что нужно делать.
К концу курса у вашего друга уже будет один законченный проект. И когда он примется за свой проект, у него уже будет и опыт, и побольше уверенности.
А дальше как и советовали: выпускаем пробную версию продукта, смотрим на реакцию рынка, дорабатываем...
Исходя из вашего описания я вижу 2 причины, которые мешают вашему знакомому доводить проекты до конца:
1) Он пытается все делать в одиночку, при этом не являясь специалистом. Это крайне неэффективный путь. К примеру, если там нужно программирование, а он не программист, то нужно найти единомышленника программиста и т.д. Тогда проект не будет заходить в тупик из-за некомпетентности.
2) Похоже на то, что ваш знакомый по складу характера - исследователь. Т.е. ему нравится начинать новые проекты, изучать что-то новое. Как только стадия "узнавать новое" сменяется стадией "пахать", такие люди сдуваются и быстро находят новую идею, которая их вдохновляет. Если мое предположение верно, то ему нужно либо найти деятельность, связанную с исследованиями, либо людей, которые будут реализовать его идеи (см. п.1).
заметил за собой обе черты. можно где-то поподробнее почитать?
хотя первое есть, но не мешает - всему можно быстро научится. Путь интересный, но не продуктивный конечно.
Про первое - это все, что касается делегирования. Это самый кардинальный способ повышения эффективности. Ищите по этому слову. У меня только платный курс по этой теме.
По второму, можете покопаться в соционике. Определите свой социотип, почитайте рекомендации.
