Предыстория
Работаю я тимлидом в аутсорсе/аутстафе уже добрый десяток лет. И были у меня в основном команды, которые я сам собирал.
Текущая команда - 8 человек, все из стран СНГ. Плюс архитектор и продакт из США. Внутреннее общение на русском, с заказчиком на английском; вся команда примерно в московском часовом поясе, заказчик в Нью-Йорке и Лос-Анджелесе. Привычная схема работы: утром внутренний звонок, обсуждаем весело текущие дела (я надеюсь), планируем работу на день, вечером встречаемся уже вместе с заказчиком - обсуждаем прогресс, задаем вопросы, планируем.
Команда показывает хорошие результаты, дела делаются, архитектор на стороне заказчика вполне доволен, продакт тоже выглядит счастливым (чаще всего), доверие имеется, страшных катастроф не было. Процессы налажены: спринты планируются, демо показываются, эпики закрываются.
И тут заказчик принимает решение, что рискованно доверять всю разработку одной компании, нужно добавить своих собственных разработчиков (т.н. “инхаус-разработчиками”). Я, конечно, понимаю ход мыслей заказчика, но добавление 3-х разработчиков к 8 уже имеющимся и так-то непростая задача. А тут эти трое из другого часового пояса. И англоговорящие конечно. И менталитет другой.
Хочешь - не хочешь, а проект надо вести дальше, два года сил вложено. Что делать? Как делать? Попробую рассказать ход своих мыслей и самые интересные моменты.
Первое, что накатило - это эмоции. С них и начнём ретроспективу изменений в команде.
Принятие и собственные эмоции
В руках менеджеров есть много формальных инструментов управления командой и сотрудниками. Однако все мы люди, и, скорее всего, первой реакцией на подобное событие будут различного рода негативные эмоции.
Это может быть обида, что взяли людей без вашего согласия. Или злость, что взяли людей не из вашей компании, а со стороны заказчика. Или страх, что сейчас всех выгонят. Или печаль, что вы столько работали над созданием команды, а тут буквально с нуля надо строить все процессы.
Менеджер всё же в первую очередь человек, и ничто человеческое ему (или ей) не чуждо. Важно принять эти эмоции, устроить с ними “чаепитие” так сказать, подумать-почувствовать откуда они взялись и попробовать найти в них если не опору, то хотя бы маркеры к действиям и изменениям. Например, мысль: “Ну вот придётся возиться с этими по объявлению” можно трансформировать в задачу: “Как перестроить процессы так, чтобы минимизировать повышение нагрузки на себя?”
А мысль “Господи, да они же запорят всё!” может быть толчком для пересмотра процессов сбора требований, постановки задач, контроля выполнения.
Первая эмоциональная реакция может служить маркером проблемных мест в команде. Поэтому используем эмоции как источник данных.
Делегируй это
Сложнее всего было наладить процесс общения с новыми членами команды. Найти достаточное количество времени в своём и так плотном рабочем графике было не просто. Значит, надо делегировать: назначить менторов за каждым новым разработчиком. Таким образом получаем:
Некритичный рост моей нагрузки. Я всё ещё продолжаю отвечать за планирование (уже большей команды), но контроль выполнения планов передан техлидам. Мне быстрее и проще созвониться с техлидами-менторами, обсудить с ними сложности и задачи, чем общаться с каждым новеньким отдельно по 20-30 минут. Одна большая нагрузка на меня разбилась на несколько маленьких частей.
Вовлечение людей в команду. Теперь новенькие вливаются в команду через общение с менторами, а менторы в свою очередь начинают доверять новеньким, понимая их возможности, находя сильные и слабые стороны каждого.
Взаимное повышение уровня доверия между членами команды. Все учаться работать вместе. Постоянно, каждый день.
Профессиональный рост менторов. Начнём с 1 подчинённого, продолжим двумя, добавим третьего, а там глядишь и в тимлиды можно отправить. Если захочет конечно. Отличный шанс для роста людей внутри команды.
Усиление контроля и больше обратной связи
Главными сложностями для работы новеньких в команде оказались:
разница часовых поясов. Основная часть команды была в GMT+3, теперь почти половина команды в GMT-8.
языковой барьер. Что не говори, а общаться на родном языке проще и приятнее. Да, все знают в команде знают английский, но он воспринимается как некий “официальный” язык.
Разница с часовыми поясами порождает проблему контроля: в течение рабочего дня, который теперь длится для команды примерно 15 часов, коллеги имеют примерно 2-3 часа, чтобы пообщаться вместе. И тут очень удобно, что один из "старых" разработчиков оказался в часовом поясе Нью-Йорка. Он и стал главным контактом для инхаус-разработчиков, пока остальная команда спит.
Чтобы новенькие работали в правильную сторону, стал устраивать звонки по историям в работе: я, ментор, новенький. Отдельные сессии для код-ревью и технических обсуждений - только ментор и новенький. Итого получаем, что у всех одинаковые ожидания и ход выполнения задач регулярно проверяется.
А язык продолжаем совершенствовать. В идеале не должно быть разницы между обсуждениями на русском и английском. Ежедневная практика в этом очень помогает.
Встречи 1о1 на английском стали отдельным вызовом для меня лично. Но проводить их надо, учусь выстраивать доверительные отношения не только с соотечественниками. Формат конечно отличается от того, что я провожу с разработчиками из своей компании. Меньше акцента на развитие и долгосрочные цели, больше - на контроль работы и результатов, на отзывы об атмосфере в команде, на сложности в общении и в работе над задачами. Главная цель - быть первоклассной командой. Над этим и работаем.
Больше рисков при планировании
Трое новых сотрудников со стороны заказчика достаточно много работают с архитектором проекта, который находится Лос-Анджелесе. Если раньше мы обсуждали какие-то вещи с архитектором по вечерам, а потом спокойно работали, то теперь он может изменить приоритеты инхаус-сотрудников в течение моей ночи. Первый раз это было для меня несколько неожиданно. Т.е. появился некий фактор риска, что сотрудники срочно будут делать не то, что было запланировано. Что ж, увеличиваем оценку рисков во время планирования, оставляем больший запас времени на форс-мажоры. Про разговор с архитектором - ниже.
С другой стороны, проблемы, которые появляются в течение нашей ночи, могут быть успешно решены инхаус-разработчиками в течение той же самой ночи. Это в идеале. Мы пока туда идём, но цель видна.
Производительность и качество работы новеньких сразу не была ясна, поэтому снижаем свои ожидания, работаем над четкими требованиями и дизайном. Диаграмма Ганта может неплохо помочь и проиллюстрировать зависимости между разработчиками в течение спринта. И показать, когда какие задачи должны быть сделаны. Есть в этом отход от чистого скрама, но зато проясняет для всех ожидания от спринта почти по дням. Планировать такое затратно по времени, но даже для самого себя это оказалось отличным инструментом контроля хода спринта. Чтобы сэкономить время, я делаю сильно упрощённую диаграмму, которая показывает примерный план выполнения по дням и людям.
Подтвердите зоны ответственности
Раз были случаи, что архитектор неожиданно менял приоритеты выполнения задач, и на следующее утро фронтенд разработчики не получали ожидаемый результат от бэкендеров, то это повод обговорить новые правила управления командой или подтвердить старые.
Архитектор со стороны заказчика не только должен на словах говорить, что управление командой остается прежним, но и не вмешиваться в процесс разработки (кроме действительно экстренных случаев)
Правила игры в команде должны быть понятны и соблюдаться всеми членами командами. Иначе отвечать за результат работы команды становится затруднительно. Если ваше планирование новенькие разработчики подтверждают с архитектором, то это повышает шансы на распад команды на порядок.
В общем, нужно сохранить свой авторитет и подтвердить право управлять командой.
Изменение “ритуалов” и распорядка дня
Раз появилось больше людей в других часовых поясах, значит надо подумать как адаптировать скрам-ритуалы под новые условия. В моем случае это выглядело так:
Нашли время на ретроспективу после демо, потому что мнение 3-х новых разработчиков о спринте тоже нужно учитывать
Изменилось время планирования, чтобы успеть обсудить задачи на спринт с инхаус-разработчиками.
Увеличение времени на скрамы с заказчиком. Как вариант - оставаться после стендапа с теми, у кого есть вопросы, ответы на которые требуют больше пары минут.
Если вы используете другой фреймворк, то тоже нужно подумать как изменить расписание регулярных встреч, чтобы повысить вовлеченность новых сотрудников.
Выводы
Мой случай с трансформацией аутстаф-команды в смешанную команду может быть не самым типичным и распространённым. Тем интереснее с ним работать. Тем сложнее решить эту задачу, адаптировать процессы под новые условия. И тем приятнее увидеть, что команда работает слаженно, что снова можно уйти в отпуск на две недели и быть уверенным, что команда справится.
Выводы по трансформации не будут сильно отличаться от условного цикла непрерывных улучшений. Хоть по ITIL 4, хоть от plan-do-check-adjust.
Важно увидеть и понять те места, которые “стали болеть” при такой трансформации. Можно использовать эмоции, можно использовать метрики, можно здравый смысл и имеющийся опыт. Вызов принят, цель ясна - “первоклассная команда, над которой не заходит солнце”.
Как формируется типичная IT-компания? Собираются несколько человек: руководитель, бэк- и фронт-разработчики, UX дизайнер и QA-инженер. И организуют стартап, который делает какой-то IT-продукт. Если все получается - работа идет, продукт оказывается востребован, рабочих рук уже не хватает, и руководство принимает решение о расширении команды. В помощь бэкенд-разработчику нанимается еще несколько бэков, организуется группа бэкенд-разработки. То же происходит с фронтенд-разработкой и т.д. Сначала возникает бурная радость: "Ура, мы ж растем!". Но через некоторое время в компании замечают, что штат вырос в 5 раз, а производительность - максимум в полтора. А то и вообще не выросла. А может быть даже уменьшилась. Почему это произошло? Что делать в этой ситуации? Эти и другие вопросы мы рассмотрим на бесплатном вебинаре, который будет полезен начинающим и действующим тимлидам, скрам-мастерам и руководителям, которые столкнулись или собираются столкнуться с проблемами роста.