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

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

Перечислю ключевые выводы своих исторических исследований.

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

2. Чем проще вы воспринимаете свои задачи, тем эффективнее и сосредоточенее выполняете работу. Простой взгляд на свою деятельность поможет найти больше примеров и уроков из истории и современных отраслей, позаимствовать их, найти сходства или различия. Это похоже на японскую концепцию шошин, что означает «сознание новичка»^[6], или открытый разум, – важную часть многих боевых искусств. Пытливый и открытый ум делает возможным рост и требует немало практики. Познание нового требует выйти за узкие рамки «безопасного» восприятия своей работы.

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

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

УЧИМСЯ НА ОШИБКАХ

Человеческие существа отличаются практически уникальной [среди животных] способностью учиться на чужом опыте, но при этом удивляют очевидным нежеланием делать это.

Дуглас Адамс^[7]

Мои исследования поставили меня перед вопросом: зачем добровольно страдать от ошибок и разочарований, когда можно избежать их? Если история древнего и современного управления проектами известна и нам платят за умные решения, независимо от источника вдохновения, почему так мало компаний вознаграждает людей за то, что они обращаются к урокам прошлого? Проекты выполняются или закрываются (а именно такая судьба ждет многие проекты^[8]), но причины этого анализируются редко. Создается впечатление, что менеджеры большинства организаций не вознаграждают людей за подобную информацию. Возможно, они боятся того, что можно обнаружить (и ответственности). Или никому не интересно анализировать неприятный, плачевный опыт, когда можно потратить время на новую задачу.

В своей книге «Инжиниринг и человеческий фактор: роль ошибки в успешном дизайне» (To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992) Генри Петроски^[9] объясняет, что ошибки нередко приводили к прорывам в разработках. Отчасти это происходит потому, что ошибки вынуждают нас быть внимательнее. Они требуют, чтобы мы пересмотрели предположения и принципы, о которых забыли (сложно притворяться, что все хорошо, когда прототип горит синим пламенем). Как говорил Карл Поппер^[10], есть только два типа теорий: ошибочные и недоработанные. Без неудач мы самонадеянно забываем, что наше понимание несовершенно.

Смысл в том, чтобы учиться на чужих ошибках. Хотя детали провалов могут быть разными в зависимости от проекта, основные причины или ошибочные действия команды вполне можно применить к вашему случаю (и избежать их). Пора прекратить прятаться от поражений. Напротив, нужно рассматривать их как возможность чему-то научиться. Какие факторы стали причиной неудачи? Какие из них можно свести к минимуму или полностью исключить? Согласно Петроски, знания, которые мы черпаем из неудач, – самый богатый источник прогресса, если нам хватит смелости проанализировать, что произошло.

Возможно, именно поэтому в Boeing Company, одном из крупнейших в мире производителей авиационной техники, конструкторские просчеты становятся уроками^[11]. Boeing ведет свою черную книгу с момента основания компании и помогает инженерам извлекать опыт из ошибок прошлого. Поступая так, любая компания не только повышает шансы на успех проектов, но и создает условия для открытого обсуждения неудач, отрицает их или прячется. Мне кажется, разработчикам ПО тоже стоит вести черные книги.