Как зайти в новую команду руководителем

Меня зовут Марина Перескокова. В сфере ИТ я уже 15 лет, 10 из них работаю в Яндексе.

Я автор книги «Мама, я тимлид!», и у меня есть свой обучающий курс для тимлидов.

Весной 2023 года меня позвали руководить службой разработки в Яндекс.Беспилотные технологии. Этот интересный опыт оказался для меня новым.

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

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

• код для этих роботов написан на C++;

• интерфейсы, которые визуализируют проезды – это 3D-графика на WebGL;

• бэкенд для бронирования машин – на Python и т.д.

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

• бэкэндеры, которые пишут на 3 языках;

• фронтэндеры;

• и тестировщики.

Чтобы адаптироваться к новой роли, я составила для себя план действий:

• я опиралась на свой предыдущий опыт работы и консультирование других руководителей;

• изучила тему через интернет-ресурсы, книги и статьи;

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

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

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

Инструкция нового руководителя. Направления действий

Глобально все мои действия по адаптации в роли руководителя можно разделить на четыре направления:

1. Технологии – все, что связано с написанием кода, с деплоем серверов и прочее техническое.

2. Продукт – все, что связано с зарабатыванием денег, с бизнесом.

3. Процессы – это Project Management, процессы тестирования и все остальное, что помогает команде держаться в строю.

4. Люди – все, что связано с наймом, с мотивацией, беседы с сотрудниками и т.д.

Но я считаю, что руководитель ИТ-подразделения должен сильнее всего фокусироваться на двух квадратах из четырех.

• На первом месте – люди. Потому что в ИТ-подразделении мы руководим инженерами, а хороший инженер в вашей команде – это залог успеха.

• На втором месте – технологии.

Я задвинула процессы и продукт не потому, что они не нужны. Но смотрите:

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

• Никто, кроме вас, не решит проблемы с технологиями, потому что вы в этом эксперт.

• А с процессами и продуктом, может быть, вам повезет, и в компании есть какая-то отдельная вертикаль менеджеров, которая поможет вам это настроить.

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

Инструкция нового руководителя. Часть 1. Люди

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

Шаг 1 – выстраиваем наём.

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

• Мне 2 февраля направили оффер, и на работу я официально вышла 7 марта.

• Но уже 7 февраля в обход всех корпоративных правил была добавлена во все чаты с эйчарами и начала ходить по собеседованиям кандидатов.

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

Поэтому:

1. Подробно выясняем, какие есть вакансии.

2. Правильно фокусируем рекрутмент, потому что они будут искать тех, кого легко искать, а не тех, кто вам сильнее всего нужен.

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

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

Что я разгребала в первом полугодии по этому поводу:

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

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

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

Шаг 2 – провести технический аудит тех сотрудников, которые уже есть.

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

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

• Вместе с экспертом вы оцениваете экспертизу всех членов команды.

• Плюс собираете, откуда только возможно, любую полезную инфу про ваших сотрудников – отзывы, истории успеха и т.д.

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

Что я разгребала в первом полугодии:

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

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

Шаг 3 – продумать, по какому принципу формировать команды.

У меня была проблема в том, что беспилотные технологии долгое время жили в режиме R&D, стартапа. Характерная черта режима R&D – вы заранее не понимаете, что вам придется делать.

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

Я оказалась на развилке:

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

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

Плюсы и минусы у кросс-функциональных команд:

• Плюсы:

  • Четко очерченные ресурсы на продукт.

  • Хороший фокус команды – они прикреплены к определенному проекту и его делают

• Минусы:

  • Руководитель – не эксперт по всем областям, которыми он руководит. Это проблема.

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

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

Поэтому мой выбор – выстраивание функциональных иерархий.

• Плюсы этого подхода:

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

  • Всем всегда есть куда расти – даже если ваш локальный проект маленький, вы можете по вертикали куда-то двигаться, быть руководителем по нескольким направлениям.

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

• Единственный минус – руководителю тяжело присматривать за своими сотрудниками, которые делают разные проекты. Он немного не в контексте. Но это решаемая проблема.

