Читать онлайн От разработчика до руководителя бесплатно

Эту книгу хорошо дополняют:

45 татуировок менеджера

Максим Батырев (Комбат)

Scrum. Революционный метод управления проектами

Джефф Сазерленд

Быть начальником — это нормально

Брюс Тулган

Deadline

Том ДеМарко

Коучинг agile-команд

Лисса Адкинс

The Manager’s Path

A Guide for Tech Leaders Navigating Growth and Change

Camille Fournier

От разработчика до руководителя

Менеджмент для IT-специалистов

Камиль Фурнье

Москва

«Манн, Иванов и Фербер»

2018

Информация

от издательства

Научный редактор Станислав Ломакин

Издано с разрешения O’Reilly Media, Inc.

На русском языке публикуется впервые

Фурнье, Камиль

От разработчика до руководителя. Менеджмент для IT-специалистов / Камиль Фурнье ; пер. с англ. М. Попова [науч. ред. С. Ломакин]. — М. : Манн, Иванов и Фербер, 2018.

ISBN 978-5-00117-319-9

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

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

Посвящается С. К.

Введение

В 2011 году я пришла в стартап под названием Rent the Runway1. Для меня это было радикальное решение — покинуть работу в дистрибуции в крупной компании ради того, чтобы присоединиться к небольшой команде инженеров, поставивших перед собой цель в максимальной степени удовлетворять запросы клиентов. Я пошла на это, потому что считала, что у них отличный бизнес, а кроме того, мне хотелось руководить. Я верила, что, напряженно работая и имея толику везения, смогу получить необходимый опыт руководства людьми.

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

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

Покинув компанию, я обнаружила, что просто лопаюсь от обилия появившихся советов. Мне хотелось также чего-то творческого, поэтому я решила попробовать поучаствовать в программе «Общенациональный месяц написания романов». Она ставит перед участником сложную задачу — написать 50 000 слов за 30 дней. Я попыталась описать все, чему я научилась за прошедшие четыре года, все, что я лично испытала, и положить на бумагу некоторые свои наблюдения, касающиеся успехов и неудач других людей. Этот проект превратился в книгу. Ее вы сейчас и читаете.

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

По моему опыту, самая главная трудность инженерно-технического менеджмента состоит в пересечении инженерии и менеджмента. Работа с людьми — сложный вопрос, и я не хочу говорить о нем вкратце. Однако управленческие навыки менеджера реализуются в условиях производства и конкретной работы каждого сотрудника. Если вы интересуетесь исключительно вопросами руководства людьми, то книги типа «Сначала сломайте все правила» (First, Break All the Rules)2 станут вам отличными помощниками.

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

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

Как читать эту книгу

Книга разделена на главы. В них рассказывается о менеджменте по мере увеличения сложности. Первая глава описывает основы того, что значит быть объектом менеджмента и чего следует ожидать от менеджера. Глава 2 и глава 3 посвящены вопросам наставничества и исполнения обязанностей технического руководителя группы, которые представляют собой два важных этапа в становлении человека как менеджера. Для опытных менеджеров обе главы могут быть полезны с точки зрения работы с людьми, играющими эти роли. В главе 4, главе 5, главе 6 и главе 7 разговор ведется об управлении людьми, командами, группами команд и самими менеджерами. Последняя, восьмая глава посвящена высшему руководству организацией.

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

В каждой главе книги представлены три сквозные рубрики.

Спросите технического директора

Короткие вставки. В них рассматриваются конкретные вопросы, возникающие на разных этапах становления менеджера.

Хороший менеджер, плохой менеджер

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

Сложные ситуации

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

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

Я хотела написать эту книгу не просто в качестве просветительской работы по вопросам лидерства для общей аудитории. Мне хотелось, чтобы из нее получилось что-то стоящее знака программы O’Reilly, что-то, к чему вы сможете время от времени возвращаться примерно так же, как вы обращаетесь к Programming Perl («Программирование на Perl»)3. Так что относитесь к этой книге как к своего рода руководству-справочнику по вопросам IT-менеджмента: я поместила в ней практические советы, способные, надеюсь, приносить пользу на протяжении всей вашей карьеры менеджера.

Основы менеджмента

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

Кейси Стенгел

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

Чего ожидать от менеджера

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

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

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

Чтобы ваша команда нормально продвигалась вперед, менеджер должен правильно выполнять несколько задач, и вы вправе ожидать этого от него. Поняв, чего можно ожидать от менеджера, стоит начать предъявлять требования.

Личные встречи

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

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

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

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

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

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

Обратная связь и помощь в работе

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

И все же вы должны быть заинтересованы в ней: хуже замечаний только их полное отсутствие или появление в уже готовом заключении по вашей работе. Чем скорее вы узнаете об изъянах в своих действиях и поведении, тем легче их исправить. То же самое относится и к похвале. Хороший менеджер всегда заметит даже небольшую положительную деталь в вашей повседневной работе и отметит ее. Запоминайте содержание обратной связи, позитивных и негативных замечаний, чтобы использовать в собственном годовом отчете.

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

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

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

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

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

Повышение уровня подготовки и карьерный рост

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

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

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

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

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

Спросите технического директора: слишком большие амбиции

Я только что начал работать, но уже понял, что цель моего карьерного роста — когда-нибудь стать техническим директором. Что мне нужно делать сейчас, чтобы этой цели достичь?

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

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

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

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

Когда вами управляют

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

Не жалейте времени на раздумья: чего же вы хотите?

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

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

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

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

За себя отвечаете вы

Познание себя — первый шаг. Движение к тому, чего вы для себя хотите, — шаг второй.

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

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

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

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

Дайте менеджеру передохнуть

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

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

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

Мудро выбирайте

Менеджер может оказать большое влияние на вашу карьеру. Рассматривая варианты, куда пойти работать, обращайте внимание не только на должность, характеристику компании и заработную плату, но и на данные о менеджере: с ним вам придется работать.

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

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

Оценка вашего опыта

Вот несколько вопросов для размышления на этом этапе вашей карьеры.

Был ли у вас когда-либо хороший менеджер? Что он делал ценного?

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

Можете ли вы рассказать менеджеру о каком-то важном событии в вашей личной жизни? Ощущаете ли, что менеджер знает что-то о вашей личной жизни?

Давал ли когда-либо ваш менеджер хорошие советы или рекомендации? А плохие? Вообще никогда не давал никаких рекомендаций?

Помог ли вам менеджер определить какие-либо рабочие цели на текущий год?

Менторинг (наставничество)

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

Важность менторинга (наставничества) в отношении младших членов команды

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

Я помню первого наставника. Он и привил мне вкус к работе программиста. Я была стажером в компании Sun Mycrosystems, в группе, работавшей с JVM4. Это была первая позиция, на которой я разрабатывала реальное программное обеспечение, и мне повезло, что моим наставником был отличный учитель и прекрасный программист Кевин. Он мне запомнился, потому что, занимая серьезную руководящую инженерную должность в нашем подразделении, уделял мне много времени. Вместо того чтобы показать мне мое рабочее место и оставить меня соображать, что вообще я должна делать, Кевин не жалел времени на обсуждение конкретных проектов, помощь с размышлениями у доски и с написанием кода. Я знала, чего от меня ждут, а когда сталкивалась с трудностями, то всегда могла обратиться к Кевину за помощью. То лето стало очень важным для моего профессионального роста как программиста, потому что под руководством Кевина я начала понимать, что могу выполнять реальную работу и быть продуктивным сотрудником. Работа с Кевином стала одной из заметных вех в моей рабочей биографии. Этот опыт научил меня ценить важность наставничества.

Быть наставником

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

Наставничество над стажерами

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

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

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

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

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

Внимательно слушайте

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

Один из первых уроков лидерства, осуществляемого через прямое управление людьми или через опосредованное влияние, таков: обычно люди не умеют высказывать свои мысли так, чтобы другие точно их понимали. У нас нет коллективного разума, как у Борга из «Звездного пути», или телепатического общения, как у вулканцев из того же сериала. Мы постоянно пропихиваем сложные мысли, словно верблюдов через игольное ушко языка. А языком-то как раз большинство инженеров-программистов не владеет в совершенстве. Поэтому умение слышать выходит за рамки простого восприятия органами слуха. Находясь лицом к лицу с собеседником, вы должны распознавать и язык его тела, и тот тон, каким он произносит слова. Он улыбается? Хмурится? Вздыхает? Эти маленькие сигналы подскажут, чувствует он себя понятым или нет.

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

Ясно доводите свои мысли до собеседника

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

Четко соразмеряйте свою реакцию

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

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

Спросите технического директора: обучение летнего стажера

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

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

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

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

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

Наставничество над новым сотрудником

Сразу после колледжа я пошла работать в очень крупную технологическую компанию. Назовем ее «Большая технокомпания» (Big-TechCo). Я попала в команду, которая уже несколько лет работала над проектом. Мой менеджер показал мне место в офисе и оставил наедине с собой, чтобы я сама придумала, что делать. Я не знала, как попросить помощи, и думала, что все будут считать меня глупой, если я попрошу. Неудивительно, что я была разочарована и подумала, что лучше пойти в аспирантуру. Так я и сделала.

Я полагала, что вторая работа по окончании аспирантуры будет мало отличаться от первой. Однако, вместо того чтобы быть препровожденной к рабочему столу и предоставленной самой себе, я получила наставника. Он попросил меня не стесняться задавать вопросы. Сначала мы занялись парным программированием, чтобы я изучила кодовую базу и тестирование (так я впервые ощутила вкус к тестированию!). Через несколько дней я уже выдавала продукцию самостоятельно. За несколько месяцев на новой работе я научилась намного большему, чем за весь период работы в Big-TechCo. Почти целиком это произошло благодаря полученному на новом месте наставничеству.

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

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

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

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

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

