кстати про архитектора, помню свою первую встречу с архитектором лет 15 назад . Он имел очень подробную схему ПО, а мы были программерами. Ни контроля ни соответствия ПО разработанной заранее архитектуре не было и в помине, вся его работа была виртуальной и бесполезной, да он и не пытался хоть что-то контролировать.

Были ли у него на это полномочия и инструменты воздействия?

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

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

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

Так даже если нету формальных методов влиять на разработку, разве нельзя общаться с командой и разработывать свою схему в соответствии с реальностью?

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

"Мы все сделали правильно, оцтань от нас"

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

Но зачем самому провоцировать конфликт?

Иными словами, если нет возможности вправить менеджеров, чтобы выстроить норм сотрудничество, то это фатальная история.

Ну вот есть команда разработчиков с принципом "и так сойдет". Формальных полномочий нет, инструментов нет.

Ваши действия?

Тимлид такой же как и разработчики. И так сойдет, а тестеры вообще непонятно зачем нужны, только жизнь портят

И еще эти, как их там, сисадмины чот говорят, но кто их слушает, этих чернорабочих менятелей картриджей

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

Наверное, я как-то немного иначе говорил. Например, что хороший способ приведения разработчика/аутсорсера во вменяемое состояние из невменяемого состоит в наличии у архитектора альтернативных вариантов реализации. Речь, конечно, про solution architecture.

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

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

можно пример желаний админов, которые влияют на решения разрабов - докеры/шардирование?

скрипт деплоя в 10 тысяч строк на питоне, который падает 3 раза из 10

ух бля (с)