Вот да, реальное решение проблемы — это архитектурно правильное выделение сервиса. А массовое решение — это «все переводим на микросервисы». В результате лет через пять (а может и уже) от них начнут перебегать к какой-нибудь новой модной технологии.
Пожалуй, Вы правы, первоначально методологии создания больших программных систем были позаимствованы из «хардварных» проектов, с их обязательными задержками по поставкам комплектующих и (взамен) работоспособностью комплектующих. В программировании же «сборка» проекта из готовых модулей стала работать только в последние десятилетия (когда появилось достаточное количество таких модулей-библиотек). А до этого приходилось фактически каждый раз создавать кабеля, балки и фермы заново, с непредсказуемой работоспособностью. В результате методология, отлично работавшая например в строительстве, оказалась не помощником, а тормозом.
Из моего личного опыта, в стартапах меньше политики, но зато намного больше так называемых «отношений». На хабре регулярно появляются статьи про «типичные ошибки стартапов», в которых большими буквами пишут: «не делайте стартап с друзьями». Так что если выбирать между корпорациями и стартапами, то еще неизвестно, где хуже.
Если еще раз посмотреть на графики «крестов», то можно увидеть, что проекты бывают не только сложными, но и простыми. В левых частях графиков — все хорошо. Проблемы начинаются примерно с середины.
А сложными проекты могут оказаться не только из-за сложности продукта, команды или планирования, но и из-за любой другой сложности (например, пресловутого «рынка», сделали классный продукт — а он «не пошел»). И основная мысль статьи — что нужно уметь видеть эти сложности, а не просто следовать некоему фреймворку или хотелкам заказчиков.
Кстати, «необузданная творческая деятельность» точно так же способна взвинтить сложность продукта до небес и исключить какие-либо шансы на то, что он когда-то заработает :)
В обсуждении на фейсбуке мне упомянули микросервисы (именно «три проекта по 100К строк вместо одного на 300К») и их ближайшую перспективу — возникновение проблем с проектированием их взаимодействия.
У Сазерленда упомянут «сосед», который сделал себе ремонт дома по Scrum. Так что возможно скрам в строительстве и применим. Другое дело, что никакой скрам не сделает из новичка профессионала — если никто в команде не знает, как правильно сделать Х, Х будет сделано неправильно.
А сложными проекты могут оказаться не только из-за сложности продукта, команды или планирования, но и из-за любой другой сложности (например, пресловутого «рынка», сделали классный продукт — а он «не пошел»). И основная мысль статьи — что нужно уметь видеть эти сложности, а не просто следовать некоему фреймворку или хотелкам заказчиков.
Кстати, «необузданная творческая деятельность» точно так же способна взвинтить сложность продукта до небес и исключить какие-либо шансы на то, что он когда-то заработает :)