alexander_lamdan
@alexander_lamdan
Тупа программист хехе

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

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

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

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

Обновление:
Для тех кто считает что я не пользуюсь MVC, Kanban, Agile, Time tracking, MindMap и так далее. Это не то.
Эти вещи используются когда уже есть макет или шаблон, черновик идей с набросками и тд.

Я имею ввиду до того как ваш проект перешел из стадии идеи в стадию разработки.
  • Вопрос задан
  • 676 просмотров
Решения вопроса 3
grabbee
@grabbee
По моему опыту - это две независимые стратегии. Нельзя пить горячий чай и жаловаться что обжигает. Равно как и холодный, и сетовать что не греет.
* Если вы копируете чей-то проект или бизнес-модель. Если вы делаете что-то, что у других уже давно работает. Если вы точно знаете что приносит доход, а на чем нужно сэкономить. Если на рынке уже есть аналогичные решения и они давно известны пользователям. Тогда только серьезный подход к планированию. Сырой продукт не взлетит.
* Если вы что-то придумываете сами. Если ничего подобного на рынке нет. Если только вы знаете, что нужно вашим потенциальным пользователям - начинайте хоть с деплоя пустого проекта черновика. Вас всё равно никто не знает Ваш продукт, никто не знает как им пользоваться. Ниша свободная и пока люди прочухают, что им этот ваш сервис нужен - вы успеете до альфа версии вырасти.

Проблема инди-разработчиков в том, что их планы могут не совпадать с требованиями пользователей. То что вы сделаете в "аналоговнет" проекте, просто может быть не нужно реальным людям. Вы считаете что нужно, а они вам докажут, что нет. И выбрасывать то, что находится в черновиках или альфе, гораздо легче, чем то что вы пол-года или год планировали и вылизывали.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
1. Быстрое создание архитектуры кода и построение диаграммы состояний для увеличения производительности за счёт параллельной обработки везде, где это возможно (5% проектного времени).
2. Можно ещё нагрузку промоделировать и выявить все возможные bottleneck. (+5%)

После, сразу же непосредственная работа: дизайн интерфейса, дизайн файловой структуры проекта, дизайн центрального хранилища, кодирование, тестирование, релиз, профит!
Ответ написан
@dimoff66
Кратко о себе: Я есть
Стоит ли тщательно обдумывать проект, архитектуру папок, файлов, дизайн, и так далее. Или все таки сразу приступить к программированию?

Стоит. Это экономит время. Когда ты один раз четко все продумал и понял что паззл сложился, далее воплотить это в код - вопрос быстроты стенографирования. Если нужно что-то показать клиенту, значит планируем как в первую очередь сделать то, что будет иметь не весь функционал, но может быть показано клиенту.
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
firedragon
@firedragon
Senior .NET developer
Вы используете водопад. Я кстати его рекомендую. Сэкономите деньги. Гибкое программирование оно хорошо, но повышает стоимость разработки в разы
Ответ написан
vvpoloskin
@vvpoloskin
Инженер связи
Все сильно зависит от горизонта вашего проекта, в том числе по срокам, от бюджета и рисков, от охвата реального мира за пределами программирования, от доверия исполнителям и влияния на них (чьими силами делаете - своей организации или подрядчика).

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

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

Это не проект. Может быть хобби, улучшалка, обучение, но не проект.
Ответ написан
BojackHorseman
@BojackHorseman
...в творческом отпуске...
а ответа на этот вопрос просто не существует. ничего не лучше
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы