Сделано

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

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

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

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

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

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

Мои исследования поставили меня перед вопросом: зачем добровольно страдать от ошибок и разочарований, когда можно избежать их? Если история древнего и современного управления проектами известна и нам платят за умные решения, независимо от источника вдохновения, почему так мало компаний вознаграждает людей за то, что они обращаются к урокам прошлого? Проекты выполняются или закрываются (а именно такая судьба ждет многие проекты[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 нужен соус и т. д.). Наблюдать за большими шумными кухнями – одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.

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

6

Сознание новичка – одна из основных концепций дзен-буддизма. Традиционный пример – стакан: если цепляться за его содержимое, в нем никогда не будет достаточно места для новых знаний. См. Shunryu Suzuki Zen Mind, Begi

7

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

8

The CHAOS Report (The Standish Group) – документ о бюджете, графике работы и общих ошибках и неудачах проектов по программному обеспечению. См. http://standishgroup.com/sample_research/.

9

Генри Петроски (р. 1942) – американский инженер, кандидат теоретической и прикладной механики. Профессор гражданского строительства и истории в Университете Дьюка. Автор книг, в которых подробно описывается история промышленного дизайна обычных повседневных предметов, таких как карандаши, скрепки и столовое серебро. Прим. ред.

10

Карл Поппер – известный философ и социолог XX века. См. http://en.wikipedia.org/wiki/Karl_Popper.

11

James R. Chiles, Inviting Disaster: Lessons from the Edge of Technology (HarperBusiness, 2002).

12

Бурден Э. О еде. Строго конфиденциально. Записки из кулинарного подполья. М.: Мидгард Эксмо, 2011.