Сделано

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

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

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

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

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

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

* * *

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

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

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

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

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

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