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

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

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

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

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

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

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

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

Итак, данная глава посвящена подходам к процессу планирования и выработке взгляда на планирование, предоставляющего наибольшие шансы на успех. Сначала мне следует пояснить некоторые термины и понятия, используемые в различных стратегиях планирования (материал суховат, но необходим для усвоения следующих глав). Если встретятся малоизвестные понятия, я дам определения и объединю разные точки зрения, проведу исследование вопросов, на которые даются ответы при хорошо организованном процессе планирования, и представлю пути организации ежедневной работы, направленной на успешное планирование. В следующих главах процесс создания конкретных разработок, в частности концептуальных документов (глава 4) и технических условий (глава 7), рассматривается более подробно.

Для небольшого индивидуального проекта корпоративного веб-сайта вряд ли стоит затевать столь же сложный процесс планирования, как для проекта отказоустойчивой операционной системы, в реализацию которого вовлечено триста человек и 10 миллионов долларов. Обычно, чем больше людей и сложнее проект, тем больше потребностей в серьезном планировании. Тем не менее планы приносят пользу даже самым простым индивидуальным проектам. Они дают возможность пересмотреть решения, выдвинуть предположения и прояснить соглашения между людьми и организациями. Планы действуют в качестве функции принуждения в борьбе со всеми видами глупости, поскольку требуют, чтобы в процессе рассмотрения других вариантов были решены все основные проблемы. Как сказал Авраам Линкольн: «Если бы у меня было шесть часов на то, чтобы срубить дерево, я бы потратил четыре часа на заточку топора». Я привел эту цитату, чтобы показать, что продуманная подготовка сокращает время работы.