Техническое или профессиональное наставничество

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

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

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

Когда вы наставник

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

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

Когда вы подопечный

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

Хороший менеджер, плохой менеджер: звезда компании

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

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

Такие звезды, даже пугающие молодых, могут стать воодушевляющим примером для них. У звезды на все есть ответы. Этот инженер работал над первоначальной версией данной системы 10 лет назад и до сих пор помнит всех авторов. Если вам нужно в чем-то разобраться, то нет проблем. Звезда точно знает, почему какая-то ваша разработка не действует, а когда это произойдет, то, поверьте, он напомнит вам о своем предупреждении. Вам нужно было послушать его и сделать так, как он говорил! Технические звезды могут многому научить, если захотят, и придумать отличные системы: для вас станет радостью помогать строить их. В целом звезды, конечно, не продвинулись бы так далеко, если бы не были талантливы, и многому могут научить свои команды, потому-то многие ценят их ум и мирятся с их недостатками.

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

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

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

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

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

Рекомендации менеджеру наставника

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

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

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

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

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

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

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

Спросите технического директора: принимаем на работу стажеров

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

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

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

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

Ключевые моменты для наставника

В качестве наставника вам следует обратить особое внимание на три аспекта своих действий.

Будьте любознательны и открыты новому

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

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

Слушайте их, говорите на их языке

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

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

Устанавливайте личные связи

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

Обратимся к оценке вашего собственного опыта

Ниже следует несколько вопросов для размышления на этом этапе вашей карьеры.

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

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

Был ли у вас когда-нибудь хороший наставник? Что он сделал для того, чтобы вы считали его таковым? Как ваш наставник помогал вам учиться — чему он учил?

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

Технический руководитель группы

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

Я была свидетелем многих неудач технических руководителей групп. Один такой случай, особенно запавший мне в память, произошел с прекрасным программистом. Он блестяще писал код, но ненавидел говорить с людьми и часто раздражался из-за технических деталей. Я молча наблюдала, как он попадал из западни в западню. В его отсутствие менеджер продукта уговорил остальных членов команды «выдать» продукт, плохо разработанный и чрезвычайно амбициозный. Проект катился в пропасть, и что же сделал технический руководитель? Он взялся за рефакторинг5, потому что был уверен: вся проблема в неправильной структуре кода. Наверное, эта ситуация вам знакома, ведь такое случается везде. Мысль, что роль технического руководителя группы должна быть автоматически возложена на наиболее опытного инженера-программиста, способного разобраться с самыми сложными вещами или написать лучший код, — общее заблуждение, в эту ловушку попадаются даже лучшие менеджеры. Должность технического руководителя группы предназначена не для того, кто нуждается в максимальной свободе для сосредоточения на деталях собственного кода. Такой технический руководитель не выполняет своей работы. Тогда в чем же на самом деле состоит работа технического руководителя группы? Чего мы ожидаем от него?

Как и в случае многих должностей в области разработки и производства программного обеспечения, понятие «технический руководитель группы» не имеет общепризнанного определения. Лучшее, что я могу в этом плане сделать, — это опираться на собственный опыт и опыт других людей. Моя работа в качестве технического руководителя группы состояла в том, что я продолжала писать код, но у меня появились и другие обязанности: представлять интересы группы перед руководством, рассматривать наши планы по новым продуктам, а также выполнять то, что характерно для процесса управления проектами. Я смогла быть техническим руководителем, не будучи самой старшей по должности, потому что оказалась способна брать на себя обязанности, связанные с этой работой, тогда как остальные члены моей команды были больше сконцентрированы на создаваемых программах. Когда моя группа в компании Rent the Runway создавала должностное расписание для инженеров-программистов, мы сознательно определили роль технического руководителя определенным набором параметров. Под них мог подойти любой программист на любой ступеньке карьерной лестницы. Мы заняли такую позицию потому, что хотели подчеркнуть: по мере развития и изменения команд роль технического руководителя может исполняться программистами, находящимися на разных этапах карьерного роста, или передаваться от одного инженера другому без обязательного изменения функционального положения. В разных компаниях функции технических руководителей групп бывают разными; они могут отличаться от группы к группе даже в рамках одной организации. Однако само название должности подразумевает: в ней соединяются технические и руководящие обязанности, и часто они носят временный, а не постоянный характер. Итак, с учетом сказанного: что же это все-таки такое — технический руководитель группы? Ниже приводится описание этой должности, созданное нами в Rent the Runway.

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

регулярные (еженедельные) встречи руководителя с членами группы;

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

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

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

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

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

Возможно, самое краткое выражение сущности роли технического руководителя группы содержится в книге Патрика Куа «Разговор с техническими руководителями» (Talking with Tech Leads).

Руководитель, отвечающий за работу команды программистов, проводит по крайней мере 30% времени в написании кода вместе со своей группой.

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

Если вы оказались в роли технического руководителя группы, то примите мои поздравления! Некоторые думают, что вы обладаете качествами, чтобы быть лидером в команде. Теперь ваша очередь учиться новому!

Что значит быть техническим руководителем

Исполнение обязанностей технического руководителя — упражнение на влияние на людей без реальной власти. Я руковожу коллективом в качестве ведущего технического специалиста, но мы все отчитываемся перед одним и тем же менеджером. Поэтому я должна влиять не только на коллег, но еще и на менеджера по вопросам правильного определения приоритетов в работе. Поначалу мне пришлось совсем туго, потому что один из первых порученных мне проектов формулировался так: остановить разработку новых программ и вместо этого сосредоточиться на проблеме «технического долга»6. Мне стало ясно, что «консервную банку» под названием «технический долг» гоняли по полю уже достаточно долго: развертывание нового кода давалось с трудом, использование действующих систем становилось все более дорогим, а техподдержка в режиме «по первому зову» 24/7 была адски трудна. Я была уверена, что нам нужно притормозить, чтобы в будущем нагнать темп. Однако в этом было трудно убедить наших разработчиков: они хотели создавать новые интересные программы. Или менеджера: его захлестывал постоянный поток запросов от заказчиков. Мне удалось привлечь членов команды на свою сторону, показав, какие позитивные моменты каждый сможет получить от проекта. Для некоторых было важно иметь более надежный сервис, для других — повысить скорость итерации, а для третьих — уменьшить количество срочных запросов в техподдержку, что дало бы им возможность спокойно спать. В беседах с менеджером особый упор я делала на снижение эксплуатационных издержек, что позволило бы команде в будущем разрабатывать более интересные программы.

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

Кейти Маккафри

Все хорошие технические руководители знают одну хитрость

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

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

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

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

Основные моменты позиции технического руководителя группы

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

Главные функции технического руководителя

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

Архитектор системы и бизнес-аналитик

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

Планировщик проекта

Планировщик должен уметь делить проект на приблизительно равные промежуточные части. Исполняя эту роль, вы должны учиться находить эффективные пути разбивки, чтобы команда работала быстро. Часть задачи — организовать параллельное движение частей работы в максимальном объеме и максимально продуктивно. Это сложно, потому что вы, скорее всего, привыкли думать только о своей работе, а не о работе группы. Ключ — найти пункт приложения всего согласованного в теории. Например, если речь идет о внешнем интерфейсе, использующем простой формат обмена данными JSON на базе API (интерфейса прикладного программирования), то не обязательно ждать, пока набор процедур API будет полностью закончен, чтобы начать разработку внешнего интерфейса. Вместо этого согласуйте использование формата JSON и начинайте писать код в этом формате при помощи Mock-объектов (фиктивных функций). Если вы удачливы, то наверняка видели это раньше, так что вам просто надо копировать предыдущие образцы. На этой стадии вам следует привлечь опытных экспертов к консультированию членов вашей группы и самому поговорить со специалистами, разбирающимися в соответствующих проблемах и способными сообщить вам необходимые детали. Также в этой части процесса нужно осуществить расстановку приоритетов. Что в программе действительно важно, а что факультативно? Как работать над важными элементами с самого начала проекта?

Разработчик программ и руководитель группы (тим-лидер)

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

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

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

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

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

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

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

Управление проектами

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

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

Это была одна из самых тяжелых ситуаций в моей жизни.

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

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

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

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

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

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

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

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

Не жалейте времени на разъяснения

Один из последних этапов на пути к докторской степени — защита диссертации. Именно здесь вы, кандидат в доктора, представляете результаты своей многолетней исследовательской работы. Вы делаете это перед научным советом, состоящим из экспертов в вашей области. Они оценят ваши результаты и решат, достаточны ли они для присуждения вам научной степени доктора наук (PhD). Много лет назад мне повезло: я получил докторскую степень по математике от одной из самых престижных программ по прикладной математике в США. Одним из членов научного совета, оценивавшим мою работу, был известный математик — специалист в области численного анализа. То, что он сказал мне после моей (успешной) защиты, прошло красной нитью сквозь всю мою рабочую карьеру (не в области математики!). Он сказал тогда: «Ваша диссертация была одной из самых прозрачных и ясных работ, прочитанных мною за многие годы. Благодарю вас!» Разумеется, я был польщен его словами, но одновременно с этим и удивлен. Я предполагал, что этот ученый, математик мирового уровня, будет все знать о моем предмете и просто наблюдать, чем обернется защита моей диссертации. На самом деле, как объяснил он, он действительно смог это сделать, но только благодаря тому, что я потрудился объяснить базовые понятия и мотивацию возникновения моих собственных идей. Я никогда не забывал этот урок. Проработав после этого в области создания программного обеспечения в больших организациях, я не раз смог оценить его слова.

