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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страницы: «« 12345678 »»

Читать бесплатно другие книги:

СССР тридцатых годов ХХ века без Сталина? Как такое возможно?! Давайте понаблюдаем!Жизнь многомилион...
Из десяти открывшихся частных пекарен через год на плаву остаются только две-три. Во-первых, за кажу...
Психология, техника, практика — вот три кита, на которых держится умение говорить и быть услышанным....
Историческая трилогия выдающейся норвежской писательницы Сигрид Унсет (1882–1949) «Кристин, дочь Лав...
Мы знаем, что для успеха и реализации собственного потенциала необходимо постоянно учиться, но мы не...
У земли есть обратная сторона подземелье, которая сильно отличается от земли, и во многом жизнь там ...