Peopleware - управление проектами

Почитал классическую книжку из тех, которые пришли к нам из 80х об управлении проектами.

Конечно прочитав её, трудно не упасть духом. Потому что описанные там проблемы остались. Как будто бы только немногие, кто осознал и на практике принял во внимание содержание книжки, стали успешны. Львиная же доля индустрии продолжает забивать микроскопом гвозди.

Моменты которые меня зацепили - касающиеся управления проектами.

Управление проектами

1. Ошибки и люди, которые их совершают. И отношение к ним. Если в команде за ошибки сурово наказывают, возникает достаточно тяжелая атмосфера. Люди будут занимать оборонительную позицию в контексте рисков и инициатив. Идея в том, чтобы минимизировать вред который ошибка причиняет и максимизировать опыт который из нее извлекается. В такой среде каждая ошибка - это практически вклад в успех.
2. Управление людьми - не пытаться сделать их одинаковыми и взаимозаменяемыми в производственном процессе (как на заводе), а уметь использовать их уникальность. Очень тонкий момент. Насколько часто хочется "сделать всех взаимозаменяемыми" настолько же часто хочется чтобы "каждый имел свою специализацию". Тонкий и холиварный момент...
3. Отношение к качеству. Профессионализм программиста не позволяет сдавать продукт с низким качеством. С другой стороны, на идеальное качество уйдет бесконечно большое время. Продавливание сдачи продукта с качеством, которое не удовлетворяет программиста обычно отражается на его самооценке и мотивации. Тонкий момент... С другой стороны, те кто готов в конечном итоге платить за качество большую цену, для них оно  в конечном итоге ничего не стоит.
4. Давление начальства на ход выполнения проекта. Оказывается "проекты в которых шеф не оказывал временного давления вообще ("Разбудите меня когда будет готово"), характеризовались самой высокой производительностью". Например с этим у нас сейчас тяжело. Каждый день разработчика кто-нибудь да спросит (причем в синхронном режиме по телефону / мессенджеру / лично): "Как там у нас дела? Как сроки?" Думаю давление можно и нужно сводить к минимуму путем асинхронной отчетности (как я её называю) - например через JIRA.
5. Производительность разработчиков и факторы которые на ее влияют. Оказывается, язык значения не имеет (опыт 84-85 годов). Склонен согласиться с этим. Не думаю, что ОО-дизайн программы на Java будет как-то отличатся по времени от С++. При условии достаточного профессионала с обеих сторон. Также не имеет значения опыт, в определенных границах (от 2х до 10 лет). И, главное, зарплата - лучшие получали всего на 9% больше худших (при двукратно лучших результатов). Теперь финансовое  стремление нанимать звезд.
6. Эффект Готорна. "Люди работают лучше когда пробуют что-то новое". Подписываюсь 
7. Отличная мысль по поводу экспериментов и пилотов: Не экспериментируйте более чем с одним технологическим аспектом в пределах одного пилотного проекта.

Продолжение следует...