Уильям Паундстоун - Как сдвинуть гору Фудзи

• Название: Как сдвинуть гору Фудзи
• Автор: Уильям Паундстоун
• Издательство: Альпина Бизнес Букс при содействии Headhunter.ru
• Жанр: Деловая литература
• Год: 2004
• ISBN: 5-9614-0094-8

Методику интервьюирования при приеме на работу в корпорацию Microsoft, основанную на решении задач и головоломок, теперь перенимают многие компании, которые хотят выявить наиболее творческих кандидатов среди просто способных. В книге «Как сдвинуть гору Фудзи?» излагается эта методика и предлагается более тридцати трудных задач и головоломок. Книга показывает, как при помощи эффективного творческого и аналитического мышления можно отыскать ответы на самые нестандартные вопросы.

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

---

Одним из людей, которых позвали, чтобы они помогли решить эту проблему, был Чарльз Симоньи. Симоньи — знаменитый ученый-специалист в области компьютеров, который предпочел работать в сфере бизнеса, что иногда выглядит в глазах академических ученых подозрительно. Работая в компании Xerox PARC, Симоньи написал первую полнофункциональную программу — текстовый редактор. Его раздражало отсутствие интереса корпорации Xerox к маркетингу операционной среды Windows и компьютерной мыши, которые были изобретены в его лаборатории. Во время деловой поездки в Сиэтл Симоньи без предварительной договоренности нанес визит в Microsoft. Тогда процедура приема на работу в этой корпорации была проще, чем сейчас. Один из «чиновников» (это был Стив Боллмер), просмотрев резюме Симоньи, решил, что ему стоит встретиться с Биллом. Гейтс в это время был на совещании и к тому времени, когда он освободился, Симоньи уже было пора в аэропорт, поэтому Гейтс поехал туда вместе с ним, чтобы побеседовать по дороге. У них сразу установились взаимопонимание и личная симпатия. Вскоре Симоньи получил приглашение работать в Microsoft и принял его.

Решением, которое Симоньи предложил для проблемы сотрудничества нескольких разработчиков, было учредить новую должность, которую назвали «мастер-программист». Она чем-то напоминала средневековых ремесленников: именно на «мастере» лежала полная ответственность за разработку дизайна программы и ее написание. Под руководством мастера должна была работать команда ассистентов-«подмастерьев». Их задачей была отладка и оптимизация программы.

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

Благодаря известной тенденции Microsoft все доводить до крайности, идея мастера-программиста очень быстро себя исчерпала. Программные продукты скоро стали такими объемными, что с ними уже не мог в одиночку управиться даже мастер-программист. Была еще одна более фундаментальная проблема: мастер-программист не всегда оказывался способным разработать удачный дизайн программного продукта. Поскольку программы становились все более изощренными, становилось все более важным приспособить их к потребностям клиентов, а эта задача существенно отличалась от собственно программирования. Для одного человека одновременно решать обе эти задачи было непосильным трудом. Конечно, случается, что отличный корректор одновременно оказывается и талантливым драматургом, но все же если вы наняли человека на работу для выполнения одного круга обязанностей, а затем поручаете ему что-то совсем другое — вас, вероятно, будет ждать разочарование.

Титул «мастер-программист» никогда широко не использовался — уж слишком патриархально он звучал даже для компании, переполненной «визжащими доминантными мужскими особями», поэтому название изменили на более нейтральное — «менеджер программы». Теперь именно оно стало стандартным для всей отрасли программного обеспечения, но сегодняшним пониманием обязанностей менеджеров программ мы в основном обязаны создателю электронных таблиц Excel Джейбу Блюменталю.

