Deadline. Роман об управлении проектами

Я действительно собирался сказать, что у нас в проекте нет серьезных проблем.
– Так всегда говорят те, у кого много проблем,

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

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

Управление – это всегда поиск компромиссов. Дизайн – тоже некий компромисс. Тебе нужно занять команду работой, поэтому ты соглашаешься на не самый лучший дизайн.
– Одно дело, когда речь идет о «не самом лучшем». Другое – когда дизайна нет вообще.
– Вебстер, какой-то дизайн есть всегда. Просто он не так хорош, как тебе хотелось бы. Даже если все время, отведенное на дизайн, потрачено впустую, все равно у системы будет внутренняя архитектура. Иначе этот твой будущий специалист, который придет в проект через несколько лет, не сможет ничего в ней поменять.

Действительно, почти во всех проектах есть некоторые задачи, которые можно выделить с самого начала. Однако если у тебя здоровенная команда, то этих задач надолго не хватит.