Что лучше: долгое планирование проекта до мельчайших деталях или прямая разработка без плана и макетов?
=========================================================================================================

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

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

  

Что делать если это проект который может помочь бизнесу, а разработчик один(например я)?  

Как тут быть? Стоит ли тщательно обдумывать проект, архитектуру папок, файлов, дизайн, и так далее. Или все таки сразу приступить к программированию?   

  

Кто нибудь считает что путь планирования с макетами лучше и продуктивнее, чем сразу взять и программировать?  

  

Обновление:   

Для тех кто считает что я не пользуюсь MVC, Kanban, Agile, Time tracking, MindMap и так далее. Это не то.  

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

  

Я имею ввиду до того как ваш проект перешел из стадии идеи в стадию разработки. 

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

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

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

  

Проблема инди-разработчиков в том, что их планы могут не совпадать с требованиями пользователей. То что вы сделаете в "аналоговнет" проекте, просто может быть не нужно реальным людям. Вы считаете что нужно, а они вам докажут, что нет. И выбрасывать то, что находится в черновиках или альфе, гораздо легче, чем то что вы пол-года или год планировали и вылизывали. 

 1. Быстрое создание архитектуры кода и построение диаграммы состояний для увеличения производительности за счёт параллельной обработки везде, где это возможно (5% проектного времени).   

2. Можно ещё нагрузку промоделировать и выявить все возможные bottleneck. (+5%)  

  

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

**Стоит ли тщательно обдумывать проект, архитектуру папок, файлов, дизайн, и так далее. Или все таки сразу приступить к программированию?**  

  

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

 Вы используете водопад. Я кстати его рекомендую. Сэкономите деньги. Гибкое программирование оно хорошо, но повышает стоимость разработки в разы 

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

  

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

  

P.S.   

> Что делать если это проект который может помочь бизнесу, а разработчик один(например я)?

  

Это не проект. Может быть хобби, улучшалка, обучение, но не проект. 

 а ответа на этот вопрос просто не существует. ничего не лучше