Подобно многим бывшим сотрудникам Microsoft, сделав в этой корпорации солидное состояние, Блюменталь покинул ее, чтобы посвятить себя самым разнообразным занятиям в своей «постмайкрософтовской» карьере. Блюменталь руководит школой обучения параглайдингу — полету на парашютах — в Каскадных горах, а также преподает математику и физику в школе Lakeside, которую он когда-то окончил (Билл Гейтс также выпускник этой школы). Ключевым «озарением» Блюменталя стало то, что менеджерам программы не обязательно знать программирование. Он решил, что основное для этого человека — представить себе, как должен выглядеть и какими свойствами должен обладать будущий программный продукт. Менеджер программы должен написать не сам код программы, а ее спецификацию (в корпорации ее называют для краткости «спек», spec), в которой описываются эти представления. Следующая задача менеджера программы — руководить разработчиками-программистами, чтобы они точно и в срок воплотили спецификацию в программном продукте.

Отношения между менеджерами программы и разработчиками довольно странные: с точки зрения разработчиков, именно они делают реальную, тяжелую и полезную работу, а менеджер программы — это «низшая форма жизни»[74], получающий непонятно за что кучу денег, несущий всякую чушь тип с зализанным пробором, похожий на пресловутого «бос-с-а» из серии карикатур о Дилберте.

А вот по мнению менеджеров программ, именно они делают творческую работу, а программисты — чисто техническую. Менеджер программы «играет на рояле», разработчики — это те ребята, которые его перетаскивают.

Учитывая такую разницу в восприятии, совсем не удивительно, что авторитет менеджеров программ достаточно неустойчив. Менеджеры программ дипломатично сравнивают свою работу с попыткой пасти стаю котов. Разработчики (их гораздо больше, чем менеджеров) более открыто выражают свое презрение последним. Их любимая шутка: «Зовите менеджера программы каждый раз, когда возникает задача, соответствующая их уровню компетентности — например, когда нужно заказать пиццу». Разработчик Адам Дэвид Барр вспоминает совещание в Microsoft, на котором докладчику не удавалось показать нужные слайды на большом проекционном экране. «Что, разве нет ни одного менеджера программы под рукой?[75]» — выкрикнул кто-то. Все захихикали. «А что, не хватает еще одного игрока в гольф?» — спросил кто-то еще. Раздался дикий взрыв хохота.

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

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

Есть один пункт, по которому у менеджеров программ и разработчиков единое мнение: и те, и другие смотрят на тестеров свысока. Быть тестером — это все равно что оказаться единственным зубным техником в отделе, где все остальные — дипломированные врачи. Все будут усмехаться: «А, это тот парень, который не сумел поступить в нормальный медицинский институт». Действительно, работа тестера вряд ли может помочь принести уважение и почет. Тестеры сами не исправляют обнаруженные ими сбои и недостатки — они только сообщают о них разработчикам, чтобы те смогли их исправить.

Хорошо. Вероятно, тестирование не предъявляет таких высоких интеллектуальных требований, как другие виды работ. Что с того? В корпорации Microsoft такая конкурентная атмосфера, что никто не может себе позволить признаться, что он менее сообразителен и вообще «менее» в чем бы то ни было. Тестеры очень заботятся о своем статусе в корпорации, и на официальном уровне Microsoft старается, насколько это возможно, не подчеркивать различия между тремя упомянутыми выше должностями и профессиями. «Если вы когда-либо отважитесь даже намекнуть, что тестерам не нужен такой же высокий уровень компетентности, как разработчикам или менеджерам программ, на вас сразу же прикрикнут»[76], — говорит Адам Дэвид Бэн. Менеджеры корпорации и сотрудники отдела персонала настаивают на том, что и разработчики, и менеджеры программ, и тестеры — все одинаково умны, способны к творчеству и амбициозны. Они даже разработали особую «мифологию», которая позволяет объяснить те проявления неравенства, которые невозможно отрицать. Суть ее в том, что у каждой из трех групп сотрудников есть свои особые таланты. Это «разные» таланты, но благодаря мистическому стечению обстоятельств, все они «одинаково важны». Это утверждение, по мнению Барра, полная выдумка и не соответствует действительности.[77]