Мы полагаем, что руководство легко схватывает то, что мы делаем как инженеры-программисты. «Эй, парень, ты просто читай код!» Среди программ мы живем каждый день, и ведь они должны быть понятны любому, кто работает в области IT, не так ли? Нет, не так. Технические менеджеры приглашают на работу лучших специалистов (во всяком случае, надеются, что они лучшие), и те решают сложные проблемы. Но менеджеры схватывают далеко не всё. Я всегда удивлялась, насколько благодарны были мне старшие технические руководители, когда я мог объяснить им некоторые основополагающие идеи (например, что собой представляет штуковина под названием «хранилища NoSQL» и что с этим делать) не в угрожающем или снисходительном тоне.

Недавно один старший бизнес-руководитель в нашей организации попросил меня объяснить ему в частном порядке, почему для нас важно перенести «Толстого клиента»7 в архитектуре клиент-сервер на платформы провайдера. На этого руководителя сильно давили, чтобы он разрешил финансирование перехода, но он не понимал, зачем это нужно. Судя по всему, ему было неудобно спрашивать об этом публично. Я провел два очень плодотворных часа, объясняя ему (без PowerPoint!) суть проблемы. Теперь я никогда не боюсь разъяснять базовые принципы и мотивации тех или иных решений и старшим, и младшим сотрудникам организации. Это дает им знания, не принижая их, они учатся доверять моим суждениям и советам, и так мы обеспечиваем в организации необходимые изменения. Не жалеть времени на объяснения — это очень важно.

Майкл Маршалл

Управление проектом

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

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

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

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

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

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

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

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

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

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

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

Точка принятия решения: остаться инженером или стать менеджером

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

Воображаемая жизнь ведущего инженера-программиста

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

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

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

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

Реальная жизнь ведущего инженера-программиста

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

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

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

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

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

Воображаемая жизнь менеджера

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

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

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

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

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

Реальная жизнь менеджера

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

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

Вы устанавливаете нормы корпоративной культуры в коллективе. Это и хорошо, и плохо. Хорошо, когда ваша команда следует тому лучшему, что есть в вас. Но плохо, когда вы понимаете, что ваша команда зеркально повторяет ваши ошибки.

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

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

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

Хороший менеджер, плохой менеджер: «царь организационного процесса»

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

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

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

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

Антипод «царя» — не менеджер, полностью отставляющий в сторону все процедуры, а менеджер, понимающий: организационные процессы должны отвечать потребностям команды и ее работы. Как это ни смешно, но хотя agile-методы обычно претворяют в жизнь довольно жесткими способами, принципы Agile Manifesto — квинтэссенция здоровых моделей управления.

Интересы отдельных работников и их взаимодействия должны стоять над интересами «процессов и методик».

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

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

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

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

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

Как быть хорошим техническим руководителем

Хорошему техническому руководителю нужны разные качества, но вот главные.

Поймите архитектуру системы

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

Будьте командным игроком

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

Руководите группой технических решений

Как технический руководитель вы будете вовлечены в основные технические решения в вашей группе. Быть вовлеченным, однако, не означает, что вы будете решать все за всех. Если вы не будете советоваться с командой, сотрудники могут обидеться и обвинить вас, когда дела пойдут плохо. С другой стороны, если вы начнете уклоняться от технических решений и перекладывать все на команду, то возможные быстрые решения окажутся отложены на неопределенное время.

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

Правильно общайтесь с командой на понятном ей языке

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

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

Обратимся к оценке вашего собственного опыта

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

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

Спрашивали ли вы менеджера, чего он ожидает от технического руководителя?

Можете ли вы назвать лучшего технического руководителя из всех, с кем довелось работать? Какие качества делали его хорошим техническим руководителем?

Приходилось ли вам когда-либо работать с неудачным техническим руководителем? Какие его качества вам не нравились?

Управление людьми

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

Марк Хедлунд

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

Сначала давайте сосредоточимся на управлении отдельными людьми. Есть много книг, способных вооружить вас огромным числом идей; моя задача в том, чтобы познакомить вас с основами менеджмента, как я их вижу. Раз уж теперь вы менеджер на горячей сковородке, как должны вы представлять себе основные задачи в управлении людьми?

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

Поговорим о главных задачах, решающих в организации управления людьми:

получение от подчиненных свежих отчетов;

проведение регулярных личных встреч;

предоставление им оценок и рекомендаций по вопросам карьерного роста, продвижения к поставленным целям, сфер для самосовершенствования, а также заслуженной похвалы;

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

С самого начала выстраивайте отношения с членами команды как с подчиненными

Первое, что случается, когда вы начинаете управлять людьми, — вы начинаете относиться к ним как к подчиненным. Это могут быть ваши коллеги или совершенно незнакомые люди. По мере движения по карьере менеджера вы постоянно будете вступать в контакт с новыми подчиненными. Как быстро узнать сотрудника, чтобы управлять им наилучшим образом?

Выстраивайте с подчиненными отношения доверия и взаимопонимания

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

Какой вид похвалы вы предпочитаете — публичную или неформальную?

Некоторые люди очень не любят, когда их хвалят на публике. Вы должны знать это.

В каком виде вы предпочитаете получать обратную связь? В письменном, чтобы иметь время «переварить» ее, или вам нравятся более неформальные устные оценки и рекомендации?

Почему вы решили работать в компании? Что вам здесь нравится?

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

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

Есть ли не нравящиеся вам моменты в поведении менеджеров?

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

Есть у вас определенные цели в плане служебного роста? Могу ли я помочь их достичь?

Когда вы вошли в команду, что вас удивило (и хорошее, и плохое)?

Моменты типа: а мои опционы? Вы обещали мне бонус после перевода с прежнего места работы, но я еще его не получил. Почему мы используем SVN (свободную централизованную систему управления версиями), а не Git (распределенную систему управления версиями)? Я не ожидал, что уже сейчас достигну такой производительности!

Помогите подчиненным составить план на 30/60/90 дней

Другой метод опытных менеджеров в работе с подчиненными — помощь в составлении планов на 30/60/90 дней. Он может включать в себя такие большие цели, как более быстрое написание кода или устранение ошибок, а также выпуск релиза продукта. Такие планы особенно важны для новых членов команды, переведенных из других подразделений. Чем старше новичок по опыту и должности, тем активнее он должен участвовать в составлении такого плана. Вы должны побудить его поставить перед собой ясные цели, показывающие, что он готов усваивать необходимые навыки для убыстрения работы. Формулирование целей требует определенной работы и от вас, и от команды, потому что очень редко бывает так, что новичку все становится на новом месте ясным, все хорошо задокументировано и вполне очевидно.

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

Побуждайте новичков к подготовке новой документации

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

Четко доводите до новичков ваш стиль руководства и свои ожидания

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

Получайте от нового работника обратную связь

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

Как общаться с командой

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

Марк Хедлунд

Регулярно проводите личные встречи с членами команды

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

Планирование личных встреч

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

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

Корректировка времени личных встреч

Как и многое в нашей жизни, личные встречи не относятся к категории «назначил и забыл». Здесь необходимо принимать во внимание целый ряд факторов.

Как часто вы контактируете с конкретным работником в течение недели?

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

В каком уровне руководства и советов нуждается данный работник?

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

Часто ли и активно делится данный работник информацией с вами?

Человек, не очень хорошо умеющий доводить до руководства свои соображения, может нуждаться в более частом личном общении с менеджером.

Каковы ваши личные отношения с данным работником?

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

Насколько стабильно или, наоборот, неустойчиво положение компании?

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

Разные стили проведения личных встреч с подчиненными

Итак, вы распланировали личные встречи с подчиненными. Для чего в реальности нужно их использовать? Я встречалась с разными стилями проведения встреч и могу сказать: их эффективность в равной степени зависит как от менеджера, так и от подчиненного.

Встреча для составления списка необходимых дел

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

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

Встреча для обсуждения в свободной манере

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

Встреча с обратной связью от вас к подчиненному

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

С сотрудниками, имеющими проблемы в работе, встречи «с обратной связью» следует проводить чаще. Если же речь идет о подчиненных, определенных к увольнению, рекомендую встречи с ними документировать. Запись такой встречи должна включать в себя обсужденные вопросы и ожидания, возложенные вами на данное лицо. Эти записи должны быть направлены работнику (обычно по e-mail).

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

Отчет о продвижении проектов

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

Личные встречи как способ узнать сотрудников

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

Не бойтесь проводить личные встречи вне офиса

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

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

Хороший менеджер, плохой менеджер: один лезет во все мелочи, а другой делится полномочиями

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

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

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

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

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

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

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

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

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

Практические советы по правильному делегированию

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

Используйте цели команды, чтобы определить, в какие детали следует влезать

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

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

Получайте информацию от систем, прежде чем обращаться к сотрудникам

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

Корректируйте фокус внимания в зависимости от фаз проекта

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

Установите стандарты для кода и систем

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

Нейтрально, а лучше позитивно относитесь к хорошим и плохим новостям внутри команды

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

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

Создание корпоративной культуры с постоянной обратной связью

