Читать онлайн «Искусство управления IT-проектами». Страница 3

Все ссылки и URL-адреса, приведенные в этой книге, а также дополнительные замечания и комментарии находятся в сети по адресу www.makingthingshappen.org. Если вас заинтересует обсуждение этой книги, обратитесь к приложению, расположенному в самом конце. Там перечислены имеющиеся дискуссионные группы и дан совет, как открыть свою собственную группу.

А теперь, поскольку у вас хватило мудрости и терпения прочитать это предисловие до конца, я смею предположить, что вы по инерции прочитаете все, что есть в этой книге (номера страниц, сноски и т. п.), и, не снижая скорости, пойдете дальше.

Во многих организациях должность человека, возглавляющего проект, не называется «Руководитель проекта». И это правильно. Каждый в своей повседневной работе управляет проектом, независимо от того, работает ли он в одиночку или возглавляет команду. На данный момент эти различия не существенны. Я стремлюсь уловить то, что приводит проекты к успеху, и как люди, возглавляющие успешные проекты, этого добиваются. Для успешных стратегий не требуются определенные иерархии, наименования должностей или методы. Стало быть, если вы работаете над проектом и несете за исход дела хоть какую-то ответственность, то все, что будет изложено далее, имеет к вам непосредственное отношение. А если на вашей визитке написано, что вы руководитель проекта – тем лучше.

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

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

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

Вся история инженерных проектов свидетельствует о том, что многие из них обладают четко обозначенными общими чертами. У них есть технические требования, проектные решения и ограничения. Они зависят от средств общения, принятия решений и сочетания творческого и логического мышления. Зачастую в проектах фигурирует рабочий график, бюджет и заказчик. Наиболее важной и основной задачей проектов является объединение усилий разных людей в единое, согласованное целое, приносящее пользу другим людям или заказчикам. Из чего бы ни был построен проект, из кода HTML, C++ или стали и бетона, существует незыблемый, основной набор понятий, разделяемый большинством проектов.

Проявляя любопытство к самым эффективным способам ведения разработки программных продуктов и веб-приложений, я всерьез заинтересовался этими основами. Я изучил другие области, чтобы посмотреть, как в них решаются основные проблемы, присущие их проектам, и удивился тому, как были разработаны и реализованы такие проекты, как космический телескоп «Хаббл» и самолет «Боинг-777». Можно ли воспользоваться чем-нибудь из принадлежащей им совокупности процессов составления технических заданий и планирования? Или же, если взять сооружение небоскреба компании «Крайслер» в Нью-Йорке и храма Парфенон в Афинах, неужели ведущие этих проектов планировали и рассчитывали свои конструкции точно так же, как это делают мои программисты? В чем состояли интересные различия и что можно получить в результате их изучения?

А как насчет редакторов газет, осуществляющих организацию и планирование ежедневных информационных выпусков? Они занялись производством мультимедийной продукции (изображений и текста) задолго до первых задумок, касающихся веб-публикаций. А как насчет художественных фильмов? Запуска Апполона-13? Изучая эти вопросы, я получил возможность взглянуть на то, как мне приступить к руководству проектами, используя новый стиль работы.

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

Ключевые уроки из моего экскурса в прошлое можно свести к трем моментам.

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

2. Чем проще ваше представление о том, чем вы занимаетесь, тем с большей энергией и целеустремленностью вы будете работать. Если сохранять простое представление о том, что мы делаем, то можно найти полезные сопоставления с другими способами создания вещей, которые существуют в окружающем нас мире. Перед вами откроется больше примеров и уроков из истории и современного производства, из которых можно будет что-нибудь позаимствовать, с чем-то провести сравнения или сопоставления. Это созвучно понятию, определяемому японским словом шошин (shoshin) – сознание начинающего[1] или открытое восприятие – основной части многих дисциплин боевых искусств. Любопытство и открытость – вот что предопределяет возможности развития, и для поддержания этого состояния требуется определенная практика. Чтобы сохранить способность обучаться чему-то новому, мы должны избегать искушения обрести узкий и непоколебимый взгляд на то, чем занимаемся.

3. Просто – отнюдь не означает легко. Лучшие атлеты, писатели, программисты и менеджеры стремились быть среди тех, кто всегда рассматривает свою деятельность как простую по сути, но в то же время и сложную. Следует помнить, что понятие простоты не является эквивалентом легкости. К примеру, что сложного в том, чтобы пробежать марафонскую дистанцию. Побежал – и не останавливайся, пока не пробежишь 42 км 195 м. Казалось бы, чего уж проще-то? Тот факт, что это нелегко, не опровергает простоты процесса. Возглавлять и управлять тоже нелегко, но природа этих процессов – направлять все в нужное русло на достижение намеченной цели – по своей сути проста.