Сделано

скачать книгу бесплатно

Сделано
Скотт Беркун

Скотт Беркун долгое время работал в Microsoft и делится с читателями своим опытом управления проектами. Предложенные автором методы и инструменты выходят за рамки разработки программного продукта.

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

Скотт Беркун

Сделано

Проектный менеджмент на практике

Издано с разрешения O’Reilly Media, Inc.

Благодарим за консультации Илону Ноженко

Все права защищены.

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

© 2008 Scott Berkun

© 2019 Mann, Ivanov and Ferber

Authorized Russian translation of the English edition of Making Things Happen ISBN 9780596517717

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2019

* * *

Предисловие

С первым изданием случилось невероятное. Книга разошлась огромным тиражом; попала в несколько списков бестселлеров, стала номинантом различных премий и привлекла достаточно внимания, побудив автора объехать весь мир и рассказать о своих идеях. А потом произошло еще более неожиданная вещь: у книги поменялось название.

Мы с издательством O’Reilly договорились, что если уж книге предстоит обрести вторую жизнь (изначально книга называлась «Искусство управления IT-проектами»[1 - Беркун С. Искусство управления IT-проектами. СПб.: Питер, 2007.]), то нужно ее доработать. Мы обновили и дополнили текст, чтобы чтение доставило вам еще большее удовольствие. Если вам интересно, почему изменили название, позвольте перечислить несколько возможных причин.

1. Министерство национальной безопасности усмотрело в старом названии террористическую угрозу.

2. Тим О’Райли[2 - Тим О’Райли (р. 1954) – американский издатель, основатель издательства O’Reilly, активист движения за свободное программное обеспечение и программное обеспечение с открытым исходным кодом; считается одним из главных идеологов Веб 2.0. Прим. ред.] решил, что его медиаимперия станет № 1 в мире, если он пойдет на хитрость со сменой названия и убедит читателей купить книгу во второй раз.

3. А здесь можете записать любое объяснение, какое придет вам в голову.

Какой бы ни была причина, мы снова взялись за старое. Я сделал все, что в моих силах, чтобы улучшить книгу и при этом не обречь ее на фиаско «Звездных войн» Джорджа Лукаса[3 - Лукас Д., Глут Д., Кан Дж. Звездные Войны. Оригинальная трилогия. М.: Азбука-Аттикус, 2016.]. Перечислим в двух словах, что изменилось.

• Текст вычитан на предмет ясности и краткости изложения. Книга стала более содержательной, без «воды».

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

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

Если вы никогда не слышали об этой книге, введение расскажет вам все, что нужно знать.

