От разработчика до руководителя. Менеджмент для IT-специалистов Фурнье Камиль

6

Управление группой команд

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

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

Главный инженер отвечает за важные технические вопросы в организации. Обычно он руководит инженерами при создании целой линейки продукции или в выполнении ими множественных технических функций. Главному инженеру бывают обычно подчинены и технические руководители групп, и отдельные разработчики, и ведущие инженеры-программисты.

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

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

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

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

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

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

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

Риск выпасть из темы значительно увеличивается, если вы перестаете участвовать в написании кода задолго до переключения на менеджерскую работу и не изучите глубоко хотя бы один язык программирования. Я настоятельно выступаю за то, что перед уходом в менеджеры вы должны добиться достаточного мастерства в программировании. В моем случае это заняло 10 лет, включая мои выпускные и магистерский дипломы. Возможно, вы способны достичь этого быстрее, чем я, однако внимательно и честно оценивайте себя. Считаете ли вы, что свободно владеете хотя бы одним языком программирования, чтобы продуктивно писать кодовую базу? Способны ли вы ускорить работу, используя стандартную среду выполнения и работая в стандартных платформах и стандартных библиотеках? В дальнейшем у вас могут уйти глубокие слои знаний, но свобода использования программного языка (подразумевающая владение стандартными инструментами программирования, работу с библиотеками и вычислительным окружением) — то, что остается надолго.

Свободное владение языком программирования подразумевает хорошее знание того, как на нем продуктивно работать над созданием программ, прежде всего с другими членами команды. Без ощущения единого ритма в разработке программы вам будет трудно в работе над одним из самых сложных на этом этапе вопросов — «расшивкой» командных проблем и обеспечением плавной работы команды над созданием качественного софта.

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

Спросите технического директора: я скучаю по коду!

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

Почти все, кто с сугубо инженерной должности уходят в менеджеры, переживают переходный период, когда часто спрашивают себя, не совершили ли ошибку. Более того, многие беспокоятся, что в ходе трансформации теряют все ценные навыки и знания. Спросите себя, не живет ли внутри вас мысль, что менеджер — это не работа. В высокотехнологичных отраслях, и особенно в IT-индустрии, полно людей, пренебрежительно относящихся к менеджменту: они полагают, что это занятие не так важно, как создание кода. Однако менеджмент — работа. Необходимая и важная, и сейчас это ваша работа.

Написание кода изобилует множеством быстрых побед, особенно в случае, если его пишет опытный разработчик. Вы видите, как успешно проходят тесты, как начинают жить новые программы, вы что-то компилируете, устраняете проблемы. Управление коллективами и проектами дает меньше быстрых побед, особенно для начинающих менеджеров. В этих условиях вполне естественно ностальгировать по более простым временам, когда действовали только вы и ваш компьютер и вам не нужно было иметь дело со сложными и непонятными человеческими существами. Возможно, такую же ностальгию испытывали вы по школьным дням и тогда, когда начали работать в постоянном штате компании. Потому что к моменту окончания школы вы, скорее всего, хотя бы понимали, чего здесь ожидать. В принципе ностальгия по более простым временам и некоторый страх перед тем, что вас ожидает, — нормально. Однако получить все одновременно нельзя. Чтобы стать хорошим менеджером, нужно приобретать устойчивые навыки, а это подразумевает, что вам придется до известной степени пожертвовать инженерными интересами и пристрастиями. Это компромисс, и приходится на него идти, если вы хотите чего-то добиться.

Организация времени: в конце концов, что же важно?

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

Подождите, ничего подобного. Это не война.

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

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

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

Таблица 6.1. Приоритеты в организации вашего времени

Задачи

Несрочные

Срочные

Важные

Стратегические: выделять время

Очевидно, нужно выполнять

Неважные

Очевидно, можно избегать

Побуждают отвлечься

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