Поэтому мой выбор – выстраивать функциональные иерархии. В больших компаниях это более удачное решение.

Четвертый шаг – диагностика людей и процессов управления людьми.

У меня этот шаг был несколько форсирован тем, что 7 марта я вышла на работу, а 22 марта в компании стартовал Performance review.

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

Что я сделала:

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

• узнала их зарплатные ожидания;

• что их мотивирует;

• что они делали последние полгода;

• комфортно ли работать с руководителем.

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

Что я разгребала в первом полугодии:

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

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

Пятый шаг – настраиваем базовые процессы управления.

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

• выстраивать для них персональный карьерный трек;

• проводить встречи «Один на один»;

• контролировать;

• давать обратную связь.

Надо убедиться, что ваши лиды умеют это делать. Кто не умеет – научить, отправить на курсы.

Очень важен процесс онбординга новичков, особенно если у вас удачный наём.

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

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

Последний, 6-й шаг, о котором не стоит забывать, когда работаешь с командой, – провести тимбилдинг, а лучше несколько.

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

И мы весь семестр что-то делали: плавали на каяках, ходили на кулинарные мастер-классы, кепки раскрашивали – в общем, весело проводили время. Я про команду что-то поняла, и они ко мне тоже привыкли.

Инструкция нового руководителя. Часть 2. Технологии

Переходим ко второй части: что нужно делать относительно технологий.

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

Шаг 7 – провести опись имущества:

• узнать, какие сервисы у нас на балансе;

• и узнать, какие сервисы считаются критически важными.

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

• Из-за того, что у службы долгое время не было руководителя, а разработчики не совсем в курсе, где их зона ответственности, я очень долго ходила и узнавала, какие сервисы наши, и за что мы отвечаем.

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

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

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

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

После этого мы можем наконец-то сделать базовую документацию – шаг 8.

• Мы составляем список сервисов на поддержке с пометками об их критичности.

• Для каждого сервиса назначаем ответственного, потому что если его нет, то сервис никто не поддерживает.

• Добываем или создаем принципиальные схемы сервиса – какие есть deployment-юниты, как они с базами данных сочетаются.

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

Примерно так это выглядит в нашем случае. У каждого сервиса есть страничка, в ней прописано:

• где смотреть логи балансера;

• где смотреть конфигурацию базы;

• где тестинг;

• где продакшн;

• какие пользователи;

• кто ответственный.

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

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

Он мне предложил гениальное решение – спроси команду (шаг 9).

Я провела серию встреч – сначала со всеми фронтендерами, потом бэкендерами, потом с тестированием.

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

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

Чем такой формат хорош:

1. Вы ничего не знаете, а они уже все знают. Они эксперты, они изнутри понимают, что болит.

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

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

4. Наблюдая, на что люди жалуются, вы увидите, какие базовые процессы в команде хромают.

Что тут пошло не так:

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

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

Следующий, 10-й шаг, который стоит сделать, – написать инженерную стратегию.

Глобально инженерная стратегия – это некоторая система, которая помогает вам принимать решения по каким-то спорным вопросам.

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

Ваша инженерная стратегия может решить проблему. Например, вы, договариваетесь, что 30% ресурсов разработки уходит на техдолг, а 70% – мы тратим на продукт. И все, команда с менеджером работает по этой договоренности.

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

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

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

В инженерной стратегии мы прописываем:

• какие баги нужно чинить срочно, а какие – нет;

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

• какой стек технологий мы считаем предпочтительным.

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

При составлении инженерной стратегии важно:

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

• Легче приживутся практики, которые команда сама подсветила вам на встречах.

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

Что я разгребала в первом полугодии:

• Тяжелее всего было работать с возражениями. Для нас краеугольным камнем стало внедрение в наших сервисах концепции observability – автоматическое реагирование на инциденты, дежурства, SRE-практики и т. д. На каждой встрече находился сотрудник, который будто пришел в первый раз и не понимал, зачем нам внедрять такие процессы несмотря на то, что все это было записано, мы это обсуждали и т.д

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

Последний шаг, 11-й, – настроить обмен опытом.

