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

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

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

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

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

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

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

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

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

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

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

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