Сложности в распределении времени возникают тогда, когда вы утрачиваете ощущение важности проблемы. Срочность обычно воспринимается острее, чем важность. Хорошим примером здесь может служить подготовка ответов на сообщения, пришедшие по электронной почте. В e-mail легко потонуть как в отвлекающем моменте, поскольку красные точки говорят: пришли новые сообщения, срочно нужно обозначить их получение. А на самом деле как часто электронные сообщения бывают по-настоящему срочными? Электронная почта — пожалуй, самый плохой способ передачи срочных, чувствительных ко времени посланий. Может быть, это сообщение и выглядит как срочное, но по существу таким не является. Именно поэтому нам рекомендуют выделять для прочтения и подготовки ответов на электронные сообщения специальное время в течение дня. Мы также склонны подменять категорию заметное на категорию срочное в определении подлинной важности сообщений. Если какое-то совещание внесено в календарь, то это заметно; вы должны бы присутствовать на нем. Но на самом ли деле это совещание срочное или вы используете его просто как предлог, чтобы не задумываться о более рациональном использовании времени?

Есть много вещей, кажущихся срочными, но только кажущихся. Новости, Facebook, Twitter. Срочным может показаться чат, но чат настолько же плох для передачи действительно срочной и важной информации, как и e-mail, особенно в случае связанной команды. Сегодня на рабочих местах мы сместили значительный объем обмена информацией с e-mail на чаты типа Slack или HipChat. У этого есть и преимущества, и слабости. Однако важно заметить, что переместить общение в другие программы не значит прекратить общение. Слова и информация продолжают течь, просто поток уходит в другое пространство. А постоянство потока информации в чате может вас отвлекать еще больше, чем раньше.

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

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

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

Теперь вернемся к вещам важным, но не срочным. Среди них — обдумывание будущего и перспектив команд. Несомненно, в этом списке есть и то, что вы должны сделать, но пока отложили в сторону. Возможно, это составление функциональных обязанностей для новых работников. Возможно, это вообще составление перспективного кадрового плана. Это может быть проведение анализа текущей работы по проекту, с тем чтобы не допустить появления в нем заметных проблем. Или беседа с менеджером другой команды: у вас возник конфликт или разногласия относительно того, как двигаться вперед на общей согласованной базе. Или список важных дел — руки пока не дошли, но вы знаете, что должны ими заняться. Если вы и дальше станете их откладывать, то они могут всплыть в негативном контексте. Как менеджер нескольких команд вы несете ответственность за широту и глубину стоящих перед коллективами вопросов и за детальное знание сегодняшней ситуации. Однако в то же время вы должны постоянно смотреть в будущее и определять движение коллективов.

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

Самый трудный и короткий урок менеджеру

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

Возможно, вы в какой-то момент оцените реальное состояние дел и скажете подчиненным: «Близится срок закрытия проекта, и на следующий месяц нам нужен еще один инженер-программист. Этим инженером буду я».

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

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

Я всегда испытываю дискомфорт, когда меня постигает неудача как инженера. Однако от моей неудачи как менеджера страдают-то в основном другие люди. Это несправедливо.

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

Кейт Хьюстон

Принять решение и делегировать

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

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

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

Точнейшая аналогия чувств, овладевающих тем, кто начал управлять несколькими командами, — это жонглирование. Знаете, есть такой фокус у жонглеров — крутящиеся тарелки. Человек держит в руках несколько палок, на верхнем острие которых вращается сразу несколько тарелок. Жонглер должен внимательно следить за вращением каждой и направлять его, чтобы оно не замедлилось и тарелка не упала. В вашем случае такие тарелки — люди и проекты. Ими вы управляете. Вам нужно правильно и точно определять объем вашего внимания, отданного в каждую данную минуту. Важно, чтобы вы оценивали вращение тарелок свежим взглядом ученика. В процессе управления тарелками вы продолжаете учиться этому искусству, и некоторые могут упасть, поскольку вы упустили их из внимания. Выработка инстинктивного знания, когда и какую тарелку нужно подкрутить, и есть ваша игра.

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

Я назвала этот раздел «Принять решение и делегировать». Как же определить делегирование? Делегирование, или перепоручение обязанностей — один из первых путей освободиться от ощущения, что вам приходится в каждое мгновение контролировать вращение слишком большого числа тарелок. По мере того как на вас наваливаются все новые задачи, спросите себя: должен ли я один выполнять всю работу? Ответ может зависеть от ряда факторов (см. таблицу 6.2).

