С чего начинается Frontend & Backend разработка?

Я знаю, что все начинается с общения менеджеров с заказчиками, меня интересует немного другое, а именно работа backend разработчика и frontend.

Предположим, менеджеры с заказчиками все обсудили, договорились, работа передается дизайнеру, он(а) создают прототипы и т.д. В какой-то момент макет готов полностью, и передается frontend/backend разработчикам.

И тут я не совсем понимаю, есть макет и исходя из этого макета backend и придумывает структуру хранения данных в БД, или как оно работает?

Дополнительно:

менеджеры с заказчиками все обсудили, договорились

Так не бывает. Обсуждение и попытки договориться не прекращаются до самого конца проекта.
Проще вам на работу устроиться - увидите весь кошмар своими глазами.

Такое дело, зависит от команды и выстроенных процессов.

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

Про сами процессы:
Если пишет один человек, проще сначала сделать бекенд, потом писать фронт под готовое апи.
Если пишут два человека, можно создать апи-пустышку с захардкоженными данными, тогда одновременно работать могут начать и фронт и бек специалисты. Ставят такую заглушку, если бекенд делается долго, надо данные откуда-то еще перекачать или еще какие сложности, обычно быстрее сразу просто апи сделать.
В некоторых командах контракт согласовывают бек и фронт вместе (или кто-то главный над ними, который раздает потом задачи).
Иногда на фронте процесс выстроен таким способом, что пишутся тесы (не шутка). Там делаются моки запросов к апи и фронт пилится в отрыве от бекенда. Контракты, разумеется, должны так же совпадать

Имея контракты, можно придумать и архитектуру данных, как все по таблицам распихать, и архитектуру фронта, где как что будет получаться и храниться

• Вот это уже ближе к делу, спасибо!
  

  Если пишет один человек, проще сначала сделать backend, потом писать фронт под готовое апи.

  Да я один хочу backend осваивать, express подучил немного и больше nodejs, сейчас взял макет (нашел в интернете приложение како-то), и думаю, а как в целом сделать модель данных, на данный момент у меня доступен только макет, получается данные для базы данных мне придется брать только из макета ?

  Но в целом вроде картина вырисовывается.

• sowefap339, Как проектировать БД немного другой вопрос, чем больше этим будешь заниматься, тем с каждым разом быстрее это будешь делать.
  Обычно есть бизнесовые поля - это то, что видишь на прототипе. Тебе их как-то надо разложить по разными таблицам, обычно так, чтобы не было дублей. Это вопрос нормализации данных, часто пишут заумными словами, но суть там обычно простая, данные и связи не должны дублироваться, это порождает аномалии (почти как в сталкере)
  Помимо бизнесовых полей добавляются технические, какой пользователь создал запись, дата создания, может аналогичные с датой последнего изменения и последним пользователем. Даты могут быть или дублироваться по utc, если сервис кантри-агностик (в разных часовых поясах)

  Я не пробовал, подруга занималась, какие-то управжнения по базам https://sql-ex.ru/?Lang погляди

• Виктор П., спасибо, пойду тогда модели создавать глядя в макет)))

Ответы:

С чтения ТЗ. Ну либо с его написания.

• А кто их в команде обычно пишет ?
• sowefap339, может составлять менеджер проекта совместно с заказчиком. Вот физически сидят и на бумажке пишут все "хотелки" заказчика. Затем менеджер проекта превращает этот поток бреда во что-то более менее понятное команде, с учетом технологий и прочего.
  После этого ТЗ отдаётся НА ПОДПИСЬ заказчику, очень важный момент! И только потом начинается работа.
• Антон Р., бреда это мягко сказано)
• Антон Р., получается макет не главный, главный у нас ТЗ. А что делать если нету ТЗ, и хотелок заказчика, есть только макет и все. Тогда как быть мне, создать структуру бд исходя из макета ? (я backend немного начал изучать, нашел макет, а дальше что делать не знаю)
• sowefap339,
  
  

  и хотелок заказчика, есть только макет и все

  Тогда делаешь так как считаешь правильным, раз нет подписанных со стороны заказчика документов.

  как быть мне, создать структуру бд исходя из макета?

  А ты и за бэк отвечаешь тоже?

• Антон Р., да, учусь вот.

есть макет и исходя из этого макета backend и придумывает структуру хранения данных в БД

Эти вещи довольно слабо связаны. Обычно как и ответили выше, читают ТЗ и из него уже примерно понимают, что нужно системе. Дизайн может повлиять на пару таблиц, из которых можно будет получить даные и то не факт.

С боли и страданий.

Если схематично, то как-то так:
User flow / UX -> wireframe -> tech. design -> API contracts (OpenAPI) -> front-end + back-end (параллельно, начиная с API mocking).

Весь цикл разработки должен происходить итеративно, с поправками. Невозможно продумать всё до мелочей.
Разработаете прототип по этой схеме и продолжаете наращивать функции, по не будет достигнут MVP.

Добавлено:
И важно понять - ТЗ обычно не бывает, ибо всё делается на ходу. ТЗ это больше про средне-крупные организации, которые могут себе позволить это, теряя в скорости и делая упор на точность и соответствие по контракту.
А с макетами уже вполне можно работать в малых командах.

• У нас так, студия, и как хочешь так и делай сказали, но я не backend я верстаю обычно. Сейчас вот чтобы лучше понять весь процесс решил и nodejs по изучать.