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

7

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Никогда не медлите с помощью командам

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

Будьте любознательны

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

Формирование ожиданий и обеспечение своевременных результатов

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

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

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

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

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

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

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

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

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

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

Сложные ситуации: нечеткие планы

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

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

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

Методы борьбы с неопределенностью в планировании

Вот несколько приемов по улучшению планирования, основанных на моем личном опыте.

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

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

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

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

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

Насколько объемен данный проект?

Насколько он важен?

Сможете ли вы ясно объяснить ценность этого проекта любому спрашивающему человеку?

Что даст команде успешное исполнение данного проекта?

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

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

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

Поддерживать свой технический уровень