Таблица 6.2. Принятие решения о перепоручении своих обязанностей или самостоятельном их выполнении

Обязанности

Регулярные

Нерегулярные

Простые

Делегировать

Выполнять самому

Сложные

Делегировать (с осторожностью)

Делегировать в целях обучения подчиненных

Степень сложности и частотности задач может служить указанием, следует ли делегировать их подчиненным и как это делать.

Перепоручайте подчиненным простые и часто встречающиеся задачи

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

Простые и нечастые задачи берите на себя

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

Используйте сложные и нечасто встречающиеся задачи для обучения будущих лидеров

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

Перепоручайте сложные и часто встречающиеся задачи в целях развития команды

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

Учатся ли ваши команды работать независимо или в важнейших областях работы вы держите их в зависимости от вас? Составьте список задач, решаемых для команды только вами. Некоторые действительно ваши — как написать заключение по работе или составление кадровых планов. Но многие важны, поскольку могут научить вашу команду самостоятельно добиваться необходимых результатов. Управление проектами. Обеспечение вхождения в работу новых сотрудников. Взаимодействие с командой продукта для разбивки задач по производству продукта на отдельные программные составляющие. Поддержка готовой продукции. Все эти навыки должны осваивать члены вашей команды. Обучение их может потребовать времени, но в перспективе это сэкономит время вам. Обучение команды всему вышеперечисленному — часть вашей работы. Как менеджер вы несете ответственность за воспитание в организации способных кадров и за то, чтобы помочь работникам освоить новые знания, нужные на последующих ступенях служебной карьеры.

Делегирование обязанностей — процесс небыстрый, но очень важный и для вашего карьерного роста. Если ваши команды не могут работать без опеки, то вам будет трудно получить повышение в должности. Находите способных людей и делегируйте им обязанности и задачи, находя таким образом новые и интересные «тарелки», чтобы их раскрутить.

Спросите технического директора: предупреждающие признаки

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

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

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

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

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

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

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

Недостаток вовлеченности в совещания означает, что команда не заинтересована в работе или ощущает недостаток прав в принятии решений.

Список приоритетов проекта начинает меняться каждую неделю в зависимости от прихотей клиента. Они возникают каждый день.

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

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

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

Трудные ситуации: уметь сказать «нет»

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

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

«Да, но…»

«Нет» руководителю — не совсем обычное «нет». Скорее оно выглядит как некое импровизированное «да, но…». «Да, мы могли бы взяться за этот проект, но для этого нам нужно всего лишь отложить начало другого проекта, а он сейчас в наших планах». В целом позитивный ответ, сопровождающийся обозначением границ реальности, выведет вас в высшую лигу искусства руководить. Такая разновидность позитивного «нет» — сложное искусство, оно трудно дается большинству инженеров. Нам обычно легче перечислить недостатки проекта. Умение преодолеть привычку говорить «нет, невозможно» дается с трудом. Постарайтесь освоить прием «да, но…», чтобы сказать «нет», особенно в отношениях с руководителями и коллегами. И убедитесь, что этот прием часто превращает тяжелые разногласия в реалистичные поиски приоритетов.

Умейте твердо стоять на своем

Во взаимоотношениях с командой вам нужно научиться четко показывать, чего стоит ответ «да». Например, вы имеете дело с программистом, желающим перейти в данном проекте на новый язык программирования. Но ваша команда до сих пор его не использовала. У инженера могут быть замечательные аргументы, почему данный язык — отличный инструмент для написания программы. Но вы не хотите задействовать его как раз потому, что он слишком совершенный. У вас есть соблазн просто сказать «нет», привести аргументы и отставить вопрос в сторону. Иногда такая тактика срабатывает. Но будет лучше, если вы найдете в себе силы говорить «нет» снова и снова, приводя объяснения. «Нет, потому что нам нужно больше людей, знающих этот язык; нет, потому что мы должны четко представлять себе, как задействовать этот язык в процессе производства». «Нет, нам нужны будут новые стандарты для записи данных; нам нужно подумать о новой методике проверки кода». Начиная повторять аргументы, вы убеждаете окружающих в правомерности своего подхода: для «да» необходимо выполнить очень сложные требования. Кроме того, такой подход дает основания для решения. Формирование такого подхода поможет команде заблаговременно понять настоящую цену ответа «да».