Когда я упоминаю заключение о работе, что приходит вам в голову? Вы морщитесь? Закатываете глаза, изображая впустую потерянное время, или ругаетесь при мысли о необходимости делать эту работу? А может быть, на вас нападает страх при мысли, на какие новые неожиданные недостатки вам укажут? Или вы ощущаете некоторое нервное возбуждение, ожидая узнать, что думают о вас люди?

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

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

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

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

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

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

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

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

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

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

Заключения по результатам работы

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

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

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

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

Написание и представление заключений по работе

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

Выделите на написание заключений достаточно времени и не затягивайте с началом работы

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

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

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

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

Используйте конкретные примеры и выдержки из оценок, которые коллеги дали работнику

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

Уделяйте больше времени фиксации достижений работника и его сильных сторон

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

Выделяйте конкретные направления для самосовершенствования сотрудников

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

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

сами по себе работают хорошо, но другим с ними трудно: они бывают излишне критически настроены или даже грубы на совещаниях, систематических коллективных проверках кода и в других видах сотрудничества;

испытывают сложности с разбивкой работы на промежуточные этапы и не умеют планировать время на разработку программы и выпуск в срок;

хорошо работают с программистами, но не умеют взаимодействовать с другими отделами или командами;

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

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

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

Избегайте сюрпризов

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

Запланируйте время, чтобы обсудить заключение с работником

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

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

Спросите технического директора: определение потенциала

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

Хочу высказать вот какое соображение. Тот, кто не продемонстрировал никаких способностей, хотя работает в компании достаточно давно, скорее всего, и не обладает никаким особенным потенциалом, во всяком случае, в рамках данной компании. И неважно, в каком университете он учился, как хорошо умеет говорить, какого он роста… если работник проработал в компании достаточное время и ничего не показал, значит, его потенциал — всего лишь плод вашего воображения (или когнитивных искажений).

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

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

Помощь подчиненным в карьерном росте

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

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

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

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

Чтобы прояснить этот вопрос, возьмем пример компании Famous BigCo. Она нанимает выпускников колледжей на должности уровня Е₂ (на должности Е₁ принимают стажеров). В компании существует такая практика: если работник в течение двух лет не демонстрирует способность пройти уровень Е₂, то здесь у него нет будущего. Эта политика относится к уровням Е₂—Е₄, однако работник может на всю жизнь застрять на должности Е₅.

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

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

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

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

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

Трудные ситуации: увольнение отстающих

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

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

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

В идеале вы должны знать детально, какую работу должен выполнять данный сотрудник. Если он ее не выполняет в полном объеме, вы должны сказать ему: «Делайте А, Б и В. Будьте добры». Но, разумеется, как и во всех воображаемых идеальных ситуациях, реальность редко бывает такой простой.

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

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

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

В любой организации с активно действующей кадровой службой и требованиями по стандартному «Плану улучшения работы» востребован архив негативных оценок в отношении работника, подпадающего под увольнение. Но даже если у вас нет самостоятельного отдела персонала, советую рекомендации по улучшению доводить до сотрудников письменно, ясно указывая, какое время отведено на улучшения. Добивайтесь, чтобы ваши работники также в письменном виде (используя e-mail) подтверждали, что получили рекомендации. Это не только защищает вас с юридической точки зрения, но и помогает справедливо относиться к работникам.

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

Спросите технического директора: как подготовить человека к увольнению

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

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

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

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

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

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

Обратимся к оценке вашего собственного опыта

Есть ли у вас практика регулярных личных встреч с подчиненными?

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

Высказывали ли вы оценки или рекомендации своим подчиненным за последнюю неделю? Когда в последний раз вы публично хвалили сотрудника перед командой?

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

Приходилось ли вам впустую терять время, читая заключения по работе сотрудников? Чего в этих заключениях не хватало, чтобы они стали более полезными?

Какую самую полезную оценку работнику со стороны окружения вы видели? Как она была доведена до вас?

Знаете ли вы, как работает механизм карьерного роста сотрудников в вашей компании? Если нет, то можете ли вы попросить кого-то ознакомить вас с ним?

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

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

Ниже привожу описание работы руководителя команды инженерного профиля (определение мое) по управлению целой командой.

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

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

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

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

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

Как становятся менеджерами, управляющими людьми

Я начинала как неформальный руководитель группы (тим-лид) в компании, не признававшей менеджеров в традиционном понимании. После того как я в течение некоторого времени поруководила группой неформально, подошло время, когда меня официально назначили менеджером. Такая позиция в нашей организации была непривычной, и весь коллектив встретил мое назначение с определенной настороженностью. Когда между менеджерами разделялось инженерное направление, мы долго взвешивали, кто мог бы справиться с ним. Не все менеджеры хотели работать с бывшими коллегами, но мне повезло. Большинство тех, кем я руководила, долго проработали со мной и спокойно восприняли меня как менеджера. Их поддержка мне очень помогла. Не все обстояло гладко, но она дала очень важный для меня толчок.

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

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

Бетани Блаунт

Оставайтесь инженером

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

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

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

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

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

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

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

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

Как отладить слабо работающую команду

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

Команда не укладывается в сроки

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

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

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

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

Конфликтный член коллектива

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

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

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

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

Недовольство слишком большим объемом работы

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

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

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

Проблемы с взаимодействием в коллективе

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

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

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

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

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

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

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

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

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

Щит для команды

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

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

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

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

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

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

Как способствовать хорошим решениям

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

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

Создавайте культуру ориентации на конкретные данные

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

Сами обдумывайте вопросы выпуска продукта

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

Смотрите в будущее

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

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

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

Регулярно следите за процессами в ретроспективе и сравнивайте данные с сегодняшним днем

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

Хороший менеджер, плохой менеджер: уклониться от конфликтов и погасить их

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

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

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

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

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

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

Что нужно и чего не нужно делать в управлении конфликтами

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

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

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

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

Избегайте конфликтов с другими командами. Как ни странно, менеджеры, стремящиеся избегать конфликтов, часто конфликтуют с другими командами. Они склонны защищать свой коллектив и агрессивно реагируют на то, что воспринимают как угрозу со стороны. Когда что-то идет не так и инциденты затрагивают несколько команд, такой менеджер с пеной у рта требует справедливости по отношению к своему коллективу или возлагает вину за возникшую ситуацию на другие команды. Иногда это своеобразный выход ощущения неполноты контроля в своей команде. Один приятель сказал мне: «Я не говорил своей команде и 10% того, в чем ей необходимо совершенствоваться, потому что боялся, что за этими 10% они не услышат 90% моих похвал. Поэтому ответственность за недостатки я перекладывал на другие команды. Я хотел, чтобы в моей команде было больше ответственности, но приходилось придумывать, как сказать это ей помягче».

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

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

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

Трудные ситуации: разрушители единства в команде

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

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

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

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

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

Блестящий негодяй

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

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

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

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

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

«Человек в себе»

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

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

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

Человек, не уважающий других

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

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

Дополнительные соображения по проектному менеджменту

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

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

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

Важнейшие правила проектного менеджмента

Ниже я привожу некоторые важные для вас правила.

Правила не подменяют agile-методов

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

У каждого инженера-программиста 10 продуктивных недель в квартал

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

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

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

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

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

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

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

Будьте избирательны с проектами, отданными на оценку команде

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

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

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

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

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

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

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

Обратимся к оценке вашего собственного опыта

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

Насколько хорошо, по вашим ощущениям, вы знаете повседневные проблемы в написании, развертывании и поддержке кода в команде?

Насколько часто ваша команда маркирует свою работу как законченную?

Когда в последний раз вы писали программу, устраняя в ней ошибки, или работали в паре с членом команды над трудным для него кодом?

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

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

Как принимаются решения в вашей команде? Есть в ней процедура распределения обязанностей по принятию решений? Принятие каких решений вы оставляете лично себе?

Когда в последний раз вы оценивали завершенный проект, чтобы увидеть, достиг ли он поставленных целей?

Насколько полно понимает ваша команда, почему она работает над конкретными текущими проектами?

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

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

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

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

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

Обычно не предполагается, что главный инженер ежедневно пишет код. Однако он несет ответственность за поддержание и повышение технологического уровня работы всей организации, задействуя при этом процессы профессионального обучения и подбора персонала. Он должен иметь серьезный технический опыт и подготовку, уделять необходимое время исследовательской работе в отношении новых технологий, а также оставаться на уровне существующих трендов в 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 или сопротивление постановке нового продукта в приоритеты). Вводимое изменение может разрушить и без того хрупкие связи, привязывающие команду к компании.

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

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

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

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

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

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

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

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

Положительные стороны лени и нетерпения

Мне нравится мысль, высказанная Ларри Уоллом в книге «Язык программирования Perl»14, что «лень, нетерпение и высокомерие — “добродетели”» инженера-программиста». Эти «добродетели» присущи и лидерству, и я рекомендую всем менеджерам научиться превращать их в преимущества.

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

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

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

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

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

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

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

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

Обратимся к оценке вашего собственного опыта

Когда в последний раз вы анализировали свое расписание, чтобы выявить, чем занимаетесь, не создавая ценности ни для себя, ни для команды? Обратите свой взгляд на последние пару недель. Посмотрите на две недели вперед. Чего вы достигли и чего рассчитываете достичь?

Если вы по-прежнему пишете код, то как это вписывается в ваш общий режим дня? Вы пишете после работы? Что побуждает вас на продолжение затрат своего времени на эту деятельность?

Какую свою последнюю задачу вы перепоручили одному из членов команд? Была она простой или сложной? А тот, кому вы ее делегировали, как справляется?

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

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

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

