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

Question

[Alexander Lamdan]

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

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

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

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

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

Comments

[Антон]

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

[Alexander Lamdan]

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

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

[Антон]

Alexander Lamdan, у вас проблема в голове!
1. Придумывать идеи Вы можете бесконечно долго, еще хуже в процессе работы, когда приходится допиливать, согласовывать, изменять, переделывать. Отсюда вывод: строим четкие планы по принципу "не всё сразу", но с заложенным механизмом масштабирования проекта.
2. Долгое планирование в конечном итоге может сделать проект нерентабельным и неактуальным.

[Alexander Lamdan]

Антон, шикарный ответ. Спасибо Антон. Возьму ваш совет на вооружение

[Валентин]

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

Все зависит от того, поставило ли вам руководство KPI на загрузку ресурсов)

Answer 1

[grabbee]

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

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

Answer 2

[xmoonlight]

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

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

Answer 3

[Дмитрий]

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

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

Answer 4

[Владимир Коротенко]

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

Comments

[Валентин]

Оно хорошо для себя или для продуктовой конторы. К заказной разработке оно мало применимо.

[Сергей Горностаев]

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

[Валентин]

Сергей Горностаев, я думаю, мало кто использует (да и раньше мало кто использовал) чистый водопадили или чистый скрам (по крайней мере как это описывал это Сазерленд). Скрамом невозможно прогнозировать на долгий срок, он слабо применим к классическим проектам (например, если помимо разработки надо построить ЦОД, поставить оборудование и посадить людей). Зато он хорошо подходит к капиталомелким активностямс тиражируемым результатам, где основные затраты - ФОТ. НАверно, вопрос в балансе.

[Сергей Горностаев]

Валентин, согласен на все 100%

Answer 5

[Валентин]

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

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

P.S.

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

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

Comments

[javedimka]

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

Нормально ты сейчас унизил 99% контор в Российской Федерации

Answer 6

[Лентюй]

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