Помогите мне сказать «да»

Описанный выше подход, конечно, весьма полезен, но он не может работать в каждом случае. Следующий прием — «помогите мне сказать “да”» — в чем-то перекликается с предыдущим. Однако он лучше действует там, где вы еще не успели соответствующим образом подготовиться. Иногда вы можете столкнуться со слабо проработанными идеями. «Помогите мне сказать “да”» означает, что по данной идее у вас есть вопросы и вы стремитесь докопаться до сомнительных элементов. Очень часто такой подход сам по себе подводит людей к пониманию, что их план не очень хорошая идея. Но иногда ход их мысли может оказаться для вас приятным сюрпризом. В любом случае тщательный опрос может помочь вам сказать «нет» и в то же время чему-то научить подчиненных.

Опирайтесь на бюджет

И для команды и для коллег вы можете использовать этот аргумент — бюджет и сроки. Простыми словами объясните текущий объем работы и покажите, что для дополнительного маневра возможностей очень мало. Иногда такие соображения полезно дополнить тезисом «во всяком случае, не сейчас» — еще одним не агрессивным, но наступательным способом сказать «нет». «Во всяком случае, не сейчас» обозначает, что вы можете согласиться с данной идеей, но не в текущий момент. Поэтому ее следует отложить на будущее. Зачастую так и происходит, так что вернуться к планам типа «во всяком случае, не сейчас» легко. Но, как я отмечала ранее, когда вы даете скрытое обещание «во всяком случае, не сейчас», это означает, что вы всерьез готовы предпринять что-то «позже». И вы должны быть готовы, что «позже» когда-нибудь наступит.

Работайте командой

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

Не затягивайте с отказом

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

Спросите технического директора: мой технический руководитель группы не занимается управлением

У меня есть технический руководитель группы. Он должен был проконтролировать, как один из младших программистов портирует приложение из компилируемого языка Objective-C на открытый язык программирования общего назначения Swift. Я только что выяснил: младший инженер еще даже не составил план проекта и не ответил ни на одно мое замечание относительно дизайна. Как мне заставить технического руководителя разобраться, чтобы мне не пришлось вмешиваться?

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

Ответ, скорее всего, будет комбинацией нескольких моментов. Первое: технический руководитель занят собственной работой и забыл о необходимости проконтролировать младшего инженера. Такое случается. Но вы все же должны напомнить ему, что руководство и контроль над младшим инженером должны быть правильно увязаны с его работой с кодом и другими обязательствами.

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

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

Инженерная составляющая за пределами кода

Менеджмент на уровне нескольких команд иногда становится весьма запутанным. Компании ведь нанимают менеджеров частично потому, что у них есть инженерная подготовка и знания. Но многие думают, что серьезный менеджмент — это уже не инженерия. В конце концов, серьезный менеджер ведь не участвует активно в написании кода и не занимается дизайном систем, верно?

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

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

Знаю ли я, чего ждут от меня на работе?

Достаточно ли у меня материалов и оборудования, чтобы успешно выполнять свою работу?

Имеется ли у меня возможность каждый день заниматься тем, что получается у меня лучше всего?

Для большинства инженеров-программистов ответ на эти вопросы — скорость написания кода данной командой. Если им ясно, чего от них ждут, они знают, какой код писать. Если в их распоряжении соответствующие элементы инструментального обеспечения, процессы и средства автоматизации, простые в использовании, они способны довести написание кода до логического конца. А если их не отвлекать излишними совещаниями или работой по поддержке программ и устранению сбоев, то у них возникнет шанс писать код каждый день. Эти здоровые признаки — большая частота релизов кода и проверок, выдерживаемая кодом, и малая частотность сбоев — ключевые отличительные характеристики команд, знающих, что им надо делать, имеющих программно-аппаратный инструментарий и занятых своим делом каждый день.

