[1/2] The Mythical Man-Month (Мифический человеко-месяц) (Рубрика Management)
Эта книга Фредерика Брукса была впервые издана 50 лет назад, в 1975 года, но она до сих пор переиздается, а цитаты из нее стали классическими. Я решил вспомнить про нее к юбилею и посмотреть насколько она еще актуальна.
В заглавие книги вынесена идея о том, что "добавление сотрудников в отстающий проект только увеличивает задержки" из-за роста коммуникационных издержек, времени на адаптацию новых членов команды и неделимости некоторых задач. Брукс критикует ошибочное предположение, что труд (измеряемый в "человеко-месяцах") можно масштабировать линейно, сравнивая это с невозможностью девяти женщин родить ребенка за один месяц. Это относится к области управления проектом/продуктом и так же актуально, как было 50 лет назад. Еще он подчеркивает важность концептуальной целостности - согласованной архитектуры системы под руководством единого видения - для предотвращения хаоса, вызванного "проектированием при помощи комитетов". Этот тезис относится к проектированию софта. Следующая ключевая идея относится к "эффекту второй системы" (перегрузка сложностью при создании следующей версии). Вот эта проблема кажется уже решена, так как продукты часто сейчас строятся итеративно и понятие версии системы вообще размывается:) Ну и последняя идея, которую стоит отметить - это различие между essential complexity (существенной сложностью, что присуща задаче) и accidental complexity (случайной сложностью, которая возникает из-за неэффективных инструментов или процессов).
Если провести параллели между разработкой во времена Брукса (1970-е годы и засилье мейнфреймов), то мы получим следующее
1) Закон Брукса vs Agile и гибридной работы
- Agile подходы снижают риск неожиданностей и даже работая проектно мы на поздних стадиях получаем меньше рисков, это соответствует мыслям Брукса о важности прототипирования в больших проектах
- Гибридная работа - современные инструменты (GitHub, Jira, Slack) снижают барьеры для коммуникаций, но правило про квадратичный рост затрат на коммуникацию от роста команды никуда не девается (помним, что в полном графе n*(n-1)/2 связей)
- Брукс рекомендовал использовать локализованные "хирургические команды", а у нас теперь есть two-pizza teams 2) Модульность и мокросервисы
- У Брукса вызывала опасения монолитная система, что они делали для мейнфрейма, но в наше время у нас пронеслись перед глазами SOA, микросервисы, FaaS и теперь людям монолит уже не кажется таким плохим вариантом для старта
- По-факту, нам нужна модульность нашего кода, а как он разворачивается можно решить потом (условно модульный монолит можно нормально разделить на отдельные микросервисы при необходимости) 3) Инструменты против человеческого фактора
- Одна из ключевых мыслей Брукса была про то, что серебрянной пули для повышения производительности разработки нет
- Но мы видим, что хорошие инженерные практики постепенно повышали продуктивность инженеров - речь про CI/CD и всю автоматизацию
- А сейчас мы живем во время, когда щепотка AI, добавленная в SDLC (software development life cycle) навроде GitHub Copilot обещает в будущем грандиозный эффект (если LLM продолжат также прогрессировать)
- Но пока мы все еще видим AI в качестве ассистента, а значит нам нужно обращать внимание на человеческий фактор, тут есть классная колонка про "Human approach to developer productivity" от Google, про которую я уже рассказывал раньше
Продолжение обзора в следующем посте.
#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps