Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

Мотивация программистов деньгами среди стандартного набора американских приемов менеджмента является «наименьшим общим кратным». С другой стороны, имейте в виду, что деньги – это наименее эффективный способ построения командной атмосферы в многокультурной среде. Что же делать? Проанализировать все факторы, способные стимулировать к работе существующую команду или новых сотрудников, которых вы только собираетесь привлечь. По результатам недавнего опроса 100 наемных работников, не являющихся гражданами США, Дин Бетменг (Dene Bettmeng) делает следующие выводы:

«Многие сотрудники рассматривают в качестве основных преимуществ работы в американских компаниях корпоративную культуру и корпоративные правила, а также технологическую оснащенность. В частности, их привлекают перспективы карьерного роста, заработная плата и льготы, равно как и возможность изучать и применять новые технологии. Все эти люди считают, что работать в компании, расположенной в США, в целом предпочтительнее, чем в какой бы то ни было другой стране. Помимо вышеперечисленных преимуществ, они ценят политическую стабильность, напряженный ритм деятельности и командный дух» [109] Из отчета наконференции Network World Fusion (http://vww.nwfusion.corn/careers/2001/0402mari.html). .

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

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

Урок 1. Впоследствии выяснилось, что для телефонных интервью консультантам предоставили длиннющие шпаргалки с ответами на все мыслимые и немыслимые вопросы. Стоило мне спросить: «Какое средство моделирования данных вы предпочитаете?» – как абонент, выдержав паузу, переспрашивал: «Повторите, пожалуйста, вопрос – я не совсем понял, о чем речь». В это время он листал шпаргалки в поисках правильного ответа. Отыскав его, он отвечал: «Больше всего мне нравится ERStudio, но у него есть такие-то недостатки. ERWin – тоже ничего, он выгодно отличается тем-то и тем-то». Понимаете, дословно повторяя содержимое шпаргалок, они говорили все то, что я хотел услышать. Мне уже стало казаться, что группа будет состоять исключительно из гениев. Вскоре после начала работы над проектом я понял, как сильно ошибался.

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

Урок 2. Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок выражает согласие!

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

Урок 4. Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.

Урок 5. Последняя индийская перепись населения зафиксировала в стране более 200 языков и диалектов. Поскольку все мои сотрудники приехали из разных регионов Индии (кстати сказать, друг друга они недолюбливали), между собой они общались исключительно на ломаном английском. Многочисленные улыбки и жесты отнюдь не способствовали преодолению взаимного непонимания.

Урок 6. Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.

Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.

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