Измерители здоровья вашей команды

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

Частота релизов

В главе 5 я отмечала, что в наше время распространенным недостатком в работе команд программистов является невыпуск кода и что прямой инструмент измерения этого состояния — частота релизов. Я сочувствую вам, если ваша компания не понимает важность частых релизов кода. В современном мире частота изменений кода — один из важнейших индикаторов трудоспособности команды разработчиков. Хорошие менеджеры-инженеры в командах, сосредоточенных на создании продукта, знают, как формировать условия, благоприятные для быстрого продвижения работы вперед. Одна из мер — умение правильно разбить работу на небольшие куски. Даже если в вашей компании не понимают ценности релизов, вы должны помогать команде достигать как можно более высокой частотности для конкретного продукта. Даже если вы считаете, что это не относится к вам, потому что вы заняты разработкой продукта (например, базы данных), не предполагающего частых релизов, я уверена: имеет смысл продвигать почти готовую версию продукта в бета-тестирование. Оно может стать важным инструментом измерения с точки зрения соотношения частотности релизов и стабильности программы.

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

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

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

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

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

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

Частота проверок кода

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

Я заостряю ваше внимание на этой теме потому, что новому менеджеру зачастую бывает трудно сказать людям, писавшим код столько же, сколько он, если не больше, что их методы работы требуют улучшения. Стремление избежать конфликтов живет глубоко в каждом из нас, и затрагивать кого-то лично бывает очень трудно. Если ваша компания стремится к быстрой разработке программных продуктов, то разрешать инженерам-программистам уходить в себя на недели и писать код в одиночку, не допуская общего контроля над созданной версией, — значит тормозить работу всей команды и порождать проблемы. Ведь вы управляете не командой ученых и исследователей. (Или все же управляете? Тогда пропустите этот раздел.) Для вас должно быть нормально ожидать, что продвигающаяся вперед работа регулярно обновляется.

Частотность сбоев

Насколько надежно и стабильно программное обеспечение, выпускаемое командой? Происходит ли улучшение или ухудшение качества либо оно остается на том же уровне, что и раньше? Определение того, обладает ли продукт вашей команды нужным качеством, и постоянное подтверждение — инженерная задача, и вы как менеджер обязаны решать ее. Если вы создаете совершенно новый продукт для небольшой растущей компании, тогда имеет смысл сосредоточиться больше на свойствах и функциях, чем на надежности. Напротив, если вы имеете дело с важными системами, определяющими жизнеспособность всей продукции, то здесь важнее всего надежность и минимизация количества сбоев. Цель в том, чтобы сбалансировать риски: тогда ни частота сбоев, ни их предотвращение не станут для разработчиков работой, на несколько дней отрывающей от написания кода.

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

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

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

Хороший менеджер, плохой менеджер: «мы против них». Командный игрок

Диана только что получила работу в небольшом стартапе. Ей предложили возглавить команду по разработке мобильных приложений, до которой никому не было дела. С самого начала ей сказали, что в команде бардак, так что Диана первым делом привлекла людей, работавших с ней в большой известной IT-компании. Их предыдущий опыт не совсем подходил текущей корпоративной культуре, так что в команде скоро возникла группировка разработчиков, или команда внутри команды, ставившая себя выше остальных сотрудников в организации. Хотя программная составляющая продуктов и улучшилась, эта группировка вступила в конфликт с командой продукта. В результате выпуск приложений резко замедлился. Через год Диана устала и ушла. За ней последовали члены прошлой команды, оставив предприятие на том же уровне.

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

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

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

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

В «группировке» отсутствует гибкость. «Группировки» обычно упорно сопротивляются любым изменениям, предложенным извне. Реорганизации, остановленные проекты и изменение приоритетов могут привести к распаду «команды внутри команды». Такое поведение может исходить от функциональных подразделений и быть направленным против других команд общего, межфункционального профиля (например, стремление замедлить разработку очередного приложения к iPad или сопротивление постановке нового продукта в приоритеты). Вводимое изменение может разрушить и без того хрупкие связи, привязывающие команду к компании.

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

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