Всем привет!
М. б. кто-нибудь в курсе про какой-нибудь фриланс в архитектуре?

Нет проблем. Нужно просто знать достаточно потенциальных заказчиков. А так чтобы на Youdo - нет.

Внесу свою лепту наверное.

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

Третья волна появляется в момент, когда сервис надо переработать и добавить функциональности. Обычно через несколько лет.

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

Я не говорю, что так всегда надо делать, но во многих проектах, которые я видел, стоило бы делать именно так.

https://youtu.be/oDNz9hXpT90?t=52

нашествие из изоляции...

За вашими душами... Бгг.

Архитекторы бровей тут уже были, но архитекторы судьбы — впервые.
Добро пожаловать!

Благодарю) шибко отсвечивать не буду. Больше в изучательных целях пока тут.

На тему вчерашнего обсуждения,
“закон дяди Боба”

If we are doubling every five years then we always have half the programmers with less than five years experience which leaves our industry in a state of perpetual inexperience.
“Uncle” Bob Martin

Организации внедряют scrum, SAFe, etc в первую очередь для масштабирования. Еще больше проектов одновременно.
Нужно еще больше инженеров, а где их взять? Приходится брать что есть.
Получается, что естественные ограничения “классического” управления сдерживали рост организации,
за счет этого в ИТ было большее количество квалифицированных инженеров с большим опытом работы.
В быстро растущем “agile enterprise” неуклонно падающая квалификация инженерных кадров есть главная проблема.
Нас ждет формирование новых ролей, в частности, по примеру SAFe, выталкивание квалифицированных кадров на другие уровни организации, на уровень программы, на уровень портфорлио.
И, конечно, knowledge management становится острой необходимостью.

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

Ценная мысль

Макс, слишком радикальное утверждение, не любое) далеко не любое

Скрам - это вообще не про масштабированиание, про масштабирование всякие SoS, SAFe, LeSS

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

Когда желание возразить превышает желание понять - легко скатиться в банальность суждений.

Я к тому, что отсутствие скрама не является сдерживающим фактором для роста организаций.

- Люди кладут сахар в еду, чтобы было вкуснее.
- Отсутствие сахара не является сдерживающим фактором для приготовления вкусной еды.

Где тут противоречие?

Поаккуратнее надо с кванторами, множествами и логикой.

Я спорю с утверждением "Получается, что естественные ограничения “классического” управления сдерживали рост организации,"

В оригинальном изречении классическому управлению как раз и противопоставляется scrum и SAFe