Когда в последний раз вы посылали e-mail после восьми часов вечера или в выходные? Полагаете ли вы, что человек, получивший e-mail, должен на него ответить? Нужен ли был вам его ответ?

Управление менеджерами

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

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

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

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

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

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

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

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

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

как извлекать полезную информацию даже из тех отчетов, которые можно пропускать;

что значит делать менеджеров подотчетными вам;

как управлять менеджерами-новичками и опытными менеджерами;

как принимать на работу новых менеджеров;

как находить корни слабой работы организации;

как поддерживать в командах стремление к совершенствованию информационных технологий.

Спросите технического директора: ошибочность политики открытых дверей

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

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

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

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

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

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

«Встречи на земле»

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

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

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

Вот некоторые рекомендации по наводящим вопросам при «встрече на земле».

Что вам нравится (или не нравится) в текущем проекте?

Кто из вашей команды особенно хорошо работает в последнее время?

Есть ли у вас какие-то соображения по поводу вашего менеджера: что идет хорошо, а что — не очень?

Какие изменения, по вашему мнению, нам необходимо внести в данный продукт?

Не считаете ли вы, что мы проходим мимо интересных перспективных возможностей?

Что вы думаете о работе всей организации? В чем нам стоит работать лучше, или больше, или меньше?

Есть ли что-то в бизнес-стратегии компании, что вам непонятно?

Что мешает вам сейчас достигать наивысших результатов в работе?

Довольны ли вы работой в компании?

Что мы могли бы сделать, чтобы работа в компании приносила вам большее удовольствие?

Такой формат личных встреч не всегда и везде возможен. Если в квартале 60 рабочих дней, а в вашей организации 60 человек, то даже одна встреча с каждым за этот период означает, что вы имеете одну такую встречу в день или пять в неделю в течение 12 недель. Ситуация становится все более напряженной, по мере того как возрастает численность организации. И на каком-то уровне встречи теряют смысл: если в организации 1000 человек, то все свое время вы будете посвящать только встречам с ними (допустим, вы работаете 40 часов в неделю). Однако в организации с меньшей численностью ежеквартальные встречи с каждым сотрудником все же имеют смысл.

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

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

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

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

Как, по вашему мнению, строится взаимодействие вашей команды с другими подразделениями организации?

Есть ли вопросы, касающиеся организации в целом? Я могу ответить на них.

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

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

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

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

Подотчетность менеджера

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

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

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

Вот несколько сложных, но достаточно распространенных ситуаций, пережитых мною на личном опыте.

Нестабильный план по выпуску продукции

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

Ошибки технического руководителя группы

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

Команда постоянно работает в авральном режиме

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

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

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

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

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

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

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

Хороший менеджер, плохой менеджер: всеобщий угодник

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

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

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

Признаки того, что рядом с вами может быть такой всеобщий угодник:

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

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

когда такому человеку трудно или плохо, это написано у него на лице, в связи с чем у команды пропадает уверенность;

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

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

он говорит «да» всем и посылает противоречащие друг другу сигналы своей команде и внешним партнерам по поводу того, что может быть реально исполнено. Результат — в коллективе возникает серьезная путаница;

он производит впечатление человека, знающего все проблемы компании. Однако ни одной из них он прямо не занимается.

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

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

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

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

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

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

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

Управление менеджерами-новичками

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

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

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

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

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

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

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

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

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

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

Управление опытными менеджерами

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

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

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

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

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

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

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

Прием менеджеров на работу

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

Начнем с того, что многие руководители не очень охотно берут менеджеров со стороны, имея на это веские причины. Как правило, мы с трудом определяем, сможет ли новый инженер-программист хорошо писать код в команде, не сводя остальных ее членов с ума. Но ведь написание кода — это навык, и мы можем попросить кандидата продемонстрировать владение им. А менеджмент — это… Кстати, а что это вообще такое? Как проводить собеседования с кандидатами на роль менеджера? На что следует обращать особое внимание при приеме на работу менеджеров?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отладка слабо работающих организаций

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

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

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

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

Должна быть идея

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

Проверьте данные

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

Наблюдайте за командой

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

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

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

Задавайте вопросы

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

Следите за динамикой процессов в команде

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

Никогда не медлите с помощью командам

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

Будьте любознательны

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

Формирование ожиданий и обеспечение своевременных результатов

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

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

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

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

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

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

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

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

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

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

Сложные ситуации: нечеткие планы

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

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

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

Методы борьбы с неопределенностью в планировании

Вот несколько приемов по улучшению планирования, основанных на моем личном опыте.

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

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

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

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

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

Насколько объемен данный проект?

Насколько он важен?

Сможете ли вы ясно объяснить ценность этого проекта любому спрашивающему человеку?

Что даст команде успешное исполнение данного проекта?

Ценность этих вопросов в том, что вы подходите к техническим проектам так же, как и к инициативам по новой продукции. Эти проекты имеют своих приверженцев, свои цели, свое расписание, и управляются они так же, как и другие большие мероприятия организации. Это нелегкий процесс, потому что часто в тех случаях, когда вы знаете, что какой-то проект важен, вы не знаете, как сформулировать оценку так, чтобы бизнес-подразделения это поняли. Это особенно нелегко с учетом сложной природы инженерных проектов и трудностей измерения эффективности в программировании. Поэтому вы часто вынуждены объяснять технические детали партнерам из нетехнического блока, а они могут не понимать, какую цель вы преследуете и почему. Здесь я советую тщательно подбирать данные, необходимые для подкрепления вашей позиции, и доводить до партнеров, что даст реализация проекта. Представьте себе систему, редко претерпевающую изменения. По итогам данного проекта она кардинально не улучшится. А вы предлагаете работу определенного объема с этой системой. Очень возможно, что проект и не стоит ваших усилий. К сожалению, на практике всегда не хватает времени на исследовательское программирование, чистку устаревшего или неподдерживаемого кода и улучшение качества программирования, хотя их хотела бы осуществить ваша команда. Поэтому правильное понимание действительной важности того или иного проекта позволит сосредоточиться на чем-то действительно важном и сэкономить время для других необходимых дел.

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

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

Поддерживать свой технический уровень

Очень часто я слышу от менеджеров один и тот же вопрос: «Как поддерживать свой технический и инженерный уровень?» Мы знаем, что без развития технических навыков мы рискуем потерять связь с профессией и отстать от времени. Однако что дает вам техническая компетентность? Чтобы дать ответ, для начала проясним вашу техническую зону ответственности.

Контролируйте необходимый технический уровень при создании ПО

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

Задавайте компетентные вопросы

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

Анализируйте и разъясняйте командам необходимость компромиссов между техническими аспектами и бизнес-интересами компании

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

Делайте конкретные запросы

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

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

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

Опирайтесь на собственный опыт

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

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

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

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

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

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

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

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

Обратимся к оценке вашего собственного опыта

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

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

За что они отвечают?

Как вы оцениваете их работу?

Какие аспекты работы, по вашему мнению, наиболее важны для достижения успеха?

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

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

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

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

Как вы строите собеседования с новыми менеджерами? Затрачиваете ли время на обсуждение персональных ценностей и подхода к менеджменту? Привлекаете ли членов команды к беседам с потенциальными менеджерами или не допускаете их до этого процесса? Затрачиваете ли время на получение личных характеристик кандидата у других людей?

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

Высшая лига

Характер повседневной работы менеджера старшего звена во многом зависит от компании. Было бы глупо утверждать, что моя работа в новом частном предприятии с персоналом в 70 человек была такой же, как и работа старшего менеджера, руководящего тысячей человек в компании, входящей в список Fortune 500. Огромное количество книг написано о менеджерской работе, в том числе о менеджменте в крупных корпорациях. В конце главы приведен список книг об общих принципах руководства в таких компаниях. Все эти книги — великолепные и важные путеводители для руководителей высшего звена.

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

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

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

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

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

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

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

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

Вы знаете, как заставить сотрудников и коллективы нести ответственность за результаты работы.

В книге «Высокоэффективный менеджмент»16 топ-менеджер и ученый Эндрю Гроув разделяет задачи менеджмента на четыре общие группы.

Сбор информации или разделение информации с заинтересованными сторонами

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

Подталкивать сотрудников к правильным действиям

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

Принятие решений

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

Подавать пример подчиненным

Разъяснение людям ценностей компании. Демонстрация приверженности обязательствам. Пример нужно подавать даже тогда, когда не хочется.

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

В чем моя работа?

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

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

У меня заняло немало времени осознание: моя работа не в том, чтобы быть самым умным в коллективе. И не в том, чтобы быть всегда правым. Моя роль скорее в том, чтобы помочь команде принять наилучшие решения и провести их в жизнь последовательно и эффективно.

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

Джеймс Тёрнбулл

Ролевые модели технических руководителей старшего звена

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

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

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

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

Выработка технологической стратегии или видения компании

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

Организационная работа

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

Исполнительская работа

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

Представление технологического лица компании перед внешними заинтересованными сторонами

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

Менеджмент по вопросам развития инфраструктуры и технического обеспечения

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

Управление бизнесом компании

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

Ниже привожу варианты комбинаций этих ролевых функций. Часть я наблюдала лично или была свидетельницей со стороны.

Бизнес-интересы компании, технологическая стратегия, организационная и исполнительская работа: технический директор или главный инженер (вице-президент или старший вице-президент).

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

Организационная и исполнительская работа, управление бизнесом компании: вице-президент по технологиям, CEO.

Менеджмент по вопросам развития инфраструктуры, организационная и исполнительская работа: технический директор / заместитель генерального директора по информационной поддержке бизнеса; возможно — вице-президент по техническим вопросам.

