Чем больше в компании продуктов, команд и процессов, тем острее становится потребность в развитой культуре лидерства. Речь не только о тонкостях управления, но и об организации слаженного взаимодействия: на уровне разработчиков, между командами, с бизнесом.
Когда каждая команда отвечает за конкретный продукт, её участникам важно видеть технологическую картину в целом; четко осознавать в ней свою роль, понимать принципы межкомандных коммуникаций и другие процессы в масштабах компании. Именно здесь роль тех- и тимлидов становится ключевой.
В Сравни мы уже три года проводим встречи лидов. Мероприятия помогают руководителям ИТ-команд фиксировать общий контекст, совместно формировать удобный для всех план действий. И параллельно решать более локальные проблемы — например, связанные с внедрением новых инструментов в командах.
За это время мы подобрали оптимальный для нас формат встреч, а недавний июльский ивент, восьмой по счету, помог закрепить удачные аспекты прошлых LeadHub.
Под катом на примере LeadHub #8 рассказываем, как устроены встречи тимлидов, и какой эффект дают на разных дистанциях. С примерами прорабатываемых на встречах проблем и практическими советами по организации подобных ивентов.
Для начала немного расскажем о том, как эволюционировал формат LeadHub.Основные вехи мы выделили в пару тематических блоков: их можно воспринимать как небольшой роадмап или же предостережение по поводу тех ошибок, которые мы совершили.
Встреча лидов, но кто говорит — и о чем?
Основным (и единственным) спикером первых LeadHub был наш CTO, а сами встречи проходили почти в формате лекции. Руководитель рассказывал об актуальных изменениях в ИТ-ландшафте компании, детали технологической стратегии. Довольно быстро формат решили развернуть в сторону большей вовлеченности ребят: встречи нужны, чтобы общаться всем вместе, верно?
Следующий шаг — сессии вопросов-ответов с CTO: лиды команд озвучивали проблемы, технический директор комментировал, совместно прикидывали план действий. Не хватало главного: акцента на общих проблемах, в решении которых ребята могли бы сплотиться; вместо этого получался скорее разбор локальных историй (что тоже по-своему было полезно).
Решили добавить в LeadHub интерактива — и фактически пришли к формату ретро, совмещенного с брейнштормом. На встречах коллеги обсуждали технологические задачи, рисовали схемы и таблицы, штурмили идеи по оптимизации процессов. Высокая вовлеченность ребят и небольшой, но ощутимый практический результат по итогам встречи убедили нас в необходимости продолжать сходки в подобном формате.
Стали дорабатывать и совершенствовать формат, в том числе на основе отзывов участников, которые собирали в корпоративном мессенджере. Элементы ретро и мозгового штурма сохранились; появилось деление на рабочие группы для решения задач в реальном времени. От обсуждения сугубо технических вопросов перешли к более глобальным и общезначимым процессам вроде найма специалистов, культуры коммуникаций. В целом три последние встречи следовали этой концепции.
Другие важные моменты
Онлайн или оффлайн? Пробовали проводить встречи удалённо, но поддерживать мотивацию и вовлеченность ребят в таком формате оказалось особенно сложно. Многие просто присутствовали на встрече с выключенными камерами и микрофонами. В дальнейшем подобный вариант уже не рассматривали: актуальная концепция LeadHub предполагает много живого взаимодействия. Собираться, к слову, решили строго за пределами офиса, в лофте — просто чтобы разбавить привычную обстановку.
Нужна ли помощь со стороны? Чем насыщеннее становилась программа встреч, тем больше росла вовлечённость ребят; поначалу процесс выглядел несколько хаотично. Поэтому мы обеспечили модерацию встреч: фасилитатор помогает ребятам не отклоняться от повестки даже в пылу дискуссий.
Состав участников. На сходки зовём всех технических руководителей: тим- и техлидов, архитекторов. Стараемся по максимуму приглашать коллег из регионов — заранее договариваемся, организуем трансфер. Лайфхак по мотивам нашего опыта: когда в проведении встреч заинтересовано высшее техническое руководство, собирать нужных спецов не составляет большого труда. С популяризацией идеи LeadHub в компании нам сильно помог CTO. Во встречах участвуют порядка 50 лидов, включая всех ключевых технических людей.
Как найти баланс тем? Когда на сходках мы разбирали локальные вопросы команд, то казалось, что упускаем масштаб. Все-таки быть ИТ-лидом — это не только про разработку, но и во многом про менеджмент, оптимизацию значимых процессов. В итоге нащупали баланс: сделали акцент на процессах, индивидуальных и командных, а «технику» обсуждаем в том случае, если проблема затрагивает несколько команд (либо если конкретный опыт можно экстраполировать на разные юниты). С учётом этого скорректировали частоту проведения встреч: раньше собирались ежеквартально, теперь — раз в полгода: за это время, как правило, появляются новые важные темы для обсуждения.
Какой ожидать профит. Развитие лидерства — плавный, поступательный процесс, который сложно с первого раза запустить в полную силу. Поэтому даже небольшой эффект от первых встреч — уже хорошо (например, разобрались со спецификой внедрения нового инструмента или зафиксировали договоренности между командами). Со временем мы пришли к более значимым результатам: например, на прошлой, седьмой встрече, зафиксировали, что улучшение сетевой инфраструктуры позволило сэкономить компании более 1.5 млн рублей в месяц — именно после детальной проработки проблемы в рамках LeadHub.
Теперь посмотрим на LeadHub более пристально: что происходит на наших встречах и о чём там ведется речь?
Leadhub #8: как работает фреймворк для встречи лидов
Центральной темой восьмой сходки стал, на первый взгляд, простой вопрос: а кто вообще такой тимлид? Решили сформулировать для себя специфику этой роли, выделить её ключевые компетенции, конкретные навыки. О прикладном значении выбора такой темы поговорим чуть ниже.
В первой же половине встречи ребята выступили с презентациями: о том, что удалось улучшить за полгода. На зимнем LeadHub мы зафиксировали ряд проблем, путем голосования выделили самые важные из них, взяли в проработку. Настало время поделиться результатами.
Многие из рассмотренных вопросов касались процессов унификации, стандартизации, оптимизации. Связано это со стремительным ростом компании: еще пару лет назад в Сравни было около 100 технических сотрудников, а сегодня — более 300. Каждая из 39 команд сосредоточена на своей специализации: например, команда из трех бэков и четырех фронтов занимается только продуктом ОСАГО (продажа электронных полисов).
С одной стороны, во внутренней базе знаний описано, кто что делает и к кому по каким вопросам можно обратиться; в корпоративном мессенджере есть общие каналы, чаты команд и направлений. С другой стороны, несмотря на это случаются и пробелы в коммуникации, и несогласованность в процессах: неизбежный сайд-эффект бурного развития.
Итак, вот примеры некоторых проблем и способы их решения, представленные ребятами на июльской сходке.
-
Проблемы взаимодействия: отсутствие единого информационного поля и закрепленного формата общения. Тимлид второй линии поддержки Сравни, Владислав Машталер, рассказал о том, как мы стараемся сделать коммуникации в технических командах более прозрачными и эффективными.
Примеры решений:
Назначили ответственных за коммуникации в командах — лидов, прописали их зону ответственности в этом вопросе (и по внутреннему, и по межкомандному взаимодействию).
Начали глобальную переработку Confluence: централизуем и унифицируем базу знаний.
Запустили чат-бот опросник в корпоративном мессенджере. С его помощью запускаем общие опросы, которые сложно игнорировать: бот уведомляет сотрудника до тех пор, пока тот не пройдет нужный опрос или не отреагирует на сообщение, где его тегнули.
-
Шаринг экспертизы в командах. Чтобы прицельно улучшить этот процесс, с помощью опроса изучили контекст: где ребята обычно ищут информацию (топ-3: коллеги, stackoverflow, github), как именно выбирают технологии для решения той или иной задачи, как происходит обмен информацией внутри команды, сколько времени занимает её поиск. В итоге зафиксировали идеи по улучшению обмена знаниями, которые постепенно воплощаем. О них рассказал тимлид нашей команды EdTech Максим Постников.
Примеры решений:
Улучшаем структурирование документации.
Укрепляем культуру внутренних выступлений, внедряем систему мотивации для докладчиков. В ближайшее время запускаем сервис с накопительной системой для сотрудников: за выступления, написание статей на Хабр и участие в других форматах донесения своей экспертизы коллеги смогут получать бонусы и тратить их в нашем внутреннем магазине.
Развиваем новые форматы шаринга техническими знаниями (пример: внутренний новостной ИТ-дайджест в почте).
-
Отсутствие общих и понятных продуктовых логов. В компании много сервисных команд, которые так или иначе работают с продуктовыми логами. Но поскольку сами логи и точки их снятия — не стандартизованные, работа с ними представляет собой неупорядоченный флоу без возможности переиспользовать все логи. С этим связаны и другие проблемы: например, согласно законодательству РФ мы должны хранить данные о пользователях и их взаимодействиях не менее 3 лет, а хранить такой огромный массив — дорого.
О постепенном устранении проблемы рассказал Павел Арланов, наш руководитель по ИБ.
Примеры решений:
Согласовали с ФОИВ конкретный состав данных, который нам требуется хранить и передавать при необходимости.
Сделали общую концептуальную схему лога.
Зафиксировали в командах подход к работе с логами и методы хранения.
-
Проблемы процессных релизов. Решили исправить ряд негативных факторов: в том числе отсутствие стандартов версионирования, релизной политики и стабильного окружения. Какие шаги для этого уже сделаны, рассказал лидер нашей мобильной команды Денис Сизый.
Примеры решений:
Внедрили вспомогательные инструменты. Настроили механизм rollouts в ARGO, создали инструкцию создания стабильного DEV, добавили механизм проставки тега в релиз, который виден в ревизии ARGO.
Прописали план релизного цикла: детализировали задачи по каждому из пяти дней цикла.
-
Вязкость. Эта часть презентации была посвящена преимущественно проблемам внедрения новых инструментов. Речь и о сложностях с самим процессом переезда на новые инструменты, и о сопутствующем затягивании сроков, и о ситуациях, когда ребята в командах не понимали смысл внедрения тех или иных инструментов, их сути и значения. Кое-что уже поправили: промежуточными результатами поделился Владимир Верещагин, заместитель CTO Сравни.
Примеры решений:
Ввели голосование по внедрению новых инструментов.
Сделали понятный чек-лист по их внедрению.
При внедрении новых инструментов начали проводить тех-демо.
Установили автоматические напоминания по срокам внедрения.
-
Отсутствие культуры UNIT-тестов в компании. Процесс внедрения UNIT-тестов не стандартизирован, применение разных подходов привносит элемент бесконтрольности. Об улучшениях в этой области рассказал Ахмед Ахмедов, заместитель CTO Сравни.
Примеры решений:
Внедрили инструмент оценки покрытия: добавили в тестовом режиме библиотеку, определяющую покрытие кода в одном репозитории каждого стека.
Отладили и развернули инструмент, представляющий собой коллектор отчётов по всем репозиториям компании.
-
Нехватка и текучка кадров. Не все лиды одинаково хорошо умеют руководить сотрудниками, в том числе новыми. А ещё лидам зачастую не хватает контекста по процессам рекрутинга: например, своевременного поступления информации об открытии новых вакансий. Что уже улучшили по этому направлению — рассказал Василий Бяхов, заместитель CTO Сравни.
Примеры решений:
Провели большой опрос лидов, по итогам которого выявлены узкие места в управлении сотрудниками — начали их прорабатывать.
Повышаем информированность лидов о вакансиях и различных аспектах найма — за счет укрепления их коммуникации с HR People Partner.
Все это — только часть тем и далеко не все озвученные выводы нашего ретро (помимо готовых результатов, много обсуждались и планы по дальнейшему развитию); всего выступления ребят заняли полтора часа. После этого был часовой перерыв на обед, и мы перешли к основной части программы.
Собираем вместе лидов — но кто же такой тимлид?
В практическом смысле мы решили раскрыть тему нашей встречи так: составить по её итогам матрицу компетенций тимлида, зафиксировать в компании и использовать для оптимизации процессов. Какой эффект планировали получить от такой матрицы?
Сделать треки развития специалистов более прозрачными. С помощью матрицы любой разработчик, стремящийся стать тимлидом, будет понимать, какие именно навыки и компетенции ему нужно укреплять для развития в профессии. То же самое касается техлидства: матрица в целом заточена под лидерские компетенции в ИТ.
Упростить онбординг. В Сравни мы стремимся выращивать лидов самостоятельно, но разумеется, не исключены случаи, когда хороший лид может прийти со стороны. Матрица позволит новому специалисту быстрее получить представление об ожиданиях к его роли и вникнуть в процесс.
Создание резерва тимлидов. Косвенно это ожидание связано с первым пунктом: собрать пул потенциальных тимлидов (из числа разработчиков, кто к этому стремится) для подключения к новым продуктам/направлениям в компании.
Наконец, матрица была бы полезна самим лидам как наглядное напоминание — о просторе для профессионального развития, который, безусловно, всегда есть. Особенно в случае с лидами, совмещающими в себе две довольно разные роли: техническую и управленческую.
Например, в бэклоге тимлида в Сравни разработка своими руками — это порядка 10-20% от всех задач. Остальное — people-менеджмент, задачи на стыке разработки и бизнеса, исследование новых инструментов и проработка архитектурных решений. Чтобы команда достигала целей по метрикам, а внутри у ребят было все нормально с мотивацией, важно давать лидам навыки и инструменты для работы с командой по разным направлениям — от коммуникации до стратегического планирования.
Но что прокачивать приоритетно? Именно это — основные компетенции тимлида — ребята формулировали во время брейншторма. Обсуждение происходило по технологии «мировое кафе». Участники поделились на несколько столов, у каждого стола было два лидера — своего рода «держатели знания», а остальные участники перемещались между столами и дополняли, развивали и корректировали идеи своих предшественников. При этом, конечно, учитывали специфику компании: цель — не собрать портрет идеального тимлида в вакууме, а получить представление о том, что важно ему в прикладном смысле, для решения реальных задач бизнеса.
В результате каждый стол проработал по две компетенции — и мы получили базовое представление о содержании будущей матрицы. Выделили следующее: технические навыки, управление командой, инициативность, навыки коммуникации, адаптивность, умение грамотно ставить задачи, понимание бизнеса, самостоятельность, погруженность во внешние коммуникации.
Следующий шаг — проработать в рамках каждой компетенции свой набор навыков. Этим лиды со своими командами занимаются уже сейчас (вдобавок к решению задач, которые были обозначенных на предыдущих встречах и пока не выполнены в полной мере). Когда наша матрица будет полностью сформирована, планируем провести оценку заложенных в неё навыков у наших лидов — и помогать с их развитием. Результаты представим уже на следующих встречах LeadHub.
Пока же предлагаем посмотреть небольшое отчётное видео с LeadHub #8: о том, как прошел ивент, буквально в пяти минутах.
Что дальше?
В случае с воспитанием технологического лидерства важно понимать, что это процесс, который невозможно уместить в рамки точечных встреч (даже если проводить их очень часто). На LeadHub мы, по сути, отмечаем достигнутое и фиксируем планы. А дальше предстоит большая работа: следовать договоренностям, разнести информацию по командам, учитывать все то, что обсудили, в решении ежедневных задач. Полгода до следующего LeadHub — время, когда нам нужно приложить максимальные усилия для устранения ранее отмеченных проблем. А о том, в какой степени это получится и куда мы двинемся дальше, расскажем зимой — уже по мотивам девятой встречи LeadHub.