В менеджерской части все наоборот. Неважно, что книга написана 50 лет назад: проблемы то у проектов все те же (люди за 50 лет не эволюционировали, а проблемы в управлении – они же от людей, а не от машин).

Более того, не так важно, что речь идет именно о программировании, собрать воедино труд десятков и сотен работников интеллектуального труда – это общий челендж (Брукс все время сравнивает это с проектами химиков, пусть так).

Наконец, думаю, люди вот уже 50 лет постоянно повторяют описанные Бруксом советы, поэтому они кажутся довольно привычными. Он и сам про это хорошо сказал в своей последней главе "Мифический человеко-месяц двадцать лет спустя":

Незнакомец, сидевший рядом со мной читал "Мифический человеко-месяц", и я ждал, как он отреагирует – словом или знаком. Наконец, когда вырулили к выходу, я не выдержал:

- Как вам эта книга? Рекомендуете?
- Гм! Ничего такого, чего бы я уже не знал.

Я предпочел не представляться.

Тем не менее, перечислю пару зацепивших меня моментов:

1) Брукс говорит, что создание программного продукта в 9 раз дороже, чем написание программы для личного пользования. При том внедрение отдельного компонента дает коэффициент x3, а сборка всего продукта - еще x3.

Это удивительным образом совпадает с эмпирическим правилом, которое я вывел за время своей работы: "когда тебя спрашивают про сроки, возьми свою техническую оценку задачи (т.е. ответ на вопрос: за сколько бы ты это написал?) и умножь на три".

2) Понятно дело, что не надо пытаться затушить пожар на проекте, добавлением туда новых людей. Только потратите время на передачу контекста, в условиях пожара – это просто невыгодно. Брукс про это даже формулировал закон, который буквально это и гласит.

3) Наверное, самый спорный для меня момент – сравнение архитекторов с аристократией (а простых работяг, видимо, с крестьянами). Дескать это высшая лига, на которой огромная ответственность за дизайн всей системы. Я согласен, что такое разделение труда имеет смысл, но метафора вызывает у меня явное отвращение.

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

4) Интересная мысль про эффект второй системы, что она обречена. Т.е. вот пишет (дизайнит) человек первый свой транслятор, что-то у него получается. Но когда он начнет дизайнить второй свой транслятор, он попытается исправить в нем все недостатки первого, реализовать там все свои идеи с прошлого проекта, которые туда не поместились. Это может привести к перегруженности и неэлегантности второй системы. Мысль очень интересная.

5) Ну и конечно: потрясающая глава про планирование и срывы дедлайнов. Там целый набор интересных наблюдений и советов: и то, что никто по собственной воле не рассказывает начальнику о появляющихся сложностях, а сначала пытаются решить это на местах (поэтому продолбы могут быть внезапными); и то, насколько четкими должны быть майлстоуны (или их точно продолбают); и то, что заниженные оценки обычно вскрываются именно за 3 недели до дедлайна.

—

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

Простым работягам типа меня я бы советовал книжку прочитать, чтобы использовать ее, как лакмусовую бумажку: если ваш начальник не знает про описанные здесь вещи; раз за разом совершает приведенные Бруксом ошибки; тушит пожары бензином добавлением рабочей силы, то может стоит задуматься: такой ли он хороший начальник? (если он ничего этого не делает, то все равно не факт, что все хорошо, признак необходимый, но не достаточный) ↓

Ну и пара технических замечаний:

1) Перевод, честно говоря, не очень. Я часто сверялся с оригиналом, т.к. мысль в русской версии прям терялась из-за корявости перевода. Может стоило читать полностью на англ, но вот именно себе я купил русскую бумажную версию, так что ой;

2) Смотрите сноски! Они как-то неудобно приведены в конце книги, но как же приятно там было встретить цитирование Ершова, например (еще один признак той эпохи);

3) Последние две главы с рефлексией спустя 20 лет и ответами на критику мне показались не особо интересными. Какие-то у него там совсем базовые размышления про ООП пошли, мне показалось, что слабовато.

Но в целом круто, всем советую! Не пожалел, что возил ее с собой по путешествиям последние пару месяцев.