The Mythical Man-Month (Мифический человеко-месяц)

Закон Брукса

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

Концептуальная целостность

Система должна проектироваться как единое целое под ясным архитектурным видением. Комитетное проектирование часто рождает фрагментацию и рост стоимости изменений.

Эффект второй системы

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

Essential vs accidental complexity

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

Закон Брукса vs Agile и гибридная работа

• Итеративная поставка снижает риск поздних сюрпризов и лучше согласуется с идеей Брукса о важности раннего прототипирования.
• GitHub, Jira и Slack уменьшают friction коммуникаций, но формула n*(n-1)/2 по-прежнему делает большие команды дорогими в координации.
• Концепция «хирургических команд» эволюционировала в компактные автономные команды (например, two-pizza teams).

Модульность важнее моды на архитектуру

• За десятилетия мы прошли путь от монолитов к SOA, микросервисам и FaaS, но ключевой вопрос остался прежним: управляемые границы модулей.
• Модульный монолит часто дает лучший старт: ниже операционная стоимость, проще наблюдаемость и меньше организационного шума.
• При необходимости модульные границы можно постепенно вынести в отдельные сервисы без большого переписывания.

No silver bullet и AI-эпоха

• CI/CD, quality gates и автоматизация действительно повышают пропускную способность команд, но не отменяют человеческий фактор.
• LLM-инструменты сейчас работают как усилитель инженера, а не как полная замена инженерного мышления.
• Устойчивый рост продуктивности требует сочетания платформенных инструментов, хороших процессов и культуры командной работы.

Профилактика задержек

• Не откладывать техдолг до финальных этапов проекта.
• Опираться на реальные потоковые метрики: cycle time, throughput, aging WIP, а не на «человеко-месяцы».
• Разделять plan на короткие проверяемые инкременты, чтобы рано обнаруживать отклонения.

Архитектурная дисциплина

• Поддерживать концептуальную целостность с первых итераций.
• Использовать RFC для обсуждения изменений и фиксировать ключевые решения в ADR.
• Держать документацию ближе к коду и автоматизировать ее обновление.

Коммуникации и фокус

• Сокращать лишние встречи и переводить обсуждения в асинхронный режим.
• Писать короткие, но качественные документы как основной интерфейс межкомандного взаимодействия.
• Защищать блоки сфокусированной работы, чтобы не разрушать flow state.

Масштабирование команд

• Использовать осознанные типы команд и интерфейсы взаимодействия (подход Team Topologies).
• Балансировать stream-aligned и platform-команды по реальным bottleneck, а не по оргмоде.
• Учитывать когнитивные пределы и коммуникационные накладные расходы (включая числа Данбара).