Ещё об индустриализации профессий
Jan. 12th, 2013 12:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Комментируя мою предыдущую
запись, pigbig указала
на идеи Ритцера о Мак-Дональдизации общества (см. изложение концепции
в рецензии
на книгу Ритцера).
Книгу я ещё почитаю, но подмеченное автором стремление к воспроизводимости и предсказуемости мне кажется очень интересными наблюдением. При этом, если верить рецензенту, эта предсказуемость становится не средством, а целью: "Не надо лучше, надо по правилам!"
Это напомнило мне эпизод, про который я, кажется, уже рассказывал. В конце прошлого века судьба и воля начальства занесла меня на семинар для менеджеров программистских компаний. Ни до, ни после этого случая я этими вопросами не интересовался, поэтому я не могу сказать, насколько общепринятыми были взгляды преподавателя. Возможно, что это были его личные заморочки - а может, наоборот, так все менеджеры думают. Впрочем, это не так уж и важно.
Преподаватель начал с того, что всем присутствующим известны замечательные программисты, способные быстро писать прекрасный код, точно решающий поставленную задачу. Они на голову выше остальных сотрудников, и заменить их практически невозможно. Задача менеджера состоит в том, чтобы таких сотрудников выявить и немедленно уволить. Их наличие несовместимо с современным промышленным производством, которому нужна воспроизводимость. "В правильно организованной компании, - подчеркнул преподаватель, - вы можете дать одну и ту же задачу двум разным программистам, и получить практически одинаковый код. Именно в этом состоит ваша цель". Преподаватель не произносил слов про средневековье и шедевры, но мысль его была вполне узнаваема: программист должен, как рабочий у конвейера, стать типовой деталью стандартного механизма. Интересно, что про качество кода при этом ничего не говорилось: в полном соответствии с идеями Ритцера (как я их понял из краткого изложения), предсказуемость и воспроизводимость тут не средство, а цель.
Я не знаю, получилось ли с этим у менеджеров, но сам подход тогда поразил меня размахом, достойным сэра Томаса Мора или Угрюм-Бурчеева. Уходящие в бесконечность правильные геометрические ряды одинаковых серых кубиков, в которых сидят взаимозаменяемые программисты, пишущие стандартный код. Они едят стандартную еду в стандартных Мак-Дональдсах, лечат их от типовых болезней типовые доктора (если два врача увидят одинаковые симптомы, они должны выписать одинаковые рецепты!), а взаимозаменяемые юристы оформляют им типовые разводы.
См. мультипликационную заставку к "Иронии судьбы".
no subject
Date: 2013-01-12 11:36 am (UTC)Во-вторых, многие обожглись на "гениях", когда был бум в софтверных конторах. Люди скакали из конторы в контору на всё большие зарплаты и более интересные проекты, оставляя за собой куски работ, которые никто не мог понять, дописать, развить или исправить. Работать два года на одном месте - нонсенс был, признак непрофессионализма и невостребованности. Год - и новое место как нормальный стиль жизни. Это были огромные убытки для контор. Так что перестраховка имела смысл. Сейчас это не так актуально, вроде.
no subject
Date: 2013-01-12 12:30 pm (UTC)Оно и сейчас близко к этому.
no subject
Date: 2013-01-12 12:31 pm (UTC)no subject
Date: 2013-01-12 05:35 pm (UTC)Сказанное является частью дилеммы.
Либо менеджер нанимает гениальных программистов - тогда он сам может ничего не пеонимать в программировании, либо менеджер нанимает тупых кодеров - но тогда процесс программирования должен будет организовывать он сам. Своими собственными ручками.
no subject
Date: 2013-01-12 05:42 pm (UTC)no subject
Date: 2013-01-12 05:48 pm (UTC)И как много таких "обычных программистов" знаете?
"Обычный программист" требует чёткой организации процесса - и поскольку "гениев" мы выкинули - то этой задачей придётся заниматься менагеру.
no subject
Date: 2013-01-12 05:57 pm (UTC)а менеджеры для того и нужны, чтобы организовывать процесс - у них даже название должности примерно так и переводится.
no subject
Date: 2013-01-12 06:42 pm (UTC)При написании програмы должен быть человек, ответственный за разделение общей задачи на подзадачи и их обратное интегрирование, за архитектуру системы - причём делать это необходимо на уровне "выше" кода, предполагая заранее сопровождаемость, масштабитуемость и т.д.
Или не предполагая.
Но ошибка в прогнозе в конце разработки может вылезти в весьма заметные средства.
no subject
Date: 2013-01-12 06:46 pm (UTC)no subject
Date: 2013-01-13 09:24 am (UTC)