Управление X командами

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

Мне повезло исполнять роль строгого коменданта в этом процессе.

Эта история вообще не о том, «как надо».
О подходах и методах управления написано огромное количество материалов разными умными дяденьками и чуть меньше — умными тётеньками. Здесь речь пойдет о том, как прийти к выводу, что «нужно именно так», если не хочется повторять этот увлекательный путь самурая самостоятельно.

До нашей эры

Допустим, x = 1

«Я шерстяной волчара.
Боже, как же я хорош,
как мощны мои лапищи!»

Вы — молодой тимлид, который с нуля построил мощную команду, лично собеседовали почти каждого её участника, и теперь эта команда — настоящая семья. Не в том пошлом смысле, когда все приветствуют друг друга дежурным «доброе утро, коллеги», толпой идут на двухчасовые обеды или имитируют бурную деятельность на совещаниях, чтобы после шести вечера просто встать, обнулиться и уйти прочь.

У вас команда единомышленников, идеально совпадающих по темпераменту и видению продукта. Ваши приложения — «лучшие в мире», а конкуренты «закроются через месяц». Команда распределённая, но вы часто встречаетесь, ездите по городам друг к другу в гости, устраиваете вечеринки и вместе отдыхаете.

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

Исправлять тут нечего, но мы запомним это место, чтобы вернуться к нему позже. Пока — у вас команда мечты!

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

«В награду» вам поручают руководство ещё одной командой.

Допустим, x = 2

— Продакт-менеджер должен сам тебя выбрать.
— Как я узнаю, что он меня выбрал?
— Он захочет тебя убить.

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

Здесь царит атмосфера закрытости: утренние планёрки с выключенными камерами длятся по полтора часа и превращаются в монологи продакт-менеджера или тимлида, щедро приправленные токсичными комментариями.

На бумаге всё прекрасно, но при внимательном изучении становится понятно, что тимлид ведёт искусственно подогнанные метрики в собственной электронной таблице, итоги ретро хоронятся под доской какого-то внешнего сервиса, на демо постоянно показывают наброски макетов или фрагменты электронных таблиц типа «было багов / стало багов», никто точно не представляет полный UX первой версии продукта, хотя команда уверенно переписывает его на вторую — «самую более лучшую».
Актуальной документации вообще нет.

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

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

К вам приходит понимание, что иногда одним тимлидом команду не починить, нужен катализатор. Грамотный баланс между продуктовым и техническим менеджментом является базой для успешной команды разработки и совершенно неважен уровень компетенций остальных её участников. Этого нельзя описать никакими правилами, квотами или метриками — достичь можно лишь поиском компромиссов, ну и качественной словесной перепалкой, конечно.

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

Очередной уровень успешно пройден, запуск команды произведён:

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

«В награду» вам поручают руководство ещё одной командой.

Допустим, x = 3

— Я знаю кунг-фу!
— Покажи мне.

Третья команда слывёт «непрозрачной и нестандартной, с множеством контекстов». Она делает что-то очень много, очень быстро, очень сложно, но нигде не отсвечивает в метриках. Единственная точка входа — продакт-менеджер.

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

Вы погружаетесь в процессы и картина проясняется.

Команда сплочённая, весёлая и отважная, как «морские котики» из боевиков. Несмотря на все трудности, они работают слаженно, иногда даже получается эффективно, поддерживают друг друга и стремятся к общей цели.

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

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

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

В качестве терапии предпринимаются следующие шаги:

• Вы проводите встречи один-на-один с продакт-менеджером, чтобы понять его ожидания и боли, а также попытаться спланировать спринт вместе.
• Чётко обозначаете И. О. лида, что он больше не «И. О.», а настоящий взрослый тимлид, разъясняете его новые полномочия и ожидания от роли. Проговариваете точки роста и назначаете регулярные встречи один-на-один.
• Поднимаете вопрос о синхронизации документации из головы тимлида с корпоративной вики, чтобы уменьшить риск потери знаний (bus-factor).
• Проводите сессию с командой, чтобы объяснить, что не все задачи нужно брать сразу и героически не успевать делать.
• Пресекаете постановку задач команде вне трекера.

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

«В награду» вам поручают руководство... всеми командами.

Наша эра

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

Но пока вы нянчились с младшими, старшие начали покуривать за гаражами: сроки поплыли, релизы переносились и откатывались, а задачи стали набираться в спринт по принципу «потому что можем».
Фокус на продукте был потерян.

Допустим, x = много

«Придёт время и жизнь покажет,
что время пришло. Ауф!»

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

В итоге получаем:

• Разные команды с разным составом: десять команд с разным количеством человек и уровнем компетенций, что усложняет управление и координацию.
• Разная отчётность: каждая команда использует свои инструменты для отчётности — трекер, BI-инструменты, Excel. Это делает сбор и анализ данных крайне затруднительным.
• Разные инструменты планирования: планирование в основном ведётся в Excel с ручной разметкой, причём формат у каждого продакт-менеджера свой. Это приводит к путанице и затрудняет сравнение результатов.
• Отсутствие инструментов контроля: инструменты верхнеуровневого контроля за отделом либо отсутствуют, либо суммируют количество человекочасов, картофель и силу ветра. Это делает невозможным объективную оценку работы отдела.
• Разные методологии: у кого-то scrum, у кого-то kanban, у кого-то «чертоги разума тимлида».
• Разные спринты: спринты у каждой команды имеют разную длительность и начинаются в разное время, что затрудняет синхронизацию и координацию работы.
• Нечёткие цели спринтов: цели спринтов ставятся «от балды» или в формате «делай хорошо, а плохо не делай», что не даёт чёткого понимания, что именно нужно делать и как измерить успех.
• Разные статусы задач: у каждой команды свои статусы на доске, что затрудняет понимание текущего состояния задач и их приоритетов.
• Тестирование и дизайн-приёмка: проводятся когда и как повезёт, что приводит к задержкам и снижению качества.

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

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

А для начала всё сломаем.

Пересборка команд

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

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

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

Унификация процессов

Первым шагом к унификации процессов во всех командах стало введение scrum и двухнедельных спринтов с фиксированным графиком на год. Это позволило синхронизировать работу и избежать путаницы.

Помимо продуктовых спринтов были введены технические, на которые выделяется определённое количество ресурсов от каждой команды разработки. Разработчики и QA «уходят» в функциональные команды и занимаются техдолгом, инцидентами и проектными задачами.

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

Для тимлида исчезла необходимость постоянно договариваться и расставлять приоритеты своего технического долга совместно с другими командами, а продакт-менеджер теперь не должен закладывать в планы фиксированную долю ресурсов на погашение технического долга — отправил сотрудника на технический спринт, и грузи остальных по полной. Главное, что ни один из них теперь не сможет перетянуть одеяло на свою сторону — оно прибито гвоздями.

Унификация инструментов

Итоговый результат выглядит следующим образом:

• вся переписка ведётся в рабочем мессенджере, обсуждения — в тредах,
• знания и документацию храним в wiki,
• задачи ведём в трекере,
• ресурсы планируем на диаграмме Ганта,
• продвижение по спринту контролируем по доске,
• метрики смотрим в BI-дашборде,
• структуру организации, индивидуальные планы развития и договорённости фиксируем в HR-системе
• и так далее

Эксклюзива не будет, всё как у всех, но какой же болью давался этот список.

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

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

Наблюдаемость, прозрачность, аналитика

Летят Васлий Иванович и Петька на аэроплане.
Васлий Иванович: — Петька, приборы!?
Петька: — Сорок два!
Васлий Иванович: — Что сорок два?
Петька: — А что приборы?

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

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

Модель зрелости команды и TMI

Нам нужно как-то оцифровать, насколько эффективно команда работает вместе, какие у нее сильные и слабые стороны, и какие шаги необходимо предпринять для улучшения её работы. Для этого построим модель зрелости команды (Team Maturity Model).

Для калибровки возьмём лучшую команду и сравним её с самой слабой. Чтобы выбор кандидатов был более объективным, обсудим решение с двумя руководителями: продуктовым и техническим.

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

Теперь добавляем к сравнению третью пока несуществующую — команду сына маминой подруги, у которой в каждом слое придумаем ещё по паре ступеней, которые мы ждём от идеальной команды. Идеальной, именно в наших реалиях, не гонимся за ФИНтехом, БИГтехом и прочим -техом на три буквы — у них нет души.

Сова готова. Сейчас будем её натягивать на глобус: берём каждую команду и просто суммируем вес достигнутых ступеней по модели — получаем индекс зрелости команды (Team Maturity Index, TMI).

Попросим тимлида и/или продакт-менеджера оценить свою команду, то же самое просим сделать функциональных руководителей (фронтенд, бэкенд, мобильная разработка, тестирование) для всех команд, и, на правах творца, выдадим ещё ряд собственных оценок. Теперь нам остаётся только взять среднее значение по каждой ступени, в спорных случаях отдавая предпочтение оценке руководителя, который больше погружён в контекст.

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

А теперь драма. Берём TMI нашей лучшей команды и делаем его минимальным порогом, который должна преодолеть каждая команда, чтобы считаться полноценной, самостоятельной единицей. Тимлиды и продакт-менеджеры следят за поддержанием и регулярным обновлением этого показателя — выполнение этой задачи закреплено в их личных планах развития и влияет на оценку профессиональных компетенций внутри компании. Тимлид команды с наилучшим показателем TMI назначается куратором и помогает остальным лидам достигнуть минимального порога.

