Майкл Шрепфер (Michael Schroepfer, вице-президент по разработке Facebook, в прошлом - вице-президент по разработке Mozilla) прочитал советы по выживанию программиста в Google (piaw.blogspot.com/2010/08/tips-for-noogler-engineers.html) и решил вкратце высказать свое мнение об основных ошибках этой компании по управлению инженерией (engineering management).

Прежде всего, говорит он, нужно отметить важные тезисы. Google - невероятно успешная компания. Она изобрела и запустила в производство многие важные компьютерные научные концепции.

При 1500 сотрудников в Google было больше гибкости и меньше бюрократии, чем в большинстве стартапов на 200 человек. При любом размере Google был лучшим местом для работы среди компаний своего класса. При текущем размере Google - все еще более привлекательное место для работы, чем Oracle, Cisco, Microsoft, Adobe, Apple и многие другие хорошо известные фирмы. Именно это делает ошибки менеджмента более заметными.

Данный список не претендует на полноту, всесторонность и даже на то, чтобы выделить главные ошибки.

1. Тренинги ведущих программистов (Tech Lead) и менеджеров

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

Нужно отделить тим-билдинг от тренингов по менеджменту и проводить последний внутри компании, а не пользоваться услугами сторонних организаций. Тренинги по менеджменту должны проводить менеджеры высшего уровня, а не люди из HR. Дорогостоящие тренинги не требуются.

2. Стимулы для ведущих программистов

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

Хорошие ведущие программисты (которые берут себе неблагодарные участки работы и отдают команде важные проекты, чтобы помогать им развиваться) явно выделяются во время анализа качества работы команд и выборе лучших сотрудников, подходящих для повышения.

Система поощрений для ведущих программистов активно провоцирует плохое поведение.

3. Одобрение, признание

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

4. Набор персонала

На уровне высшего руководства считается критически важной задачей. До 2005 года не был привязан к системе поощрения сотрудников. После этого стали регистрировать, кто и сколько проводил интервью о приеме на работу, но только этот один параметр, больше ничего не отслеживается.

Статус "активного интервьюера" получает сотрудник с показателем 0,1 (по шкале от -1 до 4), и он может получить дополнительные бонусы до $10 тыс. или больше. Этот статус является ошибкой.

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

Здесь нужно сказать, что проведение собеседований - это отдельный навык, и не у всех он есть. Если активное проведение собеседований негативно сказывается на чьей-то производительности, то нужно принять меры: или снизить количество интервью, или включить их в список непосредственных обязанностей работника.

Нужно обеспечивать статистику по среднему количеству собеседований. Нужно вычислять сотрудников, которые вообще не должны этим заниматься: или проводить с ними тренинги, или напрямую освобождать от этой работы.

5. Повышение

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

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

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

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

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

Выводы

Поощрения очень важны. Они очень сильно влияют на работу компании. Но во многих случаях лучше никакого, чем слишком малое поощрение.

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

Многие важные вещи хорошо видны на нижних уровня компании, но незаметны менеджменту. Менеджеры должны управлять лично и физически находиться рядом с сотрудниками, а не надеяться только на опросы. Опрос программистов в 2003-2004 годах показал, что основной проблемой они назвали "недостаток менеджеров". По иронии, решение этой проблемы они считали нежелательным.

Анатолий АЛИЗАР