Технологическая стратегия, управление бизнесом компании, исполнительская работа: руководитель департамента новой продукции (или директор по продуктам), иногда — технический директор.

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

Организационная и исполнительская работа: вице-президент по технологиям, иногда заместитель генерального директора по персоналу.

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

Какова роль вице-президента по технологиям?

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

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

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

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

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

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

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

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

Что представляет собой должность технического директора?

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

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

Так что же такое технический директор?

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

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

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

Что я понимаю под словом «исполнительное»? Технический директор отвечает за разработку стратегических планов компании и помогает осуществить их путем разбивки проблем и направления людей на их исполнение.

Итак, что же все-таки в реальности делает технический директор?

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

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

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

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

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

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

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

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

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

Спросите технического директора: какую должность мне занять?

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

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

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

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

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

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

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

Смена приоритетов

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

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

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

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

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

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

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

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

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

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

Разработка стратегии

Летом 2014 года в качестве старшего вице-президента по технологиям в стартапе Rent the Runway я столкнулась с серьезной проблемой. Мой CEO сказала, что на следующем заседании совета директоров хочет поставить вопрос о моем назначении на должность технического директора. Меня просят представить совету технологическую стратегию компании. Потом она несколько раз возвращала мне написанные варианты, пока не удовлетворилась. А остальное, как говорят, осталось достоянием истории.

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

Когда я говорю о руководстве старшего звена, то выделяю стратегию как важнейший элемент. Большинство людей даже не знает, с чего начать, когда речь заходит о выработке стратегии на общем уровне. Во всяком случае, я не знала. Мне помогли советом CEO и исполнительный технический директор. Он стал моим ментором. Я попросила необходимые сведения и идеи у команды исполнителей, поставила теоретические вопросы перед старшими членами команды инженеров-программистов и с их помощью увидела конкретные проблемы. Я делала это не одна. Итак, с учетом изложенного, что же собой представляет технологическая стратегия?

Активно занимайтесь исследованиями

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

Соединяйте исследования с идеями

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

Разработайте стратегию

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

Учитывайте стиль общения вашего совета директоров

Ранее я уже рассказала, что CEO несколько раз возвращала мне варианты технологической стратегии компании. На самом деле она отвергла две вещи. Первой был стратегический план, который почти целиком посвящался деталям систем и архитектуры, в нем было очень мало идей, выходящих за пределы предстоящих 6–12 месяцев. Ничего не говорилось о факторах развития бизнеса. Второй проблемой была презентация. Ранее меня учили, что для небольшой аудитории лучше использовать слайдовые презентации, не слишком перегруженные информацией. Но для нашего совета директоров нужна была насыщенная презентация. Оказалось, они привыкли знакомиться с материалами презентации еще до ее проведения, чтобы потом можно было сосредоточиться на деталях. Тогда я не поняла этого, поэтому потратила немало сил на то, что на бумаге было малоинформативным. Еще один урок для меня.

Как видите, в данном случае хорошая технологическая стратегия подразумевала несколько вещей. Да, в ней необходимо было остановиться на вопросах технологической архитектуры. Вместе с тем в ней затрагивались и вопросы организационной структуры компании. В ней должно было содержаться понимание основ бизнеса и направлений его развития. Я люблю говорить, что технологическая стратегия в компаниях, ориентированных на создание продукта, должна раскрывать весь имеющийся потенциал бизнеса. Это не документ, содержащий только реакцию на текущие проблемы и объясняющий их. Стратегия должна способствовать будущему росту и предугадывать его. Если вы работаете в бизнесе, связанном с производством продукции, то именно она должна быть в сердце стратегии. Это не означает, что в ней должны быть точно определены направления производства. Технологическая стратегия способствует успешной реализации более широких планов создания продукта.

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

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

Трудные ситуации: как сообщать плохие новости

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

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

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

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

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

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

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

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

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

Впервые мой босс — не из технической сферы. Для меня это очень тяжело. Как правильно строить отношения с ним?

Впервые я испытала, что такое руководитель не из технической сферы, попав в прямое подчинение к CEO в компании Rent the Runway. Находиться в подчинении у совершенно не технического человека — полный культурный шок. К счастью, есть некоторые методы, помогающие правильно выстраивать отношения в этом случае.

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

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

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

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

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

Старайтесь демонстрировать поддержку. Всегда спрашивайте, чем можете помочь руководителю и всей компании.

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

Ваши взаимоотношения с коллегами-руководителями

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

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

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

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

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

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

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

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

Эхо

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

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

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

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

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

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

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

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

По мере того как вы отдаляетесь от команды, вы можете начать относиться к ее членам не как к человеческим существам, а как к «винтикам». Люди всегда могут сказать, когда их руководители перестают видеть в них индивидуальности. Если они почувствуют, что никто не заботится лично о них, они могут начать испытывать меньшую готовность отдавать всех себя общему делу, принимать риски и справляться с тяжелыми обстоятельствами. Сохраняя внимание к коллективу, пусть и на уровне, кажущемся поверхностным, вы укрепляете уверенность, что люди интересны вам в своем личном качестве, а не только с точки зрения текущих проектов или конкретных результатов работы. Это укрепляет отношения с коллективом, даже без плотных связей с отдельными членами. Зачастую придется предъявлять работникам строгие требования. Но команда заслуживает лидера, остающегося добрым даже при требовательности.

Вы пример для подражания подчиненным. Каких руководителей вы хотите воспитать? Какое наследство им передать?

Править посредством страха или управлять с помощью доверия

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

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

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

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

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

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

Исправление культуры, основанной на страхе

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

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

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

«Извините, я не должна была повышать на вас голос. Я глубоко сожалению о своем поведении».

«Извините, я невнимательно слушала вас и тем самым могла вас обидеть».

«Извините, я сделала ошибку, когда не рассказала вам о Бобе».

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

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

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

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

Концепция «истинный север»

Иногда недооценивают важнейший аспект роли высших руководителей. Этот аспект — создание ими в своей функциональной области (для технического директора — технологии; для директора по финансам — финансы) необходимого стандарта качества. Я называю его «истинным севером».

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

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

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

единственная точка неуспеха;

наличие известных разработчикам проблем;

разработка продукта, не предназначенного для высоких нагрузок;

утрата программным продуктом данных;

выпуск кода, не прошедшего достаточного тестирования;

медленная работа ПО.

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

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

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

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

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

Рекомендуемая литература

Институт Арбингера. Лидерство и самообман: Как выбраться из ящика. San Francisco: Berrett-Koehler, 2000.

Браун Б. Великие дерзания: как победа над страхом показаться слабым и смешным влияет на то, как мы живем, любим, воспитываем детей и работаем. М. : ЛитРес, 2015.

Друкер П. Эффективный руководитель. М. : Манн, Иванов и Фербер, 2015.

Голдсмит М., Рейтер М. То, что привело тебя в сегодня, не обязательно приведет в завтра: как успешные люди становятся еще успешнее (What Got You Here Won’t Get You There: How Successful People Become Even More Successful). New York: Hyperion, 2007.

Гроув Э.. Высокоэффективный менеджмент. М. : Филинъ, 1996.

Маркет Д. Разверните ваш корабль: жесткий менеджмент от капитана лучшей подводной лодки США. М. : Манн, Иванов и Фербер, 2013.

Обратимся к оценке собственного опыта

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

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

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

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

Каковы ваши отношения с другими руководителями старшего звена в компании? С кем отношения хорошие, а с кем — плохие? Что вы можете сделать, чтобы улучшить отношения? Насколько вы разделяете приоритеты этих членов команды и насколько, по вашему мнению, они понимают ваши приоритеты?

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

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

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

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

Культура бутстрэппинга18

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

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

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

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

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

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

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

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

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

Одна из очень интересных работ об организационной политике в компаниях — статья известной деятельницы движения за права женщин Джо Фриман «Тирания бесструктурности»19. Хотя описываются ранние этапы существования феминистских и анархистских организаций, многие положения могут быть применены и к культуре стартапов. Внешнее отсутствие организационной структуры обычно сопровождается скрытой борьбой за доминирование различных групп, что неизбежно следует из природы человеческого общения. Интересно, что Фриман, в частности, описывает условия существования групп без прочной организационной структуры.

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

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

В такой группе должен существовать высокий уровень взаимопонимания. Информация в такой группе должна достигать каждого, мнения людей должны быть взвешенными, работа поровну разделена между всеми, члены группы должны принимать участие в принятии соответствующих решений. Это возможно только в небольшой группе, когда коллеги практически живут бок о бок на протяжении важнейших этапов решения задачи. Нет необходимости говорить, что количество внутренних связей в такой группе, охватывающих каждого, увеличивается с численностью группы. Это с неизбежностью ограничивает ее примерно пятью членами или приводит к тому, что остальные не смогут принимать участие в принятии решений. Успешные группы могут включать в себя и 10–15 человек, но при условии, что фактически они состоят из более мелких подгрупп, выполняющих конкретные части общей задачи. Такие подгруппы должны «перекрывать» друг друга, с тем чтобы информация о том, что каждая из них делает, легко могла бы распространяться по всей группе.

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

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

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

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

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

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

В небольших компаниях, напротив, более распространен запоздалый ввод элементов организационной структуризации. Проблемы в таких компаниях возникают незаметно. Один человек привыкает принимать все решения и часто их меняет. Такая стратегия работает в мини-организации, где есть только он и еще пара людей. Но когда такая схема применяется при работе с командой из 10, 20, а то и 50 человек, то сразу становится заметным высокий уровень взаимного непонимания и затраченных впустую усилий. Цена изменения решений становится все более высокой.

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

