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

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

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

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

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

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

Виталий Науменко

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

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

Все дополнительные работы начинаются с технического задания (ТЗ). После покупки коробки с вами продолжит работать тот же менеджер, который проводил сделку. Это удобно, потому что не нужно ничего повторять. Например, со мной работал Алексей Гуржиев.

Напишите в Word все ваши пожелания. Можно использовать простой язык, менеджер всё равно уточнит детали и внесёт необходимые изменения. После того как вы отправите ТЗ, менеджер внесёт все задачи в CRM-систему, к которой у вас уже есть доступ. Я пришлю договор на дополнительные работы, и процесс разработки начнётся.

Игорь Симонян

Спасибо за ответ, очень подробно расписали, но мне интересно как проходят сами процессы, не обязательно в ДСТ, а вообще как это обычно бывает в целом у всех, для общего так сказать развития и понимания 

Виталий Науменко

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

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

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

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

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

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

Металл Профиль

А какая собственно разница, мы например внедряли в DST Portal стриминговый сервис и видеоканалы, это тоже огромные компоненты, просто пишите длинное ТЗ вместе со своим менеджером и затем создаете много, много прототипов, далее идет разработка.