Уильям Паундстоун - Найти умного. Как проверить логическое мышление и творческие способности кандидата

• Название: Найти умного. Как проверить логическое мышление и творческие способности кандидата
• Автор: Уильям Паундстоун
• Жанр: Управление, подбор персонала
• Год: 2014
• ISBN: 978-5-9614-3515-3

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

---

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее изощренным является миф о тестерах. Что можно сказать о таланте «обрушивать» Excel? Грант Джордж, вице-президент по тестированию продукции, так говорит об этом: «Наиболее успешные тестеры просто думают по-другому, не так, как разработчики и менеджеры программ. Мы постоянно критикуем и высказываем мнение о качестве всего, что мы видим, к чему прикасаемся и с чем входим в контакт или используем в своей повседневной жизни. Мы живем для того, чтобы критиковать и улучшать… Господи, благослови нашу отрасль и Microsoft! Какой замечательный способ использования нашей страсти добиваться во всем отличного качества для совершенствования продукции, которую используют миллионы людей!»

Джордж не единственный человек, высказывающий подобную точку зрения, которую можно обобщить так: «У тестеров всегда есть свое мнение, а у других людей – не всегда».

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