В книге Генри Петроски (Henry Petroski) «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage Books, 1992) автор описывает множество прорывов в разработках, происходивших благодаря провалам. В частности, такое случается из-за того, что провалы заставляют нас пристальнее к чему-нибудь приглядываться. Они требуют от нас пересмотра подзабытых предположений (трудно притворяться, что все в порядке, когда прототип горит ярким пламенем). Как говорил Карл Поппер (Karl Popper[3]), есть только два вида теорий: неправильные и несовершенные. Без провалов мы самонадеянно забываем, что наше понимание вещей не настолько совершенно, насколько мы думаем.

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

Возможно, именно поэтому компания «Боинг», одна из крупнейших фирм по разработке и производству авиационной техники, ведет черную книгу уроков, извлеченных из конструкторских и инженерных просчетов.[4]Боинг ведет эту документацию со дня основания компании и использует ее для помощи современным конструкторам в извлечении уроков из прошлого. Любая организация, организовавшая подобную практику, не только повысит свои шансы на осуществление успешных проектов, но также поможет создать среду, в которой можно будет открыто обсуждать промахи и противостоять им, вместо того чтобы не признавать их существования и прятаться от них. Пожалуй, разработчикам программного обеспечения неплохо было бы завести свою собственную черную книгу.

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

К примеру, я знаю одного веб-разработчика, который искренне верит в то, что его работа не похожа ни на какую другую за всю мировую историю. Он считает, что его проект и управление задачами непохожи ни на что из ранее существовавшего, поскольку в процессе веб-разработки он должен принимать сложные инженерные решения, связанные с проектированием и согласованием, а также проверкой изменений буквально в течение нескольких часов или даже минут, а потом публиковать результаты своей работы во Всемирной сети. Он с гордостью перечисляет технологии, которыми овладел, – CSS, XHTML, Flash, Java, – утверждая, что каких-нибудь 50 лет назад они могли бы озадачить самые светлые умы человечества. Я уверен, что вам тоже попадались подобные люди. А может быть и у вас складывались ситуации, когда казалось, что еще никто и никогда не решал такие сложные проблемы.

Я предложил бы этому разработчику пройти как-нибудь в разгар рабочего дня на кухню его любимого кафе. Побывать на кухне интересно по многим причинам (почитайте замечательную книгу Энтони Бурдэйна (Anthony Bourdain) «Kitchen Confidential» (Ecco, 2001), но мое внимание привлекла производительность работы. Когда впервые сталкиваешься с такой оперативностью управления и скоординированностью действий команды, какие бывают в час пик на профессиональной кухне, начинаешь по-другому относиться к сложности собственной работы. Повара зачастую просто жонглируют сковородками, на которых жарятся блюда из разных заказов, находящиеся в разной степени готовности, и протискиваются между плитами, расположенными в противоположных концах кухни, а официанты тем временем носятся туда-сюда, сообщая о все новых и новых запросах и капризах посетителей.

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

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

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

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