Горизонтальные связи и ролевая модель большой команды
Когда отряд теряет бойца — коллега даже в большой команде уходит в отпуск или увольняется, — работа часто буксует или останавливается. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».
Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.
Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1. Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.
Сейчас расскажу, как мне удалось этого добиться.
С чего всё начиналось
В 2020 году я пришла на проект в крупный российский банк. До этого у меня был опыт управления командой максимум из 15 человек. Управляла линейно, иногда переподчиняла джунов синьорам, и это работало. Но на новом проекте у меня в подчинении оказалось сразу более 40 человек, разделённых на четыре команды. Одна из них была проблемной и работала над сложной частью проекта.
Организационно эти команды представляли собой стрим, иногда это называют трайбом или поездом.
Стрим — это конгломерат команд, объединённых одной целью, работающих над одним продуктом или тесно связанными между собой продуктами. Организационная схема стрима была достаточно простой. Команда управления стримом состояла из меня — тимлида тимлидов — и архитектора. Все остальные команды — из участников, в каждой из которых был свой тимлид:
В нашей структуре тимлид отвечает за организационную часть работы и производственный процесс, а техническое лидерство закреплено за архитектором. Иногда выделяют ещё и технического лидера, но у нас его не было — только тимлид и архитектор.
Я столкнулась с legacy-системами и давно сложившимися работающими командами и допустила пару ошибок:
Микроменеджмент
Я опустилась в микроменеджмент самой проблемной команды: ходила на стендапы, включалась во все проблемы и очень скоро поняла, что так не работает. Микроменеджмент допустим только на кратком отрезке времени, например, при критичной ситуации на проекте.
Потом ситуацию нужно отпустить, работу команды перестроить, а тимлида научить справляться с трудностями самостоятельно.
Поиск идеальных тимлидов
Я пыталась искать идеальных тимлидов на рынке, но со временем стало очевидно, что иногда проще дотянуть и переучить тех, кто есть в команде, чем тратить время на бесплодный длительный поиск.
Проблемы тимлидов, с которыми я столкнулась
Расскажу немного о тех проблемах тимлидов, с которыми я столкнулась.
Тимлид не из IT
Сейчас очень модная тема — «Войти в IT». Мы часто сталкиваемся с людьми, которые переквалифицируются и приходят из других сфер.
У нас была команда с жёстким legacy, и никто с опытом Java-разработки не хотел идти в неё тимлидить.
Для понимания масштаба проблемы: там всё работало на уже не поддерживавшемся Internet Explorer, был спагетти-код. Часть логики совершенно нелогичным образом была зашита во фронте. А монолит был настолько монолитный, что на то, чтобы донести до прода фичу, связанную со сценарным анализом, ушло девять месяцев.
Мы взяли на роль тимлида человека без опыта в IT. Он пришёл к нам из строительства: чёткий, исполнительный, с опытом оперирования в крупных корпоративных структурах, но совершенно ничего не понимавший в наших технологиях. Адаптировали мы его достаточно стандартно: с помощью курсов, литературы, консультаций от ведущих разработчиков и DevOps-инженеров. Это помогло: тимлид и команда заговорили на одном языке. Получилось быстрее переучить его, чем продолжать искать ещё кого-то.
Новоиспечённому тимлиду важно было понимать производственный процесс, знать, какие точки проходит релиз, какую документацию готовить. Всё это — доступные знания даже для человека не из ИТ. Но он не понимал, например, почему нужно закладывать больше времени, чтобы мигрировать с базы данных Oracle на Exadata, что это не просто копирование и функции могут работать по-другому. Этими вопросами занимались технические специалисты и архитектор. Зато этот тимлид был великолепен, когда нужно было легально затащить софт в контур банка или понять, куда обращаться, чтобы получить обезличенные данные.
В этой конкретной команде была важнее человеческая зрелость, нежели техническая.
Тимлид-новичок
Второй случай был сложнее. Один опытный и технически грамотный человек очень хотел тимлидить, но совершенно не имел опыта управления командой.
Когда человек начинает руководить, у него обычно возникает три вида проблем:
Делегирование.
Ведение переговоров.
Авторитет в команде.
Проблем с авторитетом у него не возникло, так как он сам был выходцем из этой команды, его знали и уважали. Но он столкнулся с трудностями ведения переговоров со смежными подразделениями и проблемой делегирования. Переговоры были в основном с заказчиком, и порой тимлид соглашался на те его требования, которые противоречили здравому смыслу с технической точки зрения. К счастью, он сам понимал свои проблемы и обращался за помощью.
Чтение книг и статей здесь не помогало.
А мне не хотелось снова опускаться в микроменеджмент команды, потому что от этого я только что ушла. Также я не хотела подрывать авторитет тимлида. Мы выбрали путь коучинговой практики: он приходил, мы обсуждали проблему и вырабатывали решение, он уходил и действовал, потом возвращался, и так повторялось много раз. Здесь было важно не навязывать ему моё собственное решение, а позволить прийти к выводам самостоятельно. Сейчас это называют коучинговым стилем управления, и в данном случае это помогло и сработало.
Стрим увеличивался
Стрим масштабировался и вырос более чем в три раза за два года. Все тимлиды справлялись прекрасно, мы уже наладили работу самой проблемной команды. Это позволило нам отказаться от подрядчика на fixprice и сэкономить 26% бюджета проекта. Но команд становилось всё больше (их было уже более десяти), а структура оставалась всё такой же линейной, и управляемость начала падать.
Нормой управляемости считается семь команд, и по моим личным ощущениям это так и есть. Здесь мы её уже превысили.
Более того, мы работали во фреймворке, построенном на основе Scaled Agile Framework (SAFe) или масштабированного Agile. Согласно ему в наших командах стали появляться новые роли. На уровне стрима, а потом и на уровне команд у нас появились владельцы продуктов — продакты:
В нашей структуре владельцы продукта — это люди, которые отвечают за стратегию развития продукта и приоритизацию бэклога. То есть тимлид — это про оперативное управление, а владелец продукта — про стратегическое.
Итак, коммуникации усложнялись, появлялись новые роли и команды. Как вариант решения проблемы можно было разделить стрим на два или выделить дополнительные уровни иерархии, углубив её.
Но эти способы нам не подходили, так как увеличение численности команд было временным — только на период реализации проектов. Если бы мы набрали дополнительный управленческий персонал, то потом просто не знали бы, что с ним делать. И тогда я решила пойти путём выделения так называемых функций и выстраивания на их основе горизонтальных связей. Так появились «замы».
Чтобы понять, какие функции выделить, нужно подробно рассмотреть одну команду и роли, которые в ней существуют:
В моём случае, кроме тимлида, владельца продукта и архитектора, были нужны аналитики, скрам-мастера и релиз-менеджеры. Выбор ролей зависит от специфики продукта, например, в другой команде могут быть важны роли UI/UX-дизайнера или технического лида.
Горизонтальные связи
Отталкиваясь от ролей, построим горизонтальные связи: в команду управления стримом добавим главного релиз-менеджера стрима и главного аналитика. Они и стали моими замами с конкретной зоной ответственности. Главный релиз-менеджер дирижирует всеми релизами стрима и строит единый план-график релизов. Аналитик стрима находится в курсе всех его функциональных взаимосвязей, систем и следит, чтобы они не пересекались, не противоречили друг другу и не дублировались.
Добавим в каждую команду наместника релиз-менеджера стрима. Роль релиз-менеджера обычно совмещается с какой-нибудь ещё. Релиз-менеджеры команд активно взаимодействуют между собой и с релиз-менеджером стрима, строя единый план-график релизов.
Таким образом, только за счёт организационного взаимодействия менеджеров релизов мы снизили Time to Market в устоявшихся командах с шести месяцев до двух–четырёх недель.
Мы выстроили план-график релизов определённым образом: в один момент времени шёл только один важный релиз, и релиз-менеджер стрима уделял ему максимальное внимание.
Плюс мы брали какие-то документы в технический долг.
По такому же принципу мы добавили в каждую команду аналитиков:
Здесь я употребляю просто термин «аналитик», но конкретно в моём случае аналитик совмещал в себе функции бизнес-аналитика и системного аналитика. Функцию аналитика данных исполняли разработчики BI-отчётности.
Главный аналитик не руководил остальными аналитиками. У них скорее образовалось мини-сообщество с постоянным обменом информацией.
Именно за счёт коммуникации между собой аналитикам удалось выработать решение, которое позволило перенести большую часть отчётности стрима на гомогенный стек, что, в свою очередь, позволило добиться ещё большей взаимозаменяемости разработчиков BI.
Финальным штрихом стало добавление в каждую команду скрам-мастера. Здесь схема немного отличалась от того, как это было с релиз-менеджерами и аналитиками:
Мы выбрали самого матёрого, опытного скрам-мастера. Он не покидал своей команды, оставался в ней и исполнял свою функцию. Но также он коучил и помогал скрам-мастерам остальных команд. В нашей системе скрам-мастер — это человек, служащий команде и устраняющий препятствия на её пути, Servant Leader, или лидер-слуга.
Во многих компаниях — негативное отношение к скрам-мастерам. Иногда участники команд не понимают, что это за роль и зачем она нужна. По моему мнению, скрам-мастер может заслужить доверие команды и влиться в неё, если умеет помочь каждому.
Приведу один пример. Команда была частично в Москве, частично — в регионах. Для проведения ретро московская часть команды собиралась в офисе. Результаты ретро фиксировались физически на доске. Те, кто был в регионах, доску не видели, но стеснялись сказать. Скрам-мастер поняла это и даже поспорила с тимлидом, но заставила перенести доску в онлайн. Она сделала так, чтобы каждому в команде было комфортно. Это сыграло в её пользу.
Ролевая модель
Итак, мы построили горизонтальные связи. Но чтобы это работало, нужен ещё один инструмент — ролевая модель. Необходимо чётко определить обязанности каждой роли. Они не должны пересекаться, и их нужно донести до каждого, чтобы избежать конфликтов:
В моём случае больше всего конфликтов было между тремя ролями: владельцем продукта, тимлидом и скрам-мастером. Все они — лидирующие, близки друг к другу и призваны работать вместе, сообща. Но на деле возникали конфликты.
В качестве примера: у меня был один активный продакт, который включался в оперативное управление командой. Но часто делал это в ущерб своим продуктовым функциям, таким, как, CustDev, или пользовательское интервью. Ещё был тимлид, временно исполнявший обязанности архитектора команды. В какой-то момент ему тоже стало сложно отделять обязанности тимлида от обязанностей архитектора.
С такими людьми нужно работать индивидуально: объяснять, что они делают неправильно, и указывать им на ролевую модель. Важно помнить, что продакт — это про стратегию, тимлид — про оперативное управление, а скрам-мастер — душа команды, он хранит её атмосферу и ритуалы.
Итак, в результате построения горизонтальных связей и ролевой модели мы перешли от полностью плоской структуры стрима к структуре с выделенными функциями и институту замов по этим функциям. Лидеры некоторых функций находятся на уровне самого стрима (релиз-менеджер стрима, аналитик стрима), в то время как лидеры других остаются у себя в командах (главный скрам-мастер).
Такая модель дала неоспоримые преимущества. Во-первых, мне самой уже не нужно было участвовать в обучении и коучинге некоторых ролей: этим занялись конкретные замы. Во-вторых, сама эта структура намекает, кого оставить за себя на время отпуска того или иного участника стрима.
Центры компетенции
Чтобы усилить эффект от ролевой модели и горизонтальных связей, можно создавать центры технической компетенции локально у себя в команде. Это тоже вид горизонтальных связей, только их цель — не совершение производственного процесса, а обмен опытом, экспертизой и информацией.
Здесь важно отталкиваться от стека. В моём случае это была «сборная солянка» из приложений Oracle, базы данных на SAP и собственных разработок на Java. Разработчики были размазаны по разным командам.
Важно найти в каждом направлении самого активного разработчика и поручить ему устанавливать взаимосвязи с остальными.
Конечно, есть гильдии и сообщества большого холдинга, но они обычно затрагивают только популярные направления разработки. А в случае legacy-стека или стека, подлежащего импортозамещению, помогут локальные центры компетенции в вашей команде. Здесь важно, чтобы каждый разработчик понимал, кто ещё занимается такой же технологией в соседних командах. К сожалению, об этом знают не все. Также часто разработчики — это интроверты: им проще обратиться к кому-то в соседней команде, чем апеллировать к далёкому сообществу большого холдинга.
От создания центров локальной компетенции можно получить выгоду: если у вас когда-нибудь уволится ценный разработчик редкой технологии, то функция не просядет полностью, потому что кто-то в соседней команде будет в курсе дел увольняющегося.
HR-директор одной крупной IT-компании рассказывала мне, что, когда у них уволился Oracle Database-администратор, они не могли заместить эту функцию в течение года. Центры технической компетенции как раз помогают в таких ситуациях.
Мне не везде удалось выстроить эти центры, например, не получилось с Java-разработчиками. Связываю это с тем, что большая их часть была у нас аутстаф: они не хотели сливаться воедино и коннектиться с нашими разработчиками.
Зато хорошо получилось встроить центры с разработчиками BI-отчётности. Помните, что решением аналитиков мы перевели большую часть отчётности на один стек — SAP BW?
Разработчиков этого вида стало достаточно много, они все сидели на одном гомогенном стеке. Настоящее достижение их сообщества — они позволили переучиться и приняли к себе 74-летнего программиста.
Ротация ролей
Чтобы ещё больше усилить эффект взаимозаменяемости, полезно вырастить больше T-shaped-специалистов — людей, исполняющих не только свою производственную роль, но также роль до и после себя в производственном процессе. Чем меньше команда, тем больше нужно уделять этому внимания. Если у вас уволится единственный разработчик, то это будет большей проблемой, нежели когда разработчиков трое.
Чтобы этого добиться, поощряйте тимлидов давать задачи участникам команды в бэклог не только по их непосредственной роли. Классический пример — когда разработчик выполняет ещё задачи, связанные с тестированием.
Выгода от этого инструмента — рост взаимозаменяемости, возможности для роста кадров и повышения их мотивации.
Был случай, когда нам с тимлидом эти T-shaped-специалисты очень помогли. У нас было порядка 10 человек на умиравшем стеке Oracle. Со временем они начали увольняться.
Заместить их с рынка мы не могли. Тогда пришли на помощь T-shaped-специалисты: к несложным задачам по разработке подключились аналитики и тестировщики. В какой-то момент это действительно нас спасло.
Таблица «замов»
Когда работа команды устоялась, можно перейти к маленькой, но важной мере — организационно-информационной. Попросите каждого в команде внести в таблицу информацию о том, кто будет замещать его во время отпуска или других неотложных дел.
Если возникнут разногласия, то обсудите их коллективно. Принятые решения опубликуйте в общем доступе, проинформируйте об этом каждого. Со временем люди привыкнут и будут знать, где искать данную информацию.
Основой таблицы «замов» станут построенные нами горизонтальные связи и ролевая модель. Часть ролей будет кросс-командной, например, скрам-мастер или релиз-менеджер.
Сложнее будет с аналитиком: он достаточно специфично привязан к своей команде и её задачам. Но для этого есть главный аналитик стрима: он может временно заместить любого, так как в курсе дел каждого аналитика в каждой команде.
Бэкапирование тимлида
Самое сложное — заместить тимлида. Из-за разной специфики команд тимлиды обычно не могут замещать друг друга, поэтому замена должна быть выращена внутри его собственной команды. Нужно отталкиваться от специфики конкретного человека. Лучше подбирать сотрудника, противоположного по качествам. Например, если тимлид по своим качествам больше управленец, то ему на замену лучше растить технаря.
Также важно исходить из размера команды. Для крупной команды или компании желательно, чтобы даже на замену шёл человек с минимальными управленческими навыками. И наоборот, для небольшой команды подойдёт технарь, и роли будут совмещаться.
Никто не хочет, чтобы его мог заместить на 100% один конкретный человек, и тимлиды — не исключение. У меня был тимлид, который перед уходом в отпуск оставлял на свою замену пять человек, каждого — по своему вопросу. Но этот подход абсолютно нерабочий: слишком много времени пройдёт, пока человек разберётся, где его вопрос в списке и к кому идти.
Тут нужно объяснять тимлиду важность его заменяемости, что он занимает ключевую должность, которую должен замещать только один человек.
Выгода в том, что если что-то произойдёт и тимлид уволится, то будет человек, который сможет хотя бы временно продержаться без него, а возможно, даже пойти на повышение.
Моя замена
Когда я была в отпуске, за меня также всегда оставался один конкретный человек. В нашем фреймворке не предусмотрена ставка заместителя IT-лидера стрима, поэтому важно найти человека, который максимально в курсе всех дел команды и обладает организационными навыками. В моём случае это был архитектор стрима. Здесь важна не роль, а личностные качества конкретного человека.
Никогда не замыкайте все процессы на себя, держите человека, который всегда в курсе дел команды. А если появились новый процесс или активность, то пропустите их через себя и потом передайте правильному участнику команды.
Проверка
Чтобы понять, что миссия по построению горизонтальных связей и ролевой модели удалась, оцените качество руководства в период вашего отсутствия. При правильной передаче дел и организованной работе вам не должны непрестанно названивать. Мне в последний раз не позвонили ни разу, и моё дело продолжает жить без меня. Отпуск и отдых — это важно и нужно! Потому что карьера в IT — это марафон, и нужно беречь силы на длинную дистанцию.
Итоги
Итак, давайте подведём итоги.
Я пришла к выводу, что микроменеджменту нужно предаваться только на кратком промежутке времени, когда у вас действительно критичная ситуация в проекте.
Также я поняла, что не нужно слишком долго искать идеальных людей на рынке. Иногда проще вырастить и доучить тех, что уже есть, чем продолжать бесплодные поиски.
Давайте в заключение ещё раз пройдёмся по семи инструментам для решения проблемы «узких мест» и «критичных звеньев» в кадровом составе большой команды.
Горизонтальные связи и ролевая модель: используйте эти два инструмента, чтобы масштабировать работу команды без дополнительных уровней иерархии на модели «замов» по определённым направлениям.
Создавайте локальные центры технической компетенции и поощряйте людей к общению в них.
Ротируйте кадры и создавайте больше T-shaped-специалистов: правильным людям это даст точку роста и больше мотивации.
Попросите каждого заполнить таблицу «замов»: кто будет замещать его в период отпуска или других неотложных дел.
Объясняйте тимлидам важность их личной заменяемости и заменяемости каждого участника в команде.
Всегда держите заместителя, который наравне с вами будет в курсе всех дел команды.
Эти инструменты позволили моей команде работать с меньшими цейтнотами, более спокойно, с отпусками и отдыхом. Я считаю, что именно за счёт этого в 2022 году текучесть кадров удерживалась на уровне 7%. До этого мы не считали, но я уверена, что она была выше, потому что многие увольнялись. Взаимозаменяемость помогла реже увольняться и меньше выгорать.
Начните использовать эти инструменты прямо сегодня в том порядке, в котором я их перечислила. Вы увидите, что работа команды изменится: станет меньше сбоев и простоев по причине кадровых движений.
