Дочитал книжку, осталось множество положительных впечатлений. Впечатления эти всподвигают к новым свершениям и желанию что-то изменить, улучшить, чего-то добиться. В общем, наряду с множеством умных мыслей почерпнутых из книги я бы сказал что еще и получаешь заряд энергии. Хорошая мотивирующая книга. Советую для прочтения. В библиотеку как Must read!

Несколько мыслей из разных глав:

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могуть помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему – сохранить хорошую мину при плохой игре.

Конфликт

  1. Проект, в котором учавствуют несколько сторон, обязательно столкнется с конфликтами интересов.
  2. Процесс создания и распространения программных систем – прямо-таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы – определения архитектуры системы (потому что всем разработчиками надо скорее дать какую-то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увелечению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набирать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

(c) Deadline by Tom DeMarco

Advertisements