• Если у вас классные инженерные специалисты, скорее всего, у них есть классные идеи.

• Сделайте так, чтобы они этими идеями обменивались.

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

Инструкция нового руководителя. Часть 3. Продукт

Тезисно расскажу про продукт и процессы.

В продукте важно:

• Шаг 12 – узнать стратегию бизнеса: на чем бизнес зарабатывает, и какое место ваши сервисы занимают в этом бизнесе. Это вам поможет правильно сфокусироваться – куда вкладывать силы, а что можно немного задвинуть.

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

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

• Последний, 15-й шаг – вовлечь команду в продукт:

  • Наладить догфудинг – чтобы ваша команда пользовалась сервисами, которые вы делаете;

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

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

Инструкция нового руководителя. Часть 4. Процессы

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

• Шаг 16 – настроить инженерные процессы. Сюда относится все, связанное с тестированием, code review, процессы безопасных релизов, процессы безопасных откатов.

• И шаг 17 – настроить процессы по управлению проектами. Это все, что связано с продуктивностью команды. Вам нужно определить, умеет ли ваша команда прогнозировать свой результат и укладывается ли она в срок. Со всем этим нужно разобраться, а затем настроить процессы по управлению проектами – определить свой метод: Scrum, Kanban, Waterfall или что-то другое.

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

Вместо послесловия

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

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

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

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

• организовать наём;

• настроить процессы;

• настроить людей так, чтобы команда работала без конфликтов;

• сфокусировать команду на продукте и т.д.

В этом ваша ценность как руководителя, даже если вы не являетесь уже инженерным специалистом, который всем диктует, как им работать.

Вопросы

Вы сказали, что надо настроить обмен опытом, а как именно вы настраивали обмен опытом?

У нас применяются следующие практики:

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

• Отдельно мы выстроили в службе DevOps контур. У нас нет выделенных DevOps-инженеров, но я собрала ребят, которым интересно заниматься подобными задачами, и они тоже регулярно собираются, обсуждают эти задачи.

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

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

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

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

Это тема отдельного доклада.

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

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

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

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

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

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

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

В Яндексе давно принята система грейдов и Performance review. Когда ее ввели, я работала в подразделении Яндекс.Карт – мы там собрали всех руководителей разработки и составили некоторый портрет специалиста.

Нам задали шкалу, сколько будет специалистов: джун, мидл, мидл +, старший лид и т.д. Мы их откалибровали и сформировали некоторые критерии, кто есть кто.

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

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

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

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

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

Это, конечно, печальная ситуация, но надо завоевать их доверие.

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

Судя по фотографиям, у вас команда в офисе или есть возможность встречаться. А если команда полностью удаленная, есть ли какая-то специфика?

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

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

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

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

Как вы на этапе собеседования понимаете, что кандидат замотивирован, а ценности кандидата и компании совпадают?

Мы рассказываем кандидату, что ему предстоит делать. Хороший знак – если он начинает задавать много уточняющих вопросов, потому что заинтересованный человек как-то откликается, ему интересно, он начинает какие-то детали выяснять. Если просто сидит и молча кивает, скорее всего, ему не очень интересно.

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

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

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

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

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

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

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

У вас же ушли «звезды». Где вы добрали специалистов?

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

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

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

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

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

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

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

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

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

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

Вы упомянули о сотрудниках, которые на все имеют свое мнение и саботируют процесс. Как с такими работать?

Если человек неуправляемый – это управленческая проблема. И тут надо подходить комплексно:

• Либо мы стараемся что-то сделать, чтобы человек начал худо-бедно делать то, что вы его просите.

• Либо работаем с его мотивацией.

• Либо понимаем, что не хватает доверия, и надо время, чтобы он начал вам доверять.

• Либо мы ему объясняем, что с такими софт скилами у него никогда не будет повышения.

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

Если вы видите, что все, что вы делаете, мимо, и он продолжает работать, как работал, надо задать себе несколько вопросов:

• Я его принимаю таким, какой он есть?

• Он в таком состоянии для меня полезен в команде?

• Я готов с ним еще 10 лет работать, если он продолжит со мной спорить?

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.