Оценка своей роли

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

Персонал

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

Возраст компании

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

Размеры существующей инфраструктуры

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

Порог рисков

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

Организационная структура компании растет по мере ее роста и возраста. Есть даже закон, описывающий эту связь. Он приводится в книге Джона Галла «Системантика»21:

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

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

Мой совет руководителям прост: когда случаются неудачи, исследуйте все аспекты окружающей действительности, приведшие к ним. То, что вы увидите, станет возможностью совершенствовать организационную структуру предприятия либо за счет создания дополнительных вариантов, либо за счет отказа от некоторых. Обдумайте вопрос, как часто вашу организацию постигают неудачи, сколько они стоят, и постарайтесь вынести оптимальное суждение относительно необходимых перемен. Использование неудачи как компаса для развития позволяет применять организационную структуру на нужном уровне. Если неуспех случается только в части системы (например, в одной из команд), можно осуществить структурные изменения только там, не затрагивая всей организации. А как с анализом успехов? Что же, вы можете кое-чему научиться на примере успеха, но, как правило, он плохой учитель. Как ни смешно, хотя судьба зачастую играет одинаковую роль и при успехе, и при неудаче, мы в большинстве случаев приписываем неуспех невезению, а успех — собственным действиям. Как гласит закон Галла, работающая простая система может развиться в систему сложную. Но это не означает, что применение уроков, полученных из успешной сложной системы, может позволить нам повторить успехи в других местах. Будучи людьми, мы склонны винить в неудачах фатум до тех пор, пока становится невозможным игнорировать собственную роль в них. Поэтому мы не слишком торопимся реорганизовывать структуру команд на основе опыта неудач. Напротив, успех заставляет нас верить, что везение позволит и дальше достигать высот. Но помните, что необходимо реально оценивать шансы на улучшение дел при более широком применении уроков успеха. Не забывайте, что для повторения успеха нужно хорошо понимать необходимый контекст.

В этом вопросе важную роль играют возраст компании и размер команды. Если вы работаете в организации, существующей уже в течение приличного времени и имеющей шансы на дальнейшее существование, эксперименты с организационной структурой (расширение или сокращение), нацеленные на повышение эффективности, могут быть очень полезны, даже если на первом этапе они окажутся весьма затратными. Это часть сделки. Обучение редко обходится бесплатно. Анализ ситуации и стремление к позитивным результатам требуют времени. Ваше время в будущем стоит меньше, чем в настоящем. Поэтому не следует слишком беспокоиться об экономии времени в будущем. То, что компания большая, имеет солидную историю и стабильна, еще не означает, что ее структура может быть такой жесткой и неизменной, как вы хотите. Изменения в технологиях часто делают рискованные в прошлом действия более безопасными по сравнению с неповоротливыми вариантами. Хороший пример — частота релизов. Частые релизы долго были трудным и дорогим делом. В значительной степени это происходило потому, что компании выпускали свое ПО потребителю в неизменном виде. Сегодня же, когда программное обеспечение стало услугой (SaaS)22, недочеты в нем могут быть легко устранены уже по ходу использования. Поэтому риски, связанные с изданием ПО, значительно снижаются по сравнению с небыстрой разработкой, что негативно влияет на конкурентоспособность продукции. Привязанность к старым понятиям структурности мешает многим людям воспринимать ее как таковую. Но если вы не признаете необходимость организационной структуры тогда, когда она нужна, то дела у вас могут пойти совсем плохо.

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

Создание собственной корпоративной культуры

Культура — это то, как делается общее дело, когда людям не нужно над этим задумываться.

Фредерик Лалу. Открывая организации будущего23

Тема культуры часто обсуждается при создании стартапов. Каковы базовые ценности компании? Что представляет собой ее корпоративная культура? Соответствуют ли ей новые работники? Или концепция «соответствия культуре» — всего лишь отговорка для дискриминации людей при приеме на работу?

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

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

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

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

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

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

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

Применение базовых ценностей

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

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

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

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

Учитесь определять тех, кто не разделяет ценности компании или команды. Если в вашей компании нормально закатывать рукава и включаться в общее дело, тот, кто регулярно «подбрасывает» свою работу другим, явно не придерживается ценностей компании. Если компания провозглашает ценностью «радость и позитивность», тот, кто пыхтит на каждую идею и все критикует, с трудом сможет вписаться в коллектив. Иногда люди изменяют поведение, воспринимая ценности компании. «Радость и позитивность» — в действительности одна из базовых ценностей компании Rent the Runway. А я не могла сказать о себе, что пришла туда из организации, где ценилась радость. Даже более того, я пришла из корпоративной культуры, характеризующейся как исключительно узкопрофессиональная и критиканская. А в Rent the Runway я научилась смотреть на вещи оптимистично. Это не значит, что я полностью утратила прошлый критический подход и позитивный взгляд дался мне легко. Вообще, использование базовых ценностей, чтобы объединять людей, если они разъединены, может помочь формулировать ясные мысли вместо расплывчатых.

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

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

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

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

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

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

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

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

Создание должностного расписания

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

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

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

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

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

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

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

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

Там, где у вас меньше должностных уровней, используйте более широкие вилки зарплат. Меньшее количество должностных уровней и широкие вилки зарплат четче разграничивают уровень профессиональной подготовки, необходимой для каждого уровня. В таком случае становится легче определить, кто работает на каком уровне. При значительном разбросе должностей необходимо иметь более широкие диапазоны заработной платы, в идеале перекрывающие друг друга. Так, скажем, если инженер-программист получает зарплату в диапазоне $50 000–100 000, то «вилка» для ведущего инженера-программиста может составлять $80 000–150 000. Это означает, что сильный инженер-программист может зарабатывать больше ведущего инженера. Такой люфт нужен, чтобы удержать талантливых инженеров, хорошо работающих на достигнутом промежуточном должностном уровне, но еще не готовых взять на себя дополнительную ответственность, связанную с переходом на следующую должность. Этот же люфт хорошо работает при найме новых работников, готовых прийти в вашу компанию на более низкие должности в надежде на скорое продвижение по службе.

Внимательно относитесь к «горячим точкам» роста сотрудников. Распространено наличие в компаниях определенных должностных уровней, называемых «вверх или в сторону». На начальных должностных позициях долгое отсутствие карьерного роста может означать, что сотруднику пока не удалось достигнуть зрелости и независимости в работе, нужных, чтобы остаться в компании. В должностном расписании это открытые или скрытые точки разрыва. А каков в вашей организации самый низкий должностной уровень, где люди могут находиться всегда, не продвигаясь по карьерной лестнице, но вместе с тем и не работая плохо? Этот уровень в компании — критическая точка. Во многих случаях он располагается где-то вокруг должностной позиции ведущего инженера-программиста. Тот, кто находится в ней, зачастую надежный член команды, но по собственному выбору может оставаться на ней неопределенно долго. Следует ясно видеть критические точки в вашей организации. Вы даже можете использовать их, чтобы ясно представлять себе, с какого именно должностного уровня карьерный рост в вашей компании становится делом непростым. Лучше, если большинство членов команды будут находиться в этой точке, а меньшинство — выше или ниже.

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

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

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

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

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

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

Кроссфункциональные команды

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

Я хочу уделить немного времени рассказу об одном замечательном опыте, вынесенном из работы в Rent the Runway, онлайн-сервисе аренды одежды. В ней была создана команда, совмещавшая функции разработчика ПО и подразделения по продуктам. Когда я пришла в компанию, команда инженеров-программистов была разделена примерно на две части: фасадную, занятую разработкой клиентской части сайта, и складскую, занимавшуюся поддержкой программного обеспечения, которое управляет логистикой. Мы быстро сделали так, что фасадная часть команды стала заниматься и пользовательским интерфейсом, и программно-аппаратным обеспечением, потому что переписывала код с РНР-монолита на микросервисные архитектуры, построенные на языках Java и Ruby.

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

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

Закон Конвея24, часто упоминаемый в дискуссиях, гласит: «Организации, осуществляющие дизайн систем… часто обречены на то, что системы копируют структуру общения в самих организациях».

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

Организация кроссфункциональных команд

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

Разумеется, каждое функциональное направление сосредоточивается на конкретных обязанностях. Кто-то из инженеров-программистов контролирует создание базовых систем, и вокруг него работает несколько специалистов, занимающихся базовым веб-приложением, мобильными приложениями и базами данных. У меня эти функции были сосредоточены в небольшой инфраструктурной группе, непосредственно разработкой продукта не занимавшейся. Даже в подобных группах инженеры, разрабатывавшие конкретный продукт, должны иметь некоторый резерв времени, чтобы заниматься такими вещами, как помощь пользователям по телефонным звонкам (дежурства on call), интервьюирование пользователей или поддержка программ. Я на основе личного опыта и опыта коллег рекомендую, чтобы 20% рабочего времени инженеров-программистов отводилось на эту работу.

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

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

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

Создание технологических процессов в разработке ПО

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

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

Спросите технического директора: что такое технологический процесс

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

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

Что мне делать? Я опасаюсь переходить от ситуации полного отсутствия процессов к задействованию сразу нескольких. Но что-то надо менять!

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

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

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

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

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

Практический совет: старайтесь не персонифицировать принятие решений

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

Проверка кода

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

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

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

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

Анализ сбоев

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

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

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

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

Ревизия архитектуры систем

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

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

Есть ли у нас стандарты разработки для новой системы?

