Искусство управления IT-проектами

2. Кто из известных вам людей постоянно опаздывает? Меняется ли из-за этого отношение к нему со стороны других сотрудников? Станете ли вы проявлять меньше оптимизма относительно сроков, отводимых ему на какую-нибудь работу? Переживает ли он из-за своих опозданий? Какие существуют мотивации для того, чтобы он изменил своим привычкам?

3. Найдите оригинал календарного плана предыдущего проекта. Сравните его с реальными событиями. Чтобы вы сделали по-другому, если бы знали все, что знаете теперь? Как воспользоваться этой информацией в интересах следующего проекта?

4. Проведите день, начиная и заканчивая все дела точно в срок. После задайтесь вопросом, стоило ли ради этого стараться? Почему да или почему нет?

5. Найдите друга, который работает в какой-нибудь другой сфере. Как он составляет календарное планирование своих проектов? Какими инструментами пользуется для подсчета времени, затрачиваемого на ту или иную работу? Какие в его сфере деятельности наиболее типичные ошибки и чему можно научиться из того, как он с ними справляется? (Если у вас нет таких друзей, то интересно будет поучиться, сравнивая свою деятельность со строительством, кинопроизводством, устроительством свадебных торжеств.)

6. Правило трех частей – это примерная норма, для которой есть исключения. Какие разновидности проектов требуют другого распределения времени? Могут ли быть проекты, в которых доминирует только одна из этих трех разновидностей работ?

7. Многие проекты существенно зависят от неподконтрольных вам работ. Какие методы можно применить при составлении календарного плана, чтобы сократить риск подобных зависимостей? Как можно наладить контакт с людьми, ответственными за составление календарного плана, чтобы они создали план, который бы привел к успеху обе команды?

8. Ваш руководитель настаивает на определенной дате, а ваш опыт подсказывает, что это нереально. Как можно воспользоваться календарным планом, чтобы объяснить вашу обеспокоенность руководителю?

9. Если элементарные просчеты, рассмотренные в этой главе, касаются большинства проектов, то как должен поступить толковый руководитель проектов: а) поставить в известность команду об их существовании, или б) поощрять людей за стремление уменьшить их влияние на проект? Um delis num velese dip exero eum velenibh ex et, susting exer si.

Глава 3. Как определить, что делать

По поводу планирования проектов редко кто приходит к единому мнению. Зачастую уйма времени в ходе планирования уходит лишь на то, чтобы прийти к согласию, как именно вести этот процесс. Я думаю, что в любой организации люди оказываются втянутыми в дискуссию о планировании из-за столкновения интересов работающих в ней специалистов разного профиля. Когда на карту поставлены главные решения, которые будут влиять на деятельность людей в течение многих месяцев или лет, всем хочется поучаствовать в их принятии. Здесь бушуют эмоции, кипит энергия, и все опасаются, что их недостаточная активность обернется упущенными возможностями. Подобное состояние легко приводит людей к убеждению, что именно у них самый правильный взгляд на вещи. Или, хуже того, что это единственная точка зрения, заслуживающая внимания.

Самым трудным при создании программной системы является решение о том, что именно создавать. Никакой другой раздел концептуальной проработки проекта не сравнится по сложности определения подробных технических требований, включая пользовательский, программный и аппаратный интерфейсы. Никакая другая неверно проделанная часть работы не способна так испортить общие результаты. Именно ее труднее всего впоследствии исправить. Поэтому наиболее важной функцией, выполняемой создателем программного продукта в интересах потребителя, является постоянное добывание и обработка требований, предъявляемых к продукту.

Фред Брукс (Fred Brooks)