Человеческие существа отличаются практически уникальной [среди животных] способностью учиться на чужом опыте, но при этом удивляют очевидным нежеланием делать это.
Дуглас Адамс[7]Мои исследования поставили меня перед вопросом: зачем добровольно страдать от ошибок и разочарований, когда можно избежать их? Если история древнего и современного управления проектами известна и нам платят за умные решения, независимо от источника вдохновения, почему так мало компаний вознаграждает людей за то, что они обращаются к урокам прошлого? Проекты выполняются или закрываются (а именно такая судьба ждет многие проекты[8]), но причины этого анализируются редко. Создается впечатление, что менеджеры большинства организаций не вознаграждают людей за подобную информацию. Возможно, они боятся того, что можно обнаружить (и ответственности). Или никому не интересно анализировать неприятный, плачевный опыт, когда можно потратить время на новую задачу.
В своей книге «Инжиниринг и человеческий фактор: роль ошибки в успешном дизайне» (To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992) Генри Петроски[9] объясняет, что ошибки нередко приводили к прорывам в разработках. Отчасти это происходит потому, что ошибки вынуждают нас быть внимательнее. Они требуют, чтобы мы пересмотрели предположения и принципы, о которых забыли (сложно притворяться, что все хорошо, когда прототип горит синим пламенем). Как говорил Карл Поппер[10], есть только два типа теорий: ошибочные и недоработанные. Без неудач мы самонадеянно забываем, что наше понимание несовершенно.
Смысл в том, чтобы учиться на чужих ошибках. Хотя детали провалов могут быть разными в зависимости от проекта, основные причины или ошибочные действия команды вполне можно применить к вашему случаю (и избежать их). Пора прекратить прятаться от поражений. Напротив, нужно рассматривать их как возможность чему-то научиться. Какие факторы стали причиной неудачи? Какие из них можно свести к минимуму или полностью исключить? Согласно Петроски, знания, которые мы черпаем из неудач, самый богатый источник прогресса, если нам хватит смелости проанализировать, что произошло.
Возможно, именно поэтому в Boeing Company, одном из крупнейших в мире производителей авиационной техники, конструкторские просчеты становятся уроками[11]. Boeing ведет свою черную книгу с момента основания компании и помогает инженерам извлекать опыт из ошибок прошлого. Поступая так, любая компания не только повышает шансы на успех проектов, но и создает условия для открытого обсуждения неудач, отрицает их или прячется. Мне кажется, разработчикам ПО тоже стоит вести черные книги.
Разработка, кухня и скорая помощь
Есть одна проблема: иногда невозможно применить уроки двадцатилетней давности и интересоваться тем, что так сильно отличается от нынешних реалий. Единственный выход провести аналогии с современными проектами. Такому подходу будет недоставать предыстории разработок, а потому веса и авторитета, но все же он позволяет познакомиться с личным опытом и наблюдениями людей. Зачастую увидеть все своими глазами единственный способ собрать достаточно информации, чтобы провести аналогии между различными идеями.
Один мой знакомый разработчик уверен, что коль скоро принимает сложные решения по проектированию, координации процесса, тестированию изменений за несколько часов или даже минут, затем выпуску продукта, его проектам и обязанностям нет аналога во всей истории Вселенной. Он с гордостью перечислит все, чем овладел: CSS, XHTML, Flash, Ajax и другое и станет убеждать, что пятьдесят лет назад эти технологии потрясли бы величайшие умы. Уверен, вам тоже доводилось встречать таких людей. Или, возможно, самим казалось, что до вас никто не решал такие сложные задачи.
Я предложил этому разработчику заглянуть «за кулисы» его любимого ресторана в разгар рабочего дня. Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально»[12]), однако сейчас я подразумеваю продуктивность. Когда люди впервые видят молниеносное управление и координацию работы на профессиональной кухне в разгар рабочего дня, им уже не кажется, что их работа самая сложная на свете. Повара жонглируют горячими сковородками с разными блюдами на разном этапе готовности, носятся между конфорками из одного угла кухни в другой, а официанты при этом вбегают и выбегают, сообщают о новых заказах, изменениях и проблемах.
И все это происходит в небольшом тесном помещении, где температура намного выше 30 градусов, под ярким флуоресцентным светом. И сколько бы заказов они ни готовили каждые несколько секунд, новые поступают примерно с той же скоростью. Иногда заказы возвращаются обратно, или, как в программных проектах, в последнюю минуту клиент вносит поправки (столик 1 не переносит лактозу, на столик 2 нужен соус и т. д.). Наблюдать за большими шумными кухнями одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.
Шеф-повара и линейные повара менеджеры кулинарных проектов или, как называет их Бурден, регулировщики движения (кстати, еще одна профессия для вдумчивого изучения). Хотя персонал кухни работает в гораздо меньших масштабах и пользуется гораздо меньшим почетом, чем менеджер команды разработчиков, по ежедневной интенсивности их даже сравнивать нельзя. Если не верите, когда в следующий раз окажетесь в ресторане, спросите официанта, можно ли одним глазком посмотреть на работу кухни. Скорее всего, он откажет, но если все-таки согласится, вы не будете разочарованы. (В некоторых модных ресторанах и барах есть открытая кухня. Если найдете такую, сядьте поближе и понаблюдайте за одним из поваров хотя бы несколько минут. Смотрите, как размещаются заказы, как они отслеживаются, собираются и доставляются. Если на кухне аврал, то вы совершенно по-другому посмотрите на поиск и исправление ошибок в программах.)
Еще одна любопытная область скорая помощь. Я смотрел по каналам Discovery и PBS, как небольшие команды врачей и медсестер оказывают пациенту помощь и находят выход из совершенно непостижимых ситуаций. Не удивительно, что именно врачи неотложной помощи изобрели процесс триажа[13], который применяется в разработке ПО для сортировки задач или ошибок в соответствии с приоритетами (подробнее в главе 15).
В медицинской среде, особенно травматологии, находятся удивительные параллели для командной работы, принятия решений в условиях высокого стресса и результатов проекта, которые влияют на многих людей каждый день (на рисунке 1.1 вы видите краткое сравнение с медициной и другими сферами работы). Как писал Атул Гаванде[14] в своей блестящей книге «Сложности: заметки хирурга о несовершенной науке» (Complications: A Surgeons Notes on an Imperfect Science (Picador USA, 2003):
Рис. 1.1. В теории многие дисциплины опираются на схожие процессы. Все они уделяют время планированию, исполнению и совершенствованию. (Однако не стоит обращаться на кухню за медицинской помощью или обедать в отделении реанимации.)
Мы воспринимаем медицину как упорядоченную область знаний и четкую процедуру. Однако это не так. Медицина наука несовершенная, собрание постоянно меняющихся сведений, непроверенной информации, небезупречных людей и жизней, которые нужно спасти. Да, наша работа опирается на науку, но, помимо нее, на привычки, интуицию, а иногда и просто догадки. Между нашими знаниями и стремлениями остается чудовищная пропасть. И эта пропасть усложняет все, что мы делаем.
Этот принцип, как и многие другие идеи из блестящей книги Гаванде, применим к разработке программного обеспечения. Фред Брукс[15] в своей классической работе по софтверному инжинирингу «Мифический человеко-месяц»[16] проводит схожие сравнения между командами хирургов и программистов. Хотя жизнь редко стоит на кону, когда вы работаете над сайтом или базой данных, можно отметить немало обоснованных параллелей с трудностями, которые подстерегают эти команды абсолютно разных профессионалов.
Задача проектного менеджмента
Управление проектами может быть профессией, должностью, ролью или функцией. В некоторых компаниях есть руководители, которые отслеживают все проекты двухсот сотрудников. В других этой должностью «награждают» линейных младших менеджеров, каждый из которых реализует часть масштабного проекта. В зависимости от структуры организации, ее культуры и целей проекта управлять проектами может любой сотрудник одновременно с выполнением других обязанностей или сотрудник, для которого управление будет основной задачей (Винсент, Клод и Рафаэль наши постоянные менеджеры проекта).
В этой книге я использую термин менеджер проекта (project manager) применительно ко всем, кто управляет проектом. Под таковым я подразумеваю руководство командой на этапе планирования, выстраивания графика и формулировки требований, а также на этапах проектирования, разработки (коммуникация, принятие решений и стратегия «середины игры») и достижения итогового результата (лидерство, кризис-менеджмент и конечная стратегия).