Peopleware — пожалуй, лучшая книга по менеджменту IT-проектов

«Человеческий фактор. Успешные проекты и команды» была моей второй книгой Тома ДеМарко (первая — Deadline), и обе прежде всего затянули красивым языком и эмоциональной частью повествования. Конечно, обе книги это «науч-поп.» и кто-то скажет, что акцент даже слишком смещен в «популярность», но если применительно к Дедлайну с этим можно согласиться, то Peopleware целиком и полностью состоит из фактов и жизненных примеров.

Ключевым — и необычным — моментом, на который авторы делают упор, становится отрицание приоритетности технической составляющей разработки. Наиболее важной компонентой считается формирование здоровой атмосферы коллектива и всяческое способствование командной деятельности. Поразмыслив, с этим сложно не согласиться, потому что как бы ни была ужасна кодовая база, если команда к ней привыкла, хорошо её знает и может быстро и качественно вносить исправления, то достижение «технического идеала» действительно выглядит весьма побочной задачей, не продиктованной требованиями рынка. Однако если эта задача «идеализации кода» рождается в самой команде, то, отмахнувшись от неё «требованиями рынка», можно напротив получить потерю мотивации и ненависть к продукту со стороны команды. Ключевым отличием здесь служит именно источник этого «толчка» к лучшему: если он внешний — то команда сама разберется, как ей работать; если внутренний — то даже если это скажется на сроках выпуска, стоит задуматься и дать команде время на совершенствование.
Конечно, это совсем не означает, что можно/нужно забыть все шаблоны проектирования, и не задумываться об архитектуре, это говорит лишь о том, что «хорошая команда + средненькая архитектура» намного лучше, чем «отличная архитектура + никакая команда/текучка». Ну а «хорошая команда + хорошая архитектура» дадут просто потрясающие результаты по скорости и качеству.

Как противоположность идеи акцента на человеческих и командных взаимодействиях и приветствования командных инициатив, авторы называют насаждение Методологии с большой буквы, подразумевая строгое следование «корпоративным стандартам», жесткой технической парадигме, сокращение пространства для творчества.
В этом контексте хочется подчеркнуть именно «насаждение», потому что сами авторы утверждают, что в процессе работы у любой команды вырабатываются и свой стиль, и свои правила, и даже своя «методология», но, что и отличает её от Методологии с большой буквы, её команда вырабатывает сама, самостоятельно прочуствовав необходимость, и потому эти ограничения не вызывают в участниках команды естественного отторжения, которое всегда является первой реакцией на внешние воздействия.
«Работа в такой среде практически освобождает от ответственности. Люди хотят принимать ответственность, но не станут, если не получат определённую степень свободы в управлении собственным курсом на успех. Смысл решения о применении Методологии ясен всем. Ничто не может лишить сотрудников мотивации настолько эффективно, насколько это сделает осознание ими того факта, что руководство считает их некомпетентными«, — кратко и емко сформулированная мысль об основном минусе Методологии.

Ну и конечно, немалую роль в привлекательности книги играет то, как авторы «читают твои мысли». Не раз и не два натыкался на моменты, про которые я сам говорил, и в которых я сам убеждал. Это и процесс вовлечения и динамика численности людей в стартующих проектах, и близкий технический уровень участников команды, и «подозрительность» митингов по расписанию и приветствие «стихийности» собраний, и сомнительность учета времени, и многое-многое другое.

И даже если на вашей ежедневной практической деятельности эта книга никак и не скажется, это просто очень занимательная повесть, гарантирующая с интересом проведенные часы чтения и размышления над прочитанным.

Рекомендую.