Каков процесс ввода ее в действие и подготовки людей к работе?

Необходимы ли новые операционные условия для использования новой системы?

А вот некоторые рекомендации.

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

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

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

Обратимся к оценке вашего собственного опыта

Какова политика вашей компании? Какова существующая в ней практика? Положены ли они на бумагу? Когда в последний раз вы просматривали их?

Есть в вашей компании признанные ценности? Что они собой представляют? Как вы в команде относитесь к ним?

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

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

Заключение

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

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

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

Умение распознать голос своего «я» — один из важных плюсов медитации. Когда я писала первый вариант книги, он включал в себя определенные медитации для каждого должностного уровня. Лично для меня медитационные практики стали очень важным инструментом развития навыков самоуправления и самоосознания. Разумеется, медитация не панацея, но она может стать полезным упражнением для развития осознанности и понимания ваших реакций. Именно поэтому рекомендую ее вам, если вы заинтересовались. Моими излюбленными источниками по этой теме являются некоторые материалы на tarabrach.com, а также книги Пемы Чодрон25.

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

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

Оставайтесь любознательными! Удачи на вашем пути!

Об авторе

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

Благодарности

Я очень хочу поблагодарить моих редакторов, Лаурел Рума и Эшли Брауна: они помогли мне, впервые публикующемуся автору, относительно безболезненно пройти путь создания книги.

Спасибо Майклу Маршалу, Кейти Маккэффри, Джеймсу Тёрнбуллу, Кейт Хьюстон, Марку Хедлунду, Питу Майрону, Бетани Блаунт и Ларе Хоган за то, что они поделились с читателями своими историями на тему лидерства.

Спасибо всем, кто дал мне ценные советы и рекомендации, в том числе Тимоти Данфорду, Роду Бегби, Лиз Крауфорд, Кейт Хьюстон, Джеймсу Тёрнбуллу, Джули Стил, Мэрилин Кол, Кэтрин Стайер и Адриану Говарду.

Особая благодарность — человеку, с которым я тесно сотрудничала в процессе работы. Келлан Элиотт-Маккри много раз подсказывал мне, что же такое искусство менеджмента. Также хочу поблагодарить всех друзей из группы «Встречи технических директоров за общим столом». Спасибо, что долгие годы вы делились со мной опытом. Многие ваши советы стали частью книги.

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

И последнее (но не по степени важности) — спасибо моему мужу Крису. Разговоры за семейным столом помогли мне написать самые сложные части книги. Его советы и идеи помогли мне по-настоящему стать автором.

Примечания

1. Rent the Runway — онлайн-сервис по аренде дизайнерской одежды и аксессуаров. Прим. ред.

2. Бакингем М., Коффман К. Сначала нарушьте все правила. Что лучшие в мире менеджеры делают по-другому. М. : Альпина Паблишер, 2013. Прим. ред.

3. Уолл Л., Кристиансен Т., Орвант Д. Программирование на Perl. М. : Символ-Плюс, 2006. Прим. ред.

4. JVM — виртуальная машина Java. Прим. ред.

5. Рефакторинг — работа над структурированием кода. Прим. ред.

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

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

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

9. Система управления версиями — программное обеспечение для облегчения работы с изменяющейся информацией. Прим. пер.

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

11. Принцип Питера — положение, выдвинутое и обоснованное в одноименной книге Лоуренсом Питером. Формулировка: «В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности». Прим. пер.

12. Аллен Д. Как привести дела в порядок. Искусство продуктивности без стресса. М. : Манн, Иванов и Фербер, 2015. Прим. ред.

13. Бакингем М., Коффман К. Сначала нарушьте все правила. М. : Альпина Паблишер, 2014. Прим. ред.

14. Tom Christiansen, brian d foy, Larry Wall and Jon Orwant, Programming Perl, 4^th edition (Sebastopol, CA: O’Reilly, 2012). Прим. автора.

15. Кот Шрёдингера — мысленный эксперимент, предложенный Эрвином Шрёдингером, австрийским физиком-теоретиком, одним из создателей квантовой механики, которым он хотел показать неполноту квантовой механики при переходе от субатомных систем к макроскопическим. Прим. пер.

16. Гроув Э. Высокоэффективный менеджмент. М. : Филинъ, 1996. Прим. ред.

17. Ленсиони П. Пять пороков команды. М. : Манн, Иванов и Фербер, 2013. Прим. пер.

18. Бутстрэп, бутстрэппинг (англ. bootstrap, bootstrapping — «зашнуровка», иногда бутстреп, бутстреппинг) — название некоторых методов и процессов, содержащих принцип повторения и самоподдержки без воздействия извне, с использованием внутренних ресурсов. Прим. ред.

19. «Тирания бесструктурности» — известная статья Джо Фриман, одного из лидеров феминистского движения в США в 1960-х годах. В ней автор утверждала, что под внешней «бесструктурностью» феминистских и анархических движений скрывалась жесткая борьба за лидерство. Статья впервые официально опубликована в журнале The Second Wave в 1972 году. Прим. пер.

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

21. John Gall. Systemantics: How Systems Really Work and Especially How They Fail. New York: Quadrangle / The New York Times Book Co., 1975. На русский язык не переводилась. Прим. ред.

22. SaaS (англ. software as a service — программное обеспечение как услуга) — одна из моделей обслуживания, при которой подписчикам предоставляется готовое прикладное программное обеспечение, полностью обслуживаемое провайдером. Прим. пер.

23. Лалу Ф. Открывая организации будущего. М. : Манн, Иванов и Фербер, 2016. Прим ред.

24. Закон Конвея — положение, сформулированное американским программистом Мелвином Конвеем в 1967 году. Впервые было озвучено им на Американском конгрессе по модульному программированию в 1968 году. Прим. пер.

25. Пема Чодрон (Pema Chodron) — рукоположенная буддийская монахиня в тибетской традиции ваяраяна, преподаватель Чегуам Трунгпа. Целью ее работы является возможность применения буддийских учений в повседневной жизни. Прим. пер.

Содержание

Введение

Как читать эту книгу

1. Основы менеджмента

Чего ожидать от менеджера

Личные встречи

Обратная связь и помощь в работе

Повышение уровня подготовки и карьерный рост

Когда вами управляют

Оценка вашего опыта

2. Менторинг (наставничество)

Важность менторинга (наставничества) в отношении младших членов команды

Быть наставником

Наставничество над новым сотрудником

Хороший менеджер, плохой менеджер: звезда компании

Рекомендации менеджеру наставника

Ключевые моменты для наставника

Обратимся к оценке вашего собственного опыта

3. Технический руководитель группы

Все хорошие технические руководители знают одну хитрость

Основные моменты позиции технического руководителя группы

Управление проектами

Управление проектом

Точка принятия решения: остаться инженером или стать менеджером

Как быть хорошим техническим руководителем

Обратимся к оценке вашего собственного опыта

4. Управление людьми

С самого начала выстраивайте отношения с членами команды как с подчиненными

Как общаться с командой

Разные стили проведения личных встреч с подчиненными

Хороший менеджер, плохой менеджер: один лезет во все мелочи, а другой делится полномочиями

Практические советы по правильному делегированию

Создание корпоративной культуры с постоянной обратной связью

Заключения по результатам работы

Помощь подчиненным в карьерном росте

Трудные ситуации: увольнение отстающих

Обратимся к оценке вашего собственного опыта

5. Управление командой

Оставайтесь инженером

Как отладить слабо работающую команду

Щит для команды

Как способствовать хорошим решениям

Хороший менеджер, плохой менеджер: уклониться от конфликтов и погасить их

Трудные ситуации: разрушители единства в команде

Дополнительные соображения по проектному менеджменту

Обратимся к оценке вашего собственного опыта

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

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

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

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

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

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

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

Положительные стороны лени и нетерпения

Обратимся к оценке вашего собственного опыта

7. Управление менеджерами

«Встречи на земле»

Подотчетность менеджера

Хороший менеджер, плохой менеджер: всеобщий угодник

Управление менеджерами-новичками

Управление опытными менеджерами

Прием менеджеров на работу

Отладка слабо работающих организаций

Формирование ожиданий и обеспечение своевременных результатов

Сложные ситуации: нечеткие планы

Поддерживать свой технический уровень

Обратимся к оценке вашего собственного опыта

8. Высшая лига

Ролевые модели технических руководителей старшего звена

Какова роль вице-президента по технологиям?

Что представляет собой должность технического директора?

Смена приоритетов

Разработка стратегии

Трудные ситуации: как сообщать плохие новости

Ваши взаимоотношения с коллегами-руководителями

Эхо

Править посредством страха или управлять с помощью доверия

Концепция «истинный север»

Рекомендуемая литература

Обратимся к оценке собственного опыта

9. Культура бутстрэппинга

Оценка своей роли

Создание собственной корпоративной культуры

Кроссфункциональные команды

Практический совет: старайтесь не персонифицировать принятие решений

Обратимся к оценке вашего собственного опыта

10. Заключение

Об авторе

Благодарности

Максимально полезные книги

Если у вас есть замечания и комментарии к содержанию, переводу, редактуре и корректуре, то просим написать на [email protected], вы поможете нам исправить недочеты и стать лучше.

Наши электронные книги

Дарите электронные книги

Заходите в гости:

mann-ivanov-ferber.ru

blog.mann-ivanov-ferber.ru

facebook.com/mifbooks

vk.com/mifbooks

twitter.com/mifbooks

instagram.com/mifbooks

youtube.com/user/mifbookstv

Дерево знаний

Предложите нам книгу