Сделано

Беркун Скотт

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

проектирования и разработки ПО таким образом, чтобы из каждой темы читатель смог извлечь для себя пользу.

Что я думаю о вас

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

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

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

• Вы не слишком серьезно относитесь к себе, программному обеспечению и менеджменту. Разработка программного обеспечения и управление проектами могут наводить тоску. Конечно, такая книга не отличается интригующим сюжетом (другое дело, если бы о разработке программного обеспечения написал Марк Твен или Дэвид Седарис [5] ), но я решил не лишать себя удовольствия пошутить над собой (или другими) или разъяснять те или иные моменты на забавных примерах.

5

Марк Твен (настоящее имя Сэмюэл Лэнгхорн Клеменс, 1835–1910) – всемирно известный американский писатель, журналист и общественный деятель. Его творчество охватывает множество жанров: юмор, сатиру, философскую фантастику, публицистику и другие. Дэвид Рэймонд Седарис (р. 1956) – американский юморист, комик, автор и радиопостановщик. Прим. ред.

Как пользоваться этой книгой

Если в какой-то момент вы заскучаете или сочтете примеры неактуальными, пропустите это место. Я написал эту книгу, учитывая потребности людей, которые привыкли «листать», а не читать или же нуждаются в конкретном совете прямо сейчас. С главами можно знакомиться в любом порядке, особенно с теми, что посвящены человеческой природе ( главу 8 , главу 9 , главу 10 , главу 11 , главу 12 , главу 13 и главу 16 ). Однако есть польза и от чтения по порядку, от начала до конца. Некоторые концепции, представленные позже, опираются на те, что даны раньше, и большинство проектов описываются в хронологическом порядке. Первая глава – самая общая и глубокая. Если вам любопытно, зачем вообще нужен проект-менеджмент или что говорят о нем авторитетные люди, то стоит почитать ее. Если начнете и вам не понравится, настоятельно рекомендую опробовать другую главу, прежде чем покинуть корабль.

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

Раз

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

Глава первая. Краткая история управления проектами (и зачем это вам нужно)

* * *

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

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

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

История нам в помощь

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

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

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