УЕФА, КОНКАКАФ и Азиатская конфедерация потребовали расследования против Джанни Инфантино и выдвинули ему жесткий ультиматум 🧐
Организации обвинили главу ФИФА в злоупотреблении полномочиями из-за попытки продать доли чемпионатов мира частным лицам без консультаций с членами совета. Футбольные чиновники призвали Инфантино не выдвигаться на выборы в марте и добровольно покинуть пост, угрожая в случае отказа тотальным бойкотом всех турниров под эгидой ФИФА.
_____________
🎙Будь в курсе спортивных событий
Подпишись на «Спортлигу»
Sportliga | Спортлига
11 авг 2026 12:44
УЕФА, КОНКАКАФ и Азиатская конфедерация потребовали расследования против Джанни Инфантино и
Взгляд руководителя проектов
Эта картинка иллюстрирует два фундаментальных подхода к построению продукта. Для РП это в первую очередь выбор стратегии управления командой, рисками и бюджетом.
1. Монолитная архитектура (Слева)
Суть: Одно большое приложение (UI, бизнес-логика, данные — всё в одном флаконе) и одна общая база данных.
Что это значит для РП:
Скорость на старте: Быстро и дешево запустить MVP (минимально жизнеспособный продукт). Одна команда, один репозиторий.
Риски изменений (Long Deployment Cycles): Чтобы выпустить новую фичу, нужно пересобрать и протестировать всё приложение. Релизы редкие, долгие и рискованные. Если упадет один модуль — упадет всё.
Масштабирование (Scaling Challenges): Если нагрузка выросла только на модуль оплаты, вам все равно придется масштабировать (покупать серверы) для всего приложения целиком. Это дорого.
Ограниченная гибкость (Limited Agility): Сложно подключать новые команды. Чем больше людей пишут в один код, тем больше конфликтов и «бутылочных горлышек».
Вердикт для РП: Идеально для стартапов, небольших команд и проектов с неясными требованиями, где важна скорость первой поставки, а не долгосрочная масштабируемость.
2. Микросервисная архитектура (Справа)
Суть: Приложение разбито на независимые сервисы (Пользователи, Заказы, Оплата, Уведомления). У каждого своя база данных и своя команда.
Что это значит для РП:
Скорость разработки (Faster Development): Команды работают параллельно и независимо. Релизы становятся частыми и маленькими (не нужно ждать всех).
Изоляция ошибок (Fault Isolation): Если упал сервис уведомлений, пользователи все равно могут оформить заказ. Это критически важно для отказоустойчивости.
Независимое масштабирование: Нагрузка выросла на «Оплату»? Масштабируем только её. Экономия бюджета на инфраструктуре.
Сложность управления (скрытая цена): Требуется зрелый DevOps, сложная инфраструктура (Kubernetes, API Gateway) и четкое управление контрактами между командами. Если API одного сервиса изменится, другой сервис может сломаться.
Вердикт для РП: Подходит для крупных, зрелых продуктов, где важны отказоустойчивость, скорость выпуска фич и где над проектом работает много команд (закон Конвея: архитектура системы повторяет структуру коммуникаций в компании).