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

Вообще то нет ) и это прописано в инструкции по сигнализации на жд транспорте )

ну возможно, просто встречал что кто-то использует семафоры, но светофоров там и правда куча

Более того локомотивы бывают из нескольких секций.  Есть локомотивы в подталкивании. Есть сдвоенная тяга )

плохо, что ты не слушаешь тех, кто уже работает

Не понимаю вас. Без ТЗ программист работать не может. Он даже пальцем не шевельнет. Две недели, плюс две команды - это как же без ТЗ? А если мелкие правки какие, типа цвета кнопки или еще что, ну, конечно, на месте быстро как-то можно решить. Но уж точно ничего глобального.

Посмотрим как быстро тебя уволят с таким подходом )

(Есть мнение что вы плохо умеете в взаимодействие с людьми)

ТЗ это про систему в целом, никто вам не будет писать ТЗ под задачу на пол дня

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

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

С каким конкретно подходом? Ведь не прозвучало, как именно решается глобальная проблема именования переменных в отрасли. Вот я и придерживаюсь мнения, что такой проблемы просто нет. Я предложил формализовать алгоритм решения этой проблемы. Вместо этого вот мы обсуждаем все вот это. А оно ни к чему привести не может. Я вам стал про ТЗ. Тоже не нравится. А как тогда решать-то? Значит, нет проблемы такой. Если она не решается. Или нерешаема, то ее нет.

Вот и славно

Как-то ваше описание не описывает вас

Или не соответствует действительности

😅😅

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

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

Формализация бизнес процессов все равно должна быть. Если мы говорим не о цвете кнопочек и очередном бдсм-шопе

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