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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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