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

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

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

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

Снятие покрова таинственности с вопросов планирования программных продуктов

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

При планировании проекта нужно найти ответы на два вопроса. Ответ на первый вопрос, «Что делать?», обычно называется выработкой требований. Ответ на второй вопрос, «Как делать?», называется проектированием или выработкой технических условий (рис. 3.1). Требование должно заключаться в тщательном описании критерия, которому работа призвана соответствовать. (Например, требование к приготовлению пищи может состоять в приготовлении недорого, вкусного и питательного блюда.) Хорошо продуманные требования легко понять и трудно неверно истолковать. Для выполнения требований могут быть выбраны различные варианты проектирования, но определить, насколько они соблюдены, можно только глядя на завершенную часть работы. Технические условия представляют собой простой план создания продукта, удовлетворяющего указанным требованиям.

Рис. 3.1. Самый простой, но весьма удобный взгляд на планирование. Если неизвестно, что делать, значит, не настало время определять, как делать

Представленные три действия, выработка требований, проектирование (или выработка технических условий) и реализация, настолько объемны, что каждое из них достойно отдельной книги (см. библиографию). Первые два действия рассматриваются с точки зрения перспективы проектного уровня в нескольких последующих главах, а реализации внимание уделено чуть позже (в главах 14 и 15).

Типы проектов

Сущность процесса выработки требований и проектирования меняется в зависимости от ряда критериев. Для их иллюстрации я воспользуюсь тремя простыми, отличающимися друг от друга примерами проектов.[18]

Супермен-одиночка. В простейшем проекте участвует один человек, который делает все сам, от написания кода, проведения рыночных исследований, планирования выпуска и сбыта программного продукта до приготовления собственного завтрака. При этом он использует собственные источники финансирования.

Небольшая команда, работающая по контракту. Фирма, состоящая из пяти—десяти программистов и одного руководителя, нанятая заказчиком для создания веб-сайта или программы. С ними заключается контракт, оговаривающий взаимные обязательства. По окончании контракта все связи обрываются до заключения следующего контракта или начала следующего проекта.

Многочисленная команда штатных сотрудников. Группа из ста человек, работающая в корпорации по найму и начинающая работу над новой версией какого-нибудь программного продукта. Это может быть продукт, предназначенный для продажи (так называемый коробочный продукт), или что-нибудь для внутрикорпоративного потребления.

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

Как на планирование влияет его организация

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

Кто выдвигает требования? Кто-то должен выдвигать требования и выставлять их на утверждение заинтересованных сторон (заказчика или вице-президента). В варианте супермена-одиночки все очень просто: все полномочия принадлежат самому супермену. У команды, работающей по контракту, должен быть заказчик, желающий строго контролировать выработку требований и, по возможности, процесс проектирования. Наконец, многочисленная группа разработчиков может иметь в корпорации комиссию или иную структурную единицу, предназначенную для выполнения этой работы (и утверждающую выдвинутые требования). Она может состоять из разных людей, имеющих право выдвигать требования высокого («Это будет спортивный грузовик») и низкого («Он будет проезжать 20 миль на одном галлоне топлива и иметь привод на четыре колеса») уровней.