Оценка эффективности команды

Команда достигает необходимого уровня TMI, и мы можем отправлять её в свободное плавание. Осталось только определиться, как именно будем оценивать, хорошо ли она «плывёт», точно ли держит верный курс и все ли одинаково усердно гребут. Морскому делу традиционно учимся за границей: нагуглив несколько фреймворков оценки эффективности — SPACE, DevEx, DORA, — начинаем их сравнивать.

В каждом из них учитываются разные стороны деятельности команд. Фокус варьируется от чётких измеримых метрик в технических аспектах (DORA) или от комплексной оценки командного взаимодействия (SPACE) до индивидуального ощущения разработчика (DevEx). Начинает казаться, что оптимальным вариантом для всесторонней оценки работы команды будет смешать-но-не-взбалтывать все три инструмента вместе, но это уже сделали за нас — читаем про DX Core 4.

Вот что пишут авторы:

«<...> мы разработали DX Core 4 — единый подход к измерению продуктивности разработчиков, который объединяет DORA, SPACE и DevEx. DX Core 4 предоставляет единый, практичный и сбалансированный фреймворк, который поддерживает принятие решений на всех уровнях организации. <...> Этот фреймворк был протестирован и усовершенствован более чем в 300 организациях, помогая компаниям достигать таких результатов, как рост эффективности на 3-12% в решении инженерных задач и увеличение на 14% времени, выделяемого на разработку нового функционала отделом R&D».

Продано!

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

• Скорость: измеряет, насколько быстро команды доставляют готовый код. Ключевые метрики включают время выполнения изменений (Lead Time for Changes), частоту деплоя (Deployment Frequency) и количество пул-реквестов на инженера (PRs per Engineer), что даёт представление о пропускной способности рабочего процесса. Фреймворк подчёркивает, что эти метрики не следует использовать для оценки индивидуальной производительности.
• Эффективность: оценивает, насколько хорошо процессы разработки поддерживают инженеров. Основной метрикой является индекс ощущений разработчика (Developer Experience Index, DXI), показатель, основанный на данных опросов, которые могут оценивать более 40 факторов, связанных со сложностями в рабочем процессе, удовлетворённостью и эффективностью.
• Качество: оценивает стабильность и надёжность программного обеспечения в боевом окружении. Основные метрики — частота инцидентов при релизах (Change Failure Rate) и время восстановления после неудачного релиза (Failed Deployment Recovery Time).
• Влияние: измеряет бизнес-ценность, создаваемую инженерной работой. Основной метрикой является процент времени, затрачиваемого на новые пользовательские ценности (Percentage of Time Spent on New Capabilities), который отслеживает долю усилий инженеров, направленных на создание новых функций по сравнению с обслуживанием или техническим долгом.

Внедрение Core 4 требует интеграции данных из различных источников, включая репозитории, инструменты управления проектами, CI/CD-пайплайны, системы управления инцидентами и платформы для опросов.

Склеить полученные лоскуты в большой ковёр помогут ETL-процессы, а облачные BI-системы позволят быстро и красиво визуализировать данные на графиках и диаграммах.

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

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

Вердикт: переходим на личности!

Уровни компетенций и оценка эффективности сотрудников

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

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

Теперь одним глазом смотрим в прогноз по ФОТ компании, а вторым — на «вилку», которую предлагают карьерные сайты для каждого уровня компетенций. Формируем зарплатную шкалу, которая плюс-минус бьётся с текущими окладами в отделе и предложениями конкурентов. Здесь сразу становится видно, чей оклад не соответствует рынку и/или размаху вашего бизнеса, соответственно, уже понятно, в каком ключе вести диалог на встрече по формированию ФОТ и при оценке эффективности сотрудника.

Третий шаг — немного разбавим наши категории промежуточными и размажем между ними с небольшим нахлёстом (~5–10 %) вилки зарплат, чтобы ускорить продвижение сотрудников по уровням и избежать резкого роста фонда оплаты труда после каждой переоценки.

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

Получаем прозрачную структуру категорий с привязкой к окладам, чёткий план профессионального развития для каждого сотрудника и последовательное его совершенствование.

Делегирование, поддержка и мотивация.

И смелые птенчики покидают
своё уютное гнёздышко и впервые
взмывают в небо.

Мы достигаем финального этапа, где уже почти все всё понимают, почти всё работает, как и планировалось, метрики и показатели почти достигли «зелёной зоны». Но как раз самая большая опасность кроется в этом «почти».

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

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

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

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

И вот они мы: довольно быстро и понятными шагами прошли 80% пути, а вот оставшиеся 20% — это «ПОЧТИ», с которым нам предстоит сражаться во главе команды единомышленников вплоть до той самой атаки рептилоидов.

Маршируем в ногу,
Солнце светит в глаз,
Вождь ведёт к успеху
Нас.