Программирование VS дизайн и вёрстка

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

Детальнейший прототип в Axure разработан. Все сценарии продуманы и написаны, документации куча...

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

А потом уже дизайн натянуть.

Программист, в целом, тоже так считает.

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

Когда она мне долго объясняет почему так надо - я соглашаюсь через какое-то время. Но проходит день-два - и я снова не могу понять почему нельзя дизайн потом натягивать🤪...

Ответ прост: потому что в cms уже есть default дизайн.

Я всегда тоже "оживлял дизайн" уже на готовых вёрстках т.к. там уже все элементы сделаны и больших изменений не будет. Можно работать точечно.

При конвейерной работе, по сути CMS уже есть или так скажем её "кубики", программисту делать ничего не нужно. А собрать их в кучку и запустить.

Но опять же это всё сферический конь в вакууме. Что у вас там в ТЗ, какие там мелочи знаете только вы.

Многие дела делать можно по разному. Если всё успеваете в сроки и всем удобно именно так работать, а менеджеру удобнее всё именно так контролировать, то возможно это и есть нормальная модель работы.

Зорро:), если у вас есть живой прототип и внятное тех. задание, то программист может начинать писать код не дожидаясь дизайна.

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

я уж не говорю про бэкоффис, в котором вообще уникального дизайна может и не быть. (мы, например, решили не рисовать для бэкоффиса что-то новое, а использовать для этого AdminLTE)

Есть и параллельный, более современный, вариант.

Нужно сделать SPA-фронтенд на любом из современных JS фреймворков типа Angular2, максимально перенеся логику на него.

А бэкенд использовать в качестве JSON-API.

К которому фронтенд будет обращаться для аутентификации/авторизации и получения данных из базы и сторонних API, а также результатов операций, которые лучше выполнять на сервере.

Но затевать такое есть смысл при бюджете на зарплату фронт и бэк -енд программистам от 150к рублей в месяц на руки каждому. Более доступные специалисты обычно справляются не лучшим образом, а хороших еще нужно поискать.

Дизайн для CMS обычно

либо прост с точки зрения логики отображения и взаимодействия с пользователем,

либо, как уже написал melkozaur, имеет стандартные заготовки для конкретной CMS и конкретного типа проекта.

Поэтому его добавление происходит быстрее.

Есть еще такой вариант.

Пока готовится фронтенд, аккуратно спроектировать базу, создать модели,

написать тесты к ним, моки для недоступных пока источников данных.

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

Ключевое слово здесь тесты. Они заменят фронтенд, на который разработчики любят поглядывать вместо написания тестов. Типа – "работает - не работает".

Здесь то же самое. Просто CMS обычно запрограммирована под определённый круг задач, и в этом круге в ней предусмотрено что надо и что не надо. А в Вашем случае программист ориентируется на конкретный сайт, при этом он должен иметь представление, что куда надо будет выводить средствами фреймворка. И для него в общем-то не важен графический дизайн, важно знать, что там будет с UI/UX и с контентом. А компоновку со стилями можно и потом натянуть. И более того, некоторые вещи в дизайне наверняка придётся переделать по итогам программирования.

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

Ну а дальше просто натягивается новый шаблон и все.

Этим и привлекательна разработка в цмс.

Можно.

Но Вы же пишете, что сейчас на этапе отладки. Он в любом случае будет.

Просто лучше сначала определится с дизайном, потом его сверстать и протестировать, а потом можно натягивать.

Меньше отладки будет.

Я же дизайн делаю сразу в html и сразу программирую, ибо делаю все сам. :)

Кстати, я сам себе и заказчик.

А так, заказчик не знает чего хочет, вот и куча правок выходит. :)

Можно распараллелить все это дело в три потока:

1. Рисуется прототип, по нему дизайн.

2. Cоздается архитектура БД, продумываются связи/индексы. Пишется RAML документация, на основе неё работает фронтенд и бекенд разработчики, пишутся приложения которые используют уже согласованный API.

3. По готовности верстки, она переносится в шаблоны, считанные часы.