[2/2] The Mythical Man-Month (Мифический человеко-месяц)
Продолжая рассказ про классическую книгу Брукса (1 и 2), расскажу про то, в какую сторону его идеи можно развивать сейчас
1) Для профилактики задержек в графике сдачи проекта
- Не стоит копить техдолг, который выстрелит ближе к сдаче проекта
- Не стоит использовать мифические человеко-месяцы, а взять метрики реальной производительности: cycle time, throughput и другие 2) Архитектурные принципы
- Стоит поддерживать концептуальную целостность с самого начала проекта - я бы тут предложил использовать RFC (request for comments) для обсуждения архитектурных вопросов, решения фиксировать в ADR (architecture decision records). Я про это как-то рассказывал в докладе про масштабирование архитектурных процессов лет 5 назад
- Также стоит инвестировать в документацию, положить ее поближе к коду и максимально автоматизировать 3) Коммуникации
- Желательно сократить по максимуму встреча, а те что исчезли перевести в асинхронный режим, а значить писать больше документов и комментить их асинхронно
- Выделять сфокусированное время для работы - это позволит не рвать поток работа (flow state) 4) Масштабирование команд
- Здесь я просто рекомендую глянуть подход из Team Topologies, который хорошо описывать типа команд и форматы их взаимодействия. Про эту книгу я много рассказывал и даже разбирал в первой серии подкаста Code of Leadership вместе со Стасом Халупом, моим бывшим коллегой
- По-факту, тут получается 2 основных типа команд: stream-aligned и platform. Первая наносит бизнесовую пользу, а вторая делает платформенные инструменты, что используют stream-aligned команды
- Ну и важно учитывать числа Донбара для понимания границ масштабирования из-за накладных расходов на коммуникации
Если подводить итоги, то книга Брукса до сих пор не устарела и может быть применена к современным проблемам. Несмотря на то что Agile и DevOps решают проблемы *случайной сложности*, его предупреждения о перегрузке ресурсами и фрагментации дизайна остаются актуальными. Команды достигают устойчивой продуктивности благодаря балансу автоматизации и процессов, ориентированных на людей — подтверждая взгляд Брукса на разработку ПО как на процесс, прежде всего зависящий от человеческого фактора. В условиях роста масштабов распределенных систем возвращение к идеям *Мифического человеко-месяца* предлагает как предостережения, так и вдохновение: инструменты меняются, но динамика команд определяет успех проекта.
#Management #Leadership #Software #Engineering #Process #Project #Architecture #DevOps