После выхода первого издания два года назад я был очень занят. Я написал другую книгу под названием «Откуда берутся гениальные идеи»[4 - Беркун С. Откуда берутся гениальные идеи? 10 мифов об инновации. СПб.: Питер, 2011.], выпустил ряд статей, подкастов и видео. Я продолжаю вести популярный блог по креативу и менеджменту. Все это можно найти на www.scottberkun.com (http://www.scottberkun.com/).

С наилучшими пожеланиями,

Скотт Беркун

Редмонд, Вашингтон

Март 2008 г.

Введение

* * *

Мой любимый вопрос – «как?». Как это работает? Как это устроено? Как они это сделали? Стоит мне увидеть что-то интересное, меня переполняют вопросы с этим коротким, но сильным словом. И большинство ответов строится на том, как люди применяют свои интеллект и мудрость, а не конкретные технологии и теории.

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

Несмотря на несколько обобщенное название книги, мой основной опыт работы связан с технологиями, в частности в Microsoft Corporation. Я проработал там с 1994 по 2003 годы, возглавлял команды по проектам Internet Explorer, Microsoft Windows и MSN. Несколько лет я посвятил группе совершенствования разработок Microsoft. Я обучал и консультировал команды во всей компании, часто выступал на конференциях, читал лекции в других корпорациях и университетах. Большинство советов, уроков и примеров, собранных в книге, опираются именно на этот опыт.

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

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

Для кого эта книга

Чтобы узнать, подходит вам эта книга или нет, предлагаю вернуться к оглавлению, выбрать тему, которая вас интересует, и пробежать глазами, что я написал. Я никогда не доверял введениям и вам не советую, но все-таки продолжу.

Книга будет особенно полезна тем, кто может отнести себя к одной или нескольким категориям.

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

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

• Программисты, тестировщики и другие участники проекта. Эта книга поможет разобраться, какие цели стоят перед вами и какие подходы можно применить для эффективной работы. Если вы когда-либо задумывались, почему проекты так часто меняют направление или создается впечатление, что ими неграмотно управляют, эта книга поможет понять причины и найти решения. Как минимум она увеличит шансы на то, что ваша работа изменит что-то к лучшему (и вы не сойдете с ума в процессе). Если вам хотелось бы возглавить команду, эта книга поможет узнать, как выглядит лидерство и насколько подходит лично вам.

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

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

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

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

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

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

2. Чем проще вы воспринимаете свои задачи, тем эффективнее и сосредоточенее выполняете работу. Простой взгляд на свою деятельность поможет найти больше примеров и уроков из истории и современных отраслей, позаимствовать их, найти сходства или различия. Это похоже на японскую концепцию шошин, что означает «сознание новичка»[6 - Сознание новичка – одна из основных концепций дзен-буддизма. Традиционный пример – стакан: если цепляться за его содержимое, в нем никогда не будет достаточно места для новых знаний. См. Shunryu Suzuki Zen Mind, Beginner’s Mind (Weatherhill, 1972) (Судзуки С. Сознание дзен, сознание начинающего. М.: Альпина Паблишер, 2014.).], или открытый разум, – важную часть многих боевых искусств. Пытливый и открытый ум делает возможным рост и требует немало практики. Познание нового требует выйти за узкие рамки «безопасного» восприятия своей работы.

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

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

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

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

    Дуглас Адамс[7 - Дуглас Ноэль Адамс (1952–2001) – английский писатель, драматург и сценарист, автор юмористических фантастических произведений. Известен как создатель знаменитой серии книг «Автостопом по галактике». Прим. ред.]

Мои исследования поставили меня перед вопросом: зачем добровольно страдать от ошибок и разочарований, когда можно избежать их? Если история древнего и современного управления проектами известна и нам платят за умные решения, независимо от источника вдохновения, почему так мало компаний вознаграждает людей за то, что они обращаются к урокам прошлого? Проекты выполняются или закрываются (а именно такая судьба ждет многие проекты[8 - The CHAOS Report (The Standish Group) – документ о бюджете, графике работы и общих ошибках и неудачах проектов по программному обеспечению. См. http://standishgroup.com/sample_research/ (http://standishgroup.com/sample_research/).]), но причины этого анализируются редко. Создается впечатление, что менеджеры большинства организаций не вознаграждают людей за подобную информацию. Возможно, они боятся того, что можно обнаружить (и ответственности). Или никому не интересно анализировать неприятный, плачевный опыт, когда можно потратить время на новую задачу.

В своей книге «Инжиниринг и человеческий фактор: роль ошибки в успешном дизайне» (To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992) Генри Петроски[9 - Генри Петроски (р. 1942) – американский инженер, кандидат теоретической и прикладной механики. Профессор гражданского строительства и истории в Университете Дьюка. Автор книг, в которых подробно описывается история промышленного дизайна обычных повседневных предметов, таких как карандаши, скрепки и столовое серебро. Прим. ред.] объясняет, что ошибки нередко приводили к прорывам в разработках. Отчасти это происходит потому, что ошибки вынуждают нас быть внимательнее. Они требуют, чтобы мы пересмотрели предположения и принципы, о которых забыли (сложно притворяться, что все хорошо, когда прототип горит синим пламенем). Как говорил Карл Поппер[10 - Карл Поппер – известный философ и социолог XX века. См. http://en.wikipedia.org/wiki/Karl_Popper (http://en.wikipedia.org/wiki/Karl_Popper).], есть только два типа теорий: ошибочные и недоработанные. Без неудач мы самонадеянно забываем, что наше понимание несовершенно.

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

Возможно, именно поэтому в Boeing Company, одном из крупнейших в мире производителей авиационной техники, конструкторские просчеты становятся уроками[11 - James R. Chiles, Inviting Disaster: Lessons from the Edge of Technology (HarperBusiness, 2002).]. Boeing ведет свою черную книгу с момента основания компании и помогает инженерам извлекать опыт из ошибок прошлого. Поступая так, любая компания не только повышает шансы на успех проектов, но и создает условия для открытого обсуждения неудач, отрицает их или прячется. Мне кажется, разработчикам ПО тоже стоит вести черные книги.

Разработка, кухня и скорая помощь

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

Один мой знакомый разработчик уверен, что коль скоро принимает сложные решения – по проектированию, координации процесса, тестированию изменений за несколько часов или даже минут, затем выпуску продукта, – его проектам и обязанностям нет аналога во всей истории Вселенной. Он с гордостью перечислит все, чем овладел: CSS, XHTML, Flash, Ajax и другое – и станет убеждать, что пятьдесят лет назад эти технологии потрясли бы величайшие умы. Уверен, вам тоже доводилось встречать таких людей. Или, возможно, самим казалось, что до вас никто не решал такие сложные задачи.

Я предложил этому разработчику заглянуть «за кулисы» его любимого ресторана в разгар рабочего дня. Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально»[12 - Бурден Э. О еде. Строго конфиденциально. Записки из кулинарного подполья. М.: Мидгард Эксмо, 2011.]), однако сейчас я подразумеваю продуктивность. Когда люди впервые видят молниеносное управление и координацию работы на профессиональной кухне в разгар рабочего дня, им уже не кажется, что их работа самая сложная на свете. Повара жонглируют горячими сковородками с разными блюдами на разном этапе готовности, носятся между конфорками из одного угла кухни в другой, а официанты при этом вбегают и выбегают, сообщают о новых заказах, изменениях и проблемах.

И все это происходит в небольшом тесном помещении, где температура намного выше 30 градусов, под ярким флуоресцентным светом. И сколько бы заказов они ни готовили каждые несколько секунд, новые поступают примерно с той же скоростью. Иногда заказы возвращаются обратно, или, как в программных проектах, в последнюю минуту клиент вносит поправки (столик 1 не переносит лактозу, на столик 2 нужен соус и т. д.). Наблюдать за большими шумными кухнями – одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.

Шеф-повара и линейные повара – менеджеры кулинарных проектов или, как называет их Бурден, регулировщики движения (кстати, еще одна профессия для вдумчивого изучения). Хотя персонал кухни работает в гораздо меньших масштабах и пользуется гораздо меньшим почетом, чем менеджер команды разработчиков, по ежедневной интенсивности их даже сравнивать нельзя. Если не верите, когда в следующий раз окажетесь в ресторане, спросите официанта, можно ли одним глазком посмотреть на работу кухни. Скорее всего, он откажет, но если все-таки согласится, вы не будете разочарованы. (В некоторых модных ресторанах и барах есть открытая кухня. Если найдете такую, сядьте поближе и понаблюдайте за одним из поваров хотя бы несколько минут. Смотрите, как размещаются заказы, как они отслеживаются, собираются и доставляются. Если на кухне аврал, то вы совершенно по-другому посмотрите на поиск и исправление ошибок в программах.)

Еще одна любопытная область – скорая помощь. Я смотрел по каналам Discovery и PBS, как небольшие команды врачей и медсестер оказывают пациенту помощь и находят выход из совершенно непостижимых ситуаций. Не удивительно, что именно врачи неотложной помощи изобрели процесс триажа[13 - Триаж (фр. Triage – сортировка) – распределение пострадавших и больных на группы, исходя из нуждаемости в первоочередных и однородных мероприятиях (лечебных, профилактических, эвакуационных) в конкретной обстановке. Прим. ред.], который применяется в разработке ПО для сортировки задач или ошибок в соответствии с приоритетами (подробнее – в главе 15 (#litres_trial_promo)).

В медицинской среде, особенно травматологии, находятся удивительные параллели для командной работы, принятия решений в условиях высокого стресса и результатов проекта, которые влияют на многих людей каждый день (на рисунке 1.1 вы видите краткое сравнение с медициной и другими сферами работы). Как писал Атул Гаванде[14 - Гаванде А. (р. 1965) – американский хирург, журналист, писатель. Широко известен как эксперт в области оптимизации современного здравоохранения. Прим. ред.] в своей блестящей книге «Сложности: заметки хирурга о несовершенной науке» (Complications: A Surgeon’s Notes on an Imperfect Science (Picador USA, 2003):

Рис. 1.1. В теории многие дисциплины опираются на схожие процессы. Все они уделяют время планированию, исполнению и совершенствованию. (Однако не стоит обращаться на кухню за медицинской помощью или обедать в отделении реанимации.)

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

Этот принцип, как и многие другие идеи из блестящей книги Гаванде, применим к разработке программного обеспечения. Фред Брукс[15 - Фредерик Филлипс Брукс – младший (р. 1931) – американский ученый в области теории вычислительных систем. Управлял разработкой OS/360 в IBM. Награжден премией Тьюринга в 1999 году. Прим. ред.] в своей классической работе по софтверному инжинирингу «Мифический человеко-месяц»[16 - Брукс Ф., Чапел Х. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2010.] проводит схожие сравнения между командами хирургов и программистов. Хотя жизнь редко стоит на кону, когда вы работаете над сайтом или базой данных, можно отметить немало обоснованных параллелей с трудностями, которые подстерегают эти команды абсолютно разных профессионалов.

Задача проектного менеджмента

Управление проектами может быть профессией, должностью, ролью или функцией. В некоторых компаниях есть руководители, которые отслеживают все проекты двухсот сотрудников. В других этой должностью «награждают» линейных младших менеджеров, каждый из которых реализует часть масштабного проекта. В зависимости от структуры организации, ее культуры и целей проекта управлять проектами может любой сотрудник одновременно с выполнением других обязанностей или сотрудник, для которого управление будет основной задачей (Винсент, Клод и Рафаэль – наши постоянные менеджеры проекта).

В этой книге я использую термин менеджер проекта (project manager) применительно ко всем, кто управляет проектом. Под таковым я подразумеваю руководство командой на этапе планирования, выстраивания графика и формулировки требований, а также на этапах проектирования, разработки (коммуникация, принятие решений и стратегия «середины игры») и достижения итогового результата (лидерство, кризис-менеджмент и конечная стратегия).

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

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

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

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

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

Программный и проектный менеджмент в Microsoft

В конце 1980-х годов Microsoft столкнулась с проблемой координации технической работы с задачами маркетинга и бизнеса (некоторые скажут, что это до сих пор остается проблемой для Microsoft и многих других компаний). Мудрый человек по имени Джейб Блюменталь придумал должность, на которой человек одновременно будет выполнять лидерские и организационные функции. Ему предстояло работать над проектом с первого дня планирования и до последнего дня тестирования. Он должен был разбираться в технических вопросах настолько, чтобы завоевать уважение программистов, уметь широко смотреть на продукт, а кроме того с радостью заниматься написанием спецификаций, анализом маркетинговых планов, составлением графиков, управлением командами, стратегическим планированием, триажем ошибок, мотивированием команды и любой другой необходимой работой, которую не выполняет никто иной (по крайней мере, достаточно хорошо). Новая должность в Microsoft получила название программный менеджер. Он обладал значительными полномочиями, хотя не все члены команды находились в его прямом подчинении. (В теории менеджмента это пример матричной организационной структуры[17 - Резюме матричной организационной структуры и других типов см. Steven A. Silbiger The Ten-Day MBA (William Morrowand Company, 1993) (Силбигер С. МВА за 10 дней. Самое важное из программ ведущих бизнес-школ мира. М.: Альпина Паблишер, 2018), pp. 139–145. Хотя информацию можно найти почти в каждой книге по теории менеджмента.], которая предполагает двойное подчинение: в зависимости от должности сотрудника и в зависимости от проекта. Так, программист или тестировщик подчиняются двум менеджерам.)

Джейб стал программным менеджером в работе над продуктом под названием Multiplan (позже его переименовали в Microsoft Excel), и успех не заставил себя ждать. Улучшились процессы проектирования и разработки и координация работы команды, и все были счастливы. После многочисленных совещаний и рабочих встреч команды адаптировались к новой роли. Поручив конкретные обязанности линейному эксперту широкого профиля, Microsoft навсегда изменила динамику работы команд разработчиков. Практически все время работы в Microsoft я как раз выступал в роли программного менеджера. Я работал с продуктовыми командами Internet Explorer, MSN и Windows и даже руководил командами программных менеджеров.