Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Руководители и технические лидеры (и те и другие) В любой команде инженеров обычно есть лидер. Иногда в команду приходит опытный руководитель, а иногда простой разработчик продвигается на роль лидера (обычно из небольшой команды). В зарождающихся командах обе роли может играть один и тот же человек — техниче- ский руководитель (TLM, tech lead manager). В больших командах обязанности руко- водителя может выполнять опытный менеджер по персоналу, если старший инженер с большим опытом работы берет на себя функции технического лидера. Несмотря на то что руководитель и технический лидер играют важные роли в развитии команды, навыки, необходимые для достижения успеха в каждой роли, совершенно разные. Руководитель Многие компании привлекают для управления командами разработчиков обучен- ных руководителей, которые могут почти ничего не знать о разработке ПО. Однако 94 Глава 5. Как стать лидером в команде с самого начала в Google было решено, что руководители команд, занимающихся программной инженерией, должны иметь опыт инженерной работы. Это предполагает прием на работу опытных руководителей, которые раньше были инженерами-про- граммистами, или обучение инженеров-программистов руководству (подробнее об этом ниже). На самом высоком уровне руководитель отвечает за эффективность, производитель- ность и удовлетворенность каждого члена команды, включая технического лидера, и при этом следит за тем, чтобы продукт удовлетворял потребности бизнеса. По- скольку потребности бизнеса и потребности отдельных членов команды не всегда совпадают, руководитель часто находится в затруднительном положении. Технический лидер Технический лидер (TL, tech lead) команды — это человек, который отчитывается перед руководителем команды, отвечает (сюрприз!) за технические аспекты продукта, включая выбор технических решений, архитектуру, приоритеты, скорость работы и общее управление проектом (в крупных командах ему могут помогать руководи- тели программ). Технический лидер обычно работает рука об руку с руководителем, чтобы укомплектовать команду кадрами и распределить задачи между инженера- ми в соответствии с их навыками и знаниями. Большинство технических лидеров одновременно являются разработчиками, что часто ставит их перед выбором: что-то быстро сделать самому или делегировать работу члену команды, который справится с ней медленнее. Последнее чаще всего является правильным решением, поскольку помогает увеличить уровень способностей и возможности команды. Технический руководитель В небольшой и только зарождающейся команде, где лидер должен обладать обшир- ными техническими навыками, руководство часто осуществляется техническим руководителем — одним человеком, способным руководить людьми и управлять тех- ническими потребностями команды. Иногда технический руководитель — это самый старший член команды, который до недавнего времени был простым разработчиком. В Google принято, чтобы крупные, хорошо зарекомендовавшие себя команды имели пару лидеров — технического лидера и руководителя, работающих вместе как парт- неры, поскольку трудно совмещать обе роли без риска психологического выгорания. Работа технического руководителя сложна и часто требует умения балансировать между выполнением работы разработчика, делегированием этой работы и управ- лением персоналом. Поэтому техническим руководителям часто требуются вы- сокая степень наставничества и помощь со стороны более опытных технических руководителей. (Рекомендуем начинающему техническому руководителю помимо изучения курсов, которые предлагает Google по этой теме, найти более опытного наставника, который сможет регулярно консультировать его по мере вхождения в новую роль.) Переход от роли разработчика к роли лидера 95 КЕЙС: ВЛИЯНИЕ БЕЗ ПОЛНОМОЧИЙ Конечно, вы можете заставить подчиненных выполнять работу, но совсем другое дело управлять теми, кто находится за пределами компании или даже занимается созданием других продуктов. Способность «влиять без полномочий» — одно из самых сильных ли- дерских качеств, которое вы можете развить. Например, в течение многих лет Джефф Дин, старший инженер-разработчик и, пожалуй, самый известный гуглер внутри Google, возглавлял очень небольшую команду инженеров Google, но его умение влиять на технические решения и направления развития помогало достигать целей как внутри инженерной организации, так и за ее пределами (благодаря его статьям и публичным выступлениям). Другой пример: в свое время я создал команду «The data liberation front», насчитывающую человек пять инженеров, которая смогла организовать экспорт данных более чем в 50 про- дуктов Google через созданный нами Google Takeout. Наши стремления не были подкрепле- ны официальными приказами на исполнительном уровне Google. Так как же нам удалось сподвигнуть сотни инженеров внести свой вклад в нашу идею? Стратегическая потребность в идее, демонстрация ее связи с целями и приоритетами компании и взаимодействие с не- большой группой инженеров, занимающихся разработкой инструмента, помогли другим группам легко и быстро интегрироваться с Takeout. Переход от роли разработчика к роли лидера Назначенный официально или нет, кто-то должен сесть за руль. Если ваш продукт начал развитие и вы имеете достаточно мотивации и не хотите ждать, тогда этим «кем-то» можете стать вы. Вас могут втянуть в разрешение конфликтов, принятие решений и координацию действий другие члены команды. Это происходит постоянно и часто совершенно случайно. Возможно, вы не собирались становиться «лидером», но это произошло — вы заболели «менеджеритом». Даже если вы поклялись никогда не руководить, в какой-то момент в своей карьере вы можете оказаться на руководящей должности, особенно если добьетесь успеха в роли разработчика. В остальной части этой главы мы поможем вам понять, что делать в такой ситуации. Мы не собираемся убеждать вас стать руководителем, а просто хотим показать, что лучшими считаются лидеры, которые служат команде, используя принципы смирения, уважения и доверия. Понимание тонкостей лидерства является важным умением, помогающим влиять на направление работы. Если вы хотите управлять кораблем проекта, а не просто плыть на нем в роли пассажира, вам нужно знать, как ориентироваться в бурных водах, иначе вы сами (и проект) сядете на мель. Единственное, чего нужно бояться, ...эм-м, всего Помимо общего чувства тревоги, которое испытывают многие, когда слышат слово «руководитель», существует еще масса причин, почему большинство людей не хотят становиться руководителями. Самая веская причина, которую можно услышать 96 Глава 5. Как стать лидером в команде в мире разработки ПО, — необходимость тратить гораздо меньше времени на создание кода. Это верно и для технических лидеров, и для руководителей, и я расскажу об этом далее в этой главе, но сначала мы рассмотрим еще несколько причин, по которым большинство из нас не горят желанием становиться руководителями. Те, кто большую часть карьеры занимается созданием кода, обычно заканчивают день чем-то, что можно продемонстрировать (код, документ с описанием дизайна или целый список исправленных ошибок), и говорят: «Вот что я сделал сегодня». Но в конце напряженного дня, посвященного «управлению», нередко возникает мысль: «Сегодня я ни черта не сделал». Однако это равносильно тому, что, потратив годы на подсчет яблок, которые вы собирали каждый день, и перейдя на работу по выращиванию бананов, вы в конце каждого дня будете говорить себе: «Я не собрал ни одного яблока», забывая про цветущие банановые пальмы рядом с собой. Оценить количественно управленческую работу сложнее, чем подсчитать созданные видже- ты, однако даже простая удовлетворенность и продуктивность команды являются ничуть не менее важной оценкой работы лидера. Просто не попадайтесь в ловушку с подсчетом яблок, занимаясь выращиванием бананов 1 Еще одна важная причина уклонения от руководящей работы, часто не высказы- ваемая прямо, корнями уходит в знаменитый «принцип Питера», который гласит: «Каждый сотрудник имеет тенденцию подняться до уровня своей некомпетентности». Чтобы избежать этого, в Google человеку предлагается выполнять более сложную работу (то есть «превзойти самого себя») в течение ограниченного времени, и только потом принять решение о переходе на новый уровень. Многие из нас сталкивались с руководителями, неспособными выполнять свою работу или просто плохо управ- лявшими людьми 2 , и мы знаем тех, кому довелось работать только с плохими руково- дителями. Если всю свою карьеру человек работал только с плохими руководителями, откуда у него может возникнуть желание самому стать руководителем? Разве может возникнуть стремление получить роль, которую вы не можете выполнять? Есть, однако, веские причины, чтобы стать техническим лидером или руководителем. Во-первых, это возможность масштабирования своих знаний и умений. Даже если вы прекрасно пишете код, его объем ограничен. А теперь представьте, сколько кода может написать команда великих инженеров под вашим руководством! Во-вторых, вы можете открыть в себе новые таланты — многие, оказавшись втянутыми в управ- ление проектом, обнаруживают, что прекрасно справляются с выбором решений, оказанием помощи и обеспечением нужд команды или компании. Кто-то должен вести за собой, так почему не вы? 1 Еще одно отличие, к которому нужно привыкнуть: плоды труда руководителя обычно зреют намного дольше. 2 Не стоит принуждать людей становиться руководителями: если инженер способен писать отличный код и вообще не хочет управлять людьми или руководить командой, заставив его работать в роли руководителя или технического лидера, вы потеряете прекрасного инженера и получите плохого руководителя. Принуждение — не только плохая, но и по-настоящему вредная идея. Руководитель 97 Лидерство как служение Иногда кажется, что руководителей поражает что-то вроде болезни, когда они за- бывают обо всех ужасах, которые с ними творили их руководители, и внезапно на- чинают делать то же самое со своими подчиненными. Вот далеко не полный список симптомов этого заболевания: микроуправление, игнорирование неэффективных сотрудников и прием на работу слабых специалистов. Без своевременного лечения эта болезнь может убить всю команду. Лучший совет, который я получил, когда впервые занял руководящий пост в Google, дал мне Стив Винтер, занимавший в то время должность технического директора. Он сказал: «Прежде всего, сопротивляйся желанию управлять». Одно из главных побуждений новоиспеченного руководите- ля — активно «управлять» своими сотрудниками, потому что именно это должен делать руководитель, верно? Часто это устремление приводит к катастрофическим последствиям. Избавиться от острых форм «менеджерита» поможет мантра: «Лидерство — это служение». Она прямо говорит, что самое ценное, что можно сделать в роли лиде- ра, — служить своей команде, подобно тому как дворецкий или мажордом служит своему хозяину и заботится о его здоровье и благополучии. Как лидер-слуга вы должны стремиться создать атмосферу смирения, уважения и доверия. Это может выражаться в устранении бюрократических препятствий, с которыми не справляются члены команды, помощи в достижении согласия или даже покупке еды для тех, кто допоздна работает в офисе. Лидер-слуга засыпает ямы, чтобы облегчить путь своей команде, консультирует при необходимости, но при этом не боится испачкать руки. Единственное, чем должен управлять лидер-слуга, — это техническое обеспечение и социальное здоровье команды. Как бы ни было заманчиво сосредоточиться ис- ключительно на техническом обеспечении, социальное здоровье команды столь же важно (но управлять им намного сложнее). Руководитель Итак, что же должен делать руководитель в современной софтверной компании? До эры повсеместного распространения компьютеров слова «управление» и «труд» описывали почти противоположные понятия. Руководитель располагал всей полно- той власти, чтобы направлять коллективный труд на достижение своих целей. Но со- временные софтверные компании работают иначе. «Начальник» — почти бранное слово Прежде чем говорить об основных обязанностях руководителя в Google, обратимся к истории. Современные представления о начальнике как об узурпаторе сформиро- вались при военной иерархии и были подхвачены в ходе промышленной революции более ста лет назад! В то время повсюду появлялись фабрики, для обслуживания машин которых требовались рабочие (обычно неквалифицированные) и начальни- ки — для управления. Спрос на работу был высок, и у начальников не было доста- 98 Глава 5. Как стать лидером в команде точно мотивации для хорошего отношения к подчиненным или улучшения условий их труда. Такие негуманные трудовые отношения успешно существовали много лет, пока работники выполняли относительно простые задачи. Начальники часто обращались с сотрудниками как погонщики с мулами: если не удавалось приманить морковкой — били палкой. Метод кнута и пряника пережил переход от фабрик 1 к современным офисам, где в середине XX века среди работни- ков, выполнявших одну и ту же работу много лет, процветал стереотипный образ невозмутимого начальника-погонщика. В некоторых отраслях эта традиция продолжается и поныне, даже там, где требуются творческое мышление и умение решать проблемы, несмотря на многочисленные ис- следования, подтверждающие неэффективность и вредность кнута и пряника в твор- ческих областях. В прошлом работники сборочного конвейера могли обучиться за несколько дней и быть быстро заменены по желанию начальника. Но современным разработчикам ПО могут потребоваться месяцы, чтобы освоиться в новой команде, поэтому они нуждаются в заботе, времени и пространстве, чтобы думать и творить. Современный руководитель Большинство людей все еще используют слово «начальник», несмотря на то что его первоначальное значение устарело. Само название часто побуждает новых руково- дителей управлять своими подчиненными. Руководители могут вести себя подобно родителям 2 , на что сотрудники вполне естественно реагируют как дети. А теперь сформулируем понятие «руководить» в контексте смирения, уважения и доверия: если руководитель выказывает свое доверие сотруднику, тот испытывает позитивное давление и старается это доверие оправдать. Это так просто. Хороший руководитель прокладывает путь команде, заботясь о ее безопасности и благополучии, и в то же время следит, чтобы ее потребности были удовлетворены. Если хотите вынести какой-то общий урок из этой главы, тогда запомните следующее: Рядовые начальники заботятся о том, как что-то сделать, а великие руководите- ли — о том, что можно сделать (и доверяют своей команде выяснение деталей, как это сделать). Несколько лет назад к моей команде присоединился новый инженер Джерри. Про- шлый руководитель Джерри (в другой компании) был непреклонен, заставляя подчиненных сидеть за столами с 9:00 до 17:00 и считая, что если работник куда-то отлучался, значит, он работал не в полную силу (что, конечно, совершенно нелепо). В свой первый рабочий день Джерри пришел ко мне в 16:40 и пробормотал извинения 1 Подробнее об оптимизации передвижения работников на фабрике читайте в статьях о на- учной организации труда или тейлоризме, где особо подчеркивается важность влияния на моральный дух работников. 2 Если у вас есть дети, то вы наверняка вспомните, когда в первый раз сказали своему ребенку что-то, что заставило вас остановиться и воскликнуть (возможно, даже вслух): «Черт возьми, я веду себя как мои родители!» Руководитель 99 за то, что вынужден уйти на 15 минут раньше, так как у него запланирована встреча, которую он не смог перенести. Я улыбнулся и сказал: «Пока вы выполняете свою работу, мне все равно, когда вы покинете офис». На несколько секунд Джерри замер в недоумении, затем кивнул и пошел дальше. Я относился к Джерри как ко взросло- му — он всегда выполнял свою работу, и мне никогда не приходилось беспокоиться о том, сидит ли он за столом, потому что ему не нужна нянька. Если ваши сотрудники настолько не заинтересованы в работе, что их должен подгонять начальник-нянька, это и есть ваша настоящая проблема. НЕУДАЧА — ТОЖЕ ВАРИАНТ Еще один способ стимулировать команду — дать людям почувствовать себя защищенными, чтобы они начали рисковать. Если вам удастся создать в команде атмосферу психологиче- ской безопасности, ее члены смогут быть самими собой и не опасаться негативной реакции от вас или коллег. Риск — захватывающая штука, но большинство людей боятся рисковать, и во многих компаниях принято избегать риска любой ценой, выбирать консервативный подход к работе и стремиться к небольшим успехам, даже когда больший риск может дать многократно больший результат. В Google говорят, что, пытаясь достичь невозможного, вы, вероятно, потерпите неудачу, но, скорее всего, такая неудача даст вам больше, чем вы- полнение работы, которая точно вам под силу. Чтобы создать культуру, в которой допустим риск, команда должна знать, что неудачи — это нормально. Итак, давайте примем раз и навсегда: терпеть неудачу — это нормально. На самом деле мы предпочитаем думать о неудаче как о быстром способе научиться чему-то (при условии, что одна и та же неудача не повторяется), а не обвинять в ней кого-то. Быстро потерпеть неуда- чу — это хорошо, потому что на карту поставлено не так много. Неудача после длительной работы тоже может преподать ценный урок, но она воспринимается болезненно, потому что при ней потери больше (обычно времени инженера). Таким образом, неудача, влияю- щая на клиентов, является самой нежелательной, но она же преподносит наиболее ценный урок. Как упоминалось выше, каждый раз, когда в Google происходит серьезная неудача, мы выполняем вскрытие, документируем события, приведшие к неудаче, и разрабатываем последовательность шагов, которые предотвратят подобное в будущем. Эта процедура — не поиск виноватых и не бюрократическая проверка: главная ее цель — сосредоточиться на сути проблемы и решить ее раз и навсегда. Это очень сложно, но эффективно (и надежно). Личные успехи и неудачи немного отличаются. Одно дело хвалить за личные успехи, но стремление возложить личную вину в случае неудачи — отличный способ рассорить команду и отбить в людях охоту рисковать. Потерпеть неудачу — допустимо, но неудачи должны быть общими для всей команды, и вся команда должна учиться на ошибках. Если человек добивается личного успеха, хвалите его перед командой. Если терпит неудачу — изложите конструктивную критику в частном порядке 1 . В любом случае воспользуйтесь неудачей как возможностью проявить смирение, уважение и доверие, чтобы помочь команде учиться на ошибках. 1 Публичная критика не только неэффективна (она заставляет людей защищаться), но и редко необходима, а чаще является просто излишне жестокой. Можете быть уверены, что осталь- ные члены команды уже знают, что человек потерпел неудачу, поэтому нет необходимости заострять на этом внимание. |