Человеческий фактор: успешные проекты и команды
Шрифт:
ВТОРОЙ ЗАКОН ТЕРМОДИНАМИКИ МЕНЕДЖМЕНТА: Энтропия в организации постоянно увеличивается.
Именно поэтому в более старых организациях теснее и не так весело работать, как в энергичных молодых компаниях.
С этим явлением вряд ли можно бороться в глобальном масштабе, однако в своей собственной области вы должны ему противостоять. Наиболее успешный руководитель будоражит локальную энтропию, нанимая подходящих людей и разрешая им быть собой, пусть даже приходится отступать от корпоративных норм. Когда у вашей организации начнётся трупное окоченение, орган, находящийся под вашим контролем, будет
15. Как нанять жонглёра
Менеджер: «Как давно вы жонглируете?» Кандидат: «Ну, примерно шесть лет».
Менеджер: «Тремя, четырьмя, пятью шарами умеете жонглировать?» Кандидат: «Да, да и да».
Менеджер: «Работаете с горящими предметами?» Кандидат: «Конечно».
Менеджер: «…ножами, топорами, открытыми коробками с сигарами, мягкими широкополыми шляпами?» Кандидат: «Мне всё равно, чем жонглировать».
Менеджер: «А какую-нибудь весёлую скороговорку знаете?» Кандидат: «Онабесподобна».
Менеджер: «Что ж, мне нравится. Думаю, мы вас возьмём». Кандидат: «Аааа… Не хотите посмотреть, как я жонглирую?» Менеджер: «Хм, мне как-то это не пришло в голову».
Нелепо брать на работу жонглёра, не увидев сперва, как он жонглирует. Это просто здравый смысл. И всё-таки, когда вы принимаете решение нанять инженера, проектировщика, программиста или руководителя группы, правила здравого смысла часто отходят на второй план. Вы не просите показать проект, или программу, или что-то ещё. По сути дела это просто «собеседование».
Вы нанимаете человека, чтобы создавать продукт, предположительно подобный тому, что он или она уже создавали в прошлом. Вам требуется изучить образцы тех продуктов, чтобы оценить качество работы кандидата. Это может показаться очевидным, но руководители проектов по разработке почти всегда упускают это из виду. На собеседовании существует некая поверхностная сдержанность в отношении примеров выполненных работ. Словно неписаное правило, разрешающее интересоваться прошлыми проектами, но не требовать у кандидата образцы работы. А ведь если спросить, большинство кандидатов будут рады что-нибудь показать.
Весной 1979 года, когда мы занимались преподавательской работой на западе Канады, позвонил преподаватель информатики одного местного университета. Он предложил как-нибудь вечерком угостить нас пивом в обмен на идеи. От таких предложений мы редко отказываемся. То, что мы узнали от него в тот вечер, стоит определённо больше, чем то, что он узнал от нас.
Этот преподаватель честно объяснил, что ему нужно признание в своей области, а для этого необходимо, чтобы его ученики получили хорошие предложения, много хороших предложений. «Диплом Гарварда ценен сам по себе, а вот наш диплом не стоит ничего. Если выпускники этого года быстро не найдут работу, то работы не будет и у меня.» Поэтому он разработал формулу, позволяющую сделать его выпускников как можно более привлекательными на рынке рабочей силы. Разумеется, он преподавал им современные методы конструирования систем, включая структурный анализ и основанное на данных проектирование, сокрытие информации, структурное программирование, командное рецензирование и метрики. Он также предоставлял им работу над реальными проектами в местных компаниях и агентствах. Однако важнейшим в этой формуле стало портфолио. В портфолио каждый учащийся собирал примеры своей работы.
Он объяснил учащимся, как следует представлять портфолио на интервью:
«Я
В последующие годы мы ещё часто слышали об этом малоизвестном университете и этих портфолио. Нам доводилось видеть агентов по найму аж из Северной Каролины и Флориды, регулярно совершавших набеги на далёкий канадский учебный городок в надежде заполучить его выпускников.
Конечно, со стороны преподавателя было умно придумать такой способ придавать своим выпускникам дополнительное ускорение, но в тот вечер нас больше всего поразило, что интервьюеров всегда удивляли портфолио. Это означало, что они не имели привычки предлагать кандидатам приносить портфолио на собеседования. Но почему нет? Что может быть разумнее, чем попросить каждого кандидата принести на собеседование примеры своих работ?
Если так важно, чтобы новый сотрудник хорошо владел различными навыками работы, почему не спроектировать тест на пригодность, чтобы измерить его квалификацию? В нашей отрасли идеей тестирования на профпригодность интересуются давно и с переменным успехом. В шестидесятые годы эта идея была весьма популярной. Сегодня же, вероятно, вы и ваша организация уже распрощались с ней. Но если нет, мы знаем одну важную причину, по которой распрощаться все же стоит: тесты измеряют не то, что нужно.
Тесты на профпригодность почти всегда ориентированы на задачи, которые человек будет решать непосредственно после найма. Эти тесты определяют, насколько вероятно, что человек будет хорош в роли аналитика или программиста, или в том, что требуется для данной конкретной должности. Легко можно ознакомиться с тестами практически для любой технической области, и все они весьма тщательно опробованы в плане предсказания того, насколько хорошо будет работать новый человек. Ну и что? Успешный новый сотрудник может успешно выполнять эти задачи в течение нескольких лет, а затем стать лидером команды, или возглавить проект, или продвигать продукты. Этот человек в конечном итоге может потратить два года на задачи, определённые тестом, а потом двадцать – на совершенно другие.
Известные нам тесты на профпригодность в основном ориентированы на левое полушарие мозга. Дело в том, что новые сотрудники, как правило, выполняют задачи, связанные с левым полушарием. А вот то, чем они будут заниматься в своей дальнейшей жизни, в гораздо большей степени связано с правым полушарием. Руководство в частности требует целостного мышления, эвристических суждений, а также основанной на опыте интуиции. Поэтому тест на профпригодность может выявить людей, более полезных на короткой дистанции, но в будущем вряд ли успешных. Возможно, проводя тест на профпригодность, следует нанимать тех, кто его провалит.