Вопрос по проектированию софта
Всем привет!
Я обычный программист город Тверь, никогда не проектировал софт и не был архитектором.
Но очень горю желанием сделать наконец уже свой серьезный проект.
Много раз пытался делать разные проекты, и пришел к выводу, что мне очень не хватает компетенции в сфере планирования и проектирования. Пока я знаю, что и как делать, то проект растет. Но без четкого плана на голом энтузиазме я держусь недолго.
Я надеюсь, что здесь есть люди, которые в этом разбираются, и которые были бы рады помочь неофиту.
В общем, я пришел к выводу, что мне нужно перед любой разработкой проследовать по такому плану:
Составить документы по 5 конкурентам, в которых перечислить:
- Функционал детально
- Страницы, пункты меню
- Entities и их поля
- Взаимосвязи, сценарии
- Какие есть роли
- Функционал по разным ролям
- Что редактируется, когда редактируется, кем редактируется
Смержить эти документы и получить MVP, в котором будет прописан функционал, entities and fields, взаимосвязи и сценарии, роли, функционал по ролям и т.д.
На основе выше полученного спроектировать базу данных.
Потом разбить на задачи по страницам, по сценариям, по ролям.
Детально прописать задачи, какие поля на странице, какие placeholders, опции селектов.
Заказать реализацию дизайна для каждой задачи.
Начать реализацию кода.
Подскажите пожалуйста, все ли я правильно понял, и может быть я что-то упустил?
Я бы сказал, что это неверный подход. Ключевые вещи в разработке программного продукта - это планирование и итерации. Алгоритм примерно следующий:
-1. Анализ конкурентов. Но не переписывание их пунктов меню, а выделение ключевых преимуществ их решений, главных фич, уникальных фич, а также ключевых недостатков, которые в вашем продукте будут исправлены)
0. Roadmap. План развития продукта, детализация должна быть минимальной, но достаточной, чтобы напротив каждого пункта можно было бы поставить трудоемкость в неделях и дату завершения.
0.5. Архитектура. Главное в архитектуре - это опять же минимализм. Архитектура должна помешать завести проект в тупик (например, выбрав неправильную технологию) и при этом не должна содержать деталей реализации (схема БД, например, совершенно лишняя)
1. Берется первый пункт из roadmap и декомпозируется на задачи по 1-2 недели, на каждый кусок назначается трудоемкость и дата завершения.
2. Реализуется верхняя задача
3. Актуализируется roadmap, если не уложился в ранее назначенные сроки
4. гоу ту 1