Название | Искусство управления IT-проектами |
---|---|
Автор произведения | Скотт Беркун |
Жанр | Компьютеры: прочее |
Серия | Бестселлеры O’Reilly (Питер) |
Издательство | Компьютеры: прочее |
Год выпуска | 2011 |
isbn | 978-5-388-00543-4 |
6. Правило трех частей – это примерная норма, для которой есть исключения. Какие разновидности проектов требуют другого распределения времени? Могут ли быть проекты, в которых доминирует только одна из этих трех разновидностей работ?
7. Многие проекты существенно зависят от неподконтрольных вам работ. Какие методы можно применить при составлении календарного плана, чтобы сократить риск подобных зависимостей? Как можно наладить контакт с людьми, ответственными за составление календарного плана, чтобы они создали план, который бы привел к успеху обе команды?
8. Ваш руководитель настаивает на определенной дате, а ваш опыт подсказывает, что это нереально. Как можно воспользоваться календарным планом, чтобы объяснить вашу обеспокоенность руководителю?
9. Если элементарные просчеты, рассмотренные в этой главе, касаются большинства проектов, то как должен поступить толковый руководитель проектов: а) поставить в известность команду об их существовании, или б) поощрять людей за стремление уменьшить их влияние на проект? Um delis num velese dip exero eum velenibh ex et, susting exer si.
Глава 3. Как определить, что делать
По поводу планирования проектов редко кто приходит к единому мнению. Зачастую уйма времени в ходе планирования уходит лишь на то, чтобы прийти к согласию, как именно вести этот процесс. Я думаю, что в любой организации люди оказываются втянутыми в дискуссию о планировании из-за столкновения интересов работающих в ней специалистов разного профиля. Когда на карту поставлены главные решения, которые будут влиять на деятельность людей в течение многих месяцев или лет, всем хочется поучаствовать в их принятии. Здесь бушуют эмоции, кипит энергия, и все опасаются, что их недостаточная активность обернется упущенными возможностями. Подобное состояние легко приводит людей к убеждению, что именно у них самый правильный взгляд на вещи. Или, хуже того, что это единственная точка зрения, заслуживающая внимания.
Самым трудным при создании программной системы является решение о том, что именно создавать. Никакой другой раздел концептуальной проработки проекта не сравнится по сложности определения подробных технических требований, включая пользовательский, программный и аппаратный интерфейсы. Никакая другая неверно проделанная часть работы не способна так испортить общие результаты. Именно ее труднее всего впоследствии исправить. Поэтому наиболее важной функцией, выполняемой создателем программного продукта в интересах потребителя, является постоянное добывание и обработка требований, предъявляемых к продукту.