А что это означает?

Плюс:
ТЗ вы составили первоначальное?

А школа по изучению чего?

Как разработка будет вестись, вы сами - посредник ?

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

Не начальное, а полное. Естественно.
Но, мнение разработчика в ТЗ всегда очень важно.

Что вы подразумеваете под словом "как"?
Я сам выступаю в роли координатора всего проекта. Сам занимаюсь разработкой в иной области.

Одним словом: продукт должен не только решать поставленные задачи, но и быть именно тем, который нужен.

Так что, фреймворки что ли не использовать?
В веб разработке как раз наоборот не приветствуется велосипедостроение, когда вместо использования проверенного (и поддерживаемого) пытаются писать все свое.

Ну это все вопросы из темы DevOps-а.
Где хостится, где тестовые версии, где продакшн, сколько чел в команде, кто ими управляет, трекеры задач, какое воркфлоу выбрано в гите, управление ветками, фичами, кто принимает пулреквесты, как это потом будет с версткой/дизайном сливаться и т.д.

Или вы это все на ответственность вот этого человека оставляете, чтоб он один разрабатывал, а вам просто показывал что сделано?

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

Ну это дело вкуса каждого и не более того.
Но, нужно понимать, что чистого веба здесь не так и много.

Сейчас коллектив под проект только собирается. Видение следующее
На каждой позиции один человек
- бэкэндер
- бэкенд математики бота
- дизайнер
- фронтэндер

Оптимальней, на текущий момент чтобы бэк и фронт были связаны через приватное апи (ajax / socket), ибо весь дизайн будет строится в стиле нативного приложения.

Нагрузка на первом этапе крошечная - 500-1000 юзеров в онлайне.

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

Есть важный момент. Часть заказчиков предпочитают решать важные вопросы лично. Это не столь сложная штука, но весьма важная

Ну главным образом, конечно, бизнесом не приветствуется, обычно! =)

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

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

Все хорошо на своем месте. И уж точно не стоит переубеждать ТС, пытаясь навязать свою точку зрения. Советы конечно хорошо, но не в ключе

В какой именно веб-разработке? Я, допустим, знаю и другую, с противоположным мнением.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Кстати ИМХО что велосипедисту проще осваивать широкий круг инструментов, нежели тому кто всю жизнь не изобретает, а пихает битрикс везде к примеру. Потому что велосипедист он много возился с низкоуровневым кодом, с основами, много подглядывал, выбирал. Много раз менял мнение и переписывал, такому проще решать нетипичные задачи и проще соглашаться с новым code style коллектива или новомодного фреймворка имея при этом свою обоснованную, набитую шишками позицию. Вообще умение идти на компромиссы это супер важный скилл как для начальника, так и для подчинённого.

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

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

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

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

Да откуда ты знаешь в каком ключе они думают о будущем? Может на самом деле их бизнес не хотел подобных затрат, но просто вынужден по ряду причин. Например, из-за конкурентной борьбы, сейчас условный гугол заюзает открытую либу, а ее фигак и купят конкуренты под шумок. Значит либо им самим выкупить права, либо своё производить. Возможен подобный сценарий среди средних предпринимателей (тем более мелких)? Скорее всего нет. Поэтому зачем эти сравнению с крупными игроками, поясни?

Да какие там синонимы))) Тот же Yii (да и Лара кстати) основаны на AR, что изначально противоречит принципу SOLID. А повторю, 90% функционала этих фреймворков завязаны на Active Record. В итоге получается куча слабодокументированной и сильносвязанной лапши, с чем изначально вроде как и призвано бороться ООП.

В итоге имеем тру, как ты говоришь, специалистов по синтаксису и правилам конкретного фреймворка, которые вообще не мыслят, как можно сделать что-то иначе. Я с этим жестко столкнулся по долгу службы, попытавшись внедрить DataMaper вместо AR. Поплыли ребятки, имеющие по 5-7 лет стажу на Yii.

Именно притом. Программисты пишут программы, сиречь велосипеды в твоем понимании. Кодеры пишут коды, эти программы соединяющие в какой то один проект. Ну это мое ИМХО, если легче станет.

Что касается крупного бизнеса. Плох тот солдат, который не хочет стать генералом. Но дело даже не в этом. Что за градация такая, мелкий, крупный, средний. В чем измеряется? В величине кодовой базы, количестве пользователей, валовом обороте или еще в чем? Можно быстренько сляпать пару лендингов и заработать миллионы, а можно развернуть проект на овердохрена фреймворков и разных готовых либ и потерпеть фиаско.

Я говорил не о величине, а о качестве. О том, как этот проект будет чувствовать себя долгие годы своей жизнедеятельности. Мы же хотим долгих лет своему проекту? Ведь собранный из чужих решений, он становится их заложником. Либа может запросто перестать поддерживаться и устареть. А может еще хуже, поменять концепцию, как было со знаменитым Пимплом. Или в ней обнаружится уязвимость, которую долго не исправят, как было с PhpMailer к примеру. А может вообще все испортиться из-за отсутствия обратной совместимости, как с тем же Yii2.

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

Я не говорю, что это лучше всегда. Нет. Для быстрых сиюминутных решений чужие либы - что доктор прописал. Я просто не могу спокойно смотреть на то, как люди, обжегшись на молоке, дуют на воду. А что еще хуже, заставляют дуть других. Так ведь чаще они и не обжигались, а просто выучили мантру: так делают все!

Не все, не нужно врать.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.