Представьте: у вас упал прод, и никто не знает, как поднять. Проблема в коде, который писал один человек. А он – недоступен. Или вообще уволился. И вот за вашим плечом вырастает фигура начальника. Затем – начальника начальника. Вы выдергиваете на созвон всех: разрабов, девопсов, тестеров и устраиваете мозговой штурм . Кто-то смотрит код, кто-то логи. А решения все нет. Брр….
Меня зовут Иван, я тимлид. Мне важно, чтобы на проекте не было таких «факапов». Я работаю над устойчивостью команды к рискам.
Потеря знаний – серьезный риск. Печально, если никто не знает, как работает фича или как устранить инцидент. Для снижения риска я использую матрицу компетенций конкретного проекта. В матрице нет места сферическим знаниям типа «Асинхронности», «SQL», «Паттернов». Только конкретика: «Делал релиз», «Разработал отчеты».
Меня этот инструмент как-то раз серьезно спас, когда ротировалась половина команды. Bus Factor ≥ 2 позволил не потерять критичные знания на проекте. И хотя мой опыт несёт флёр Капитана Очевидности, я рискну им поделиться. Потому что хочу помочь командам, у которых до сих пор Bus Factor = 1.
Случаи из практики.
Что бывает, когда матрицы нет.
Накануне сдачи проекта мой коллега-разработчик, носитель уникальных знаний, улетел в отпуск. А на приёмо-сдаточных испытаниях всё упало. Разработка лихорадочно искала причину. Менеджмент пытался развлечь иностранных заказчиков русским колоритом: «водка-матрёшка-балалайка» Прилетевшие из-за океана заказчики от водки не отказались, и, скривив физиономии, дали на устранение пару дней.
В конце первого дня прогресс был нулевой. В воздухе запахло разрывом единственного контракта, который «кормил» фирму.
Во второй день в обед (на который никто так и не пошёл) кто-то методом научного тыка смог локализовать баг. К концу дня баг исправили, без тестирования накатили на сервера и позвали заказчика.
Пронесло. Не упало. Так я понял, что «автобусный фактор» – это не просто юмористический термин.
И как хорошо, когда она есть.
На другой работе, когда я стал тимлидом, я «подрезал» матрицу компетенций у более опытного товарища и включил её в свой набор инструментов.
Я использую этот инструмент около шести лет. Делаю это скорее по привычке. Как страховку, за которую платишь, но всерьез не думаешь, что она понадобится.
И тут… внезапно из команды забрали двух разработчиков из четырёх. Взамен наняли двух новых. Если бы каждый разработчик пилил свою часть в одиночку, мы бы лишились половины компетенций.
Благодаря нашей регулярной работе с матрицей по критическим знаниям Bus Factor достигал тройки. Мы не потеряли ничего важного. Разработка не остановилась. Инциденты обрабатывались так же, как раньше. Ни один релиз не был сорван.
О чём пойдёт речь
Матрица компетенций разработчиков – это таблица в формате тепловой карты. В столбцах – люди, в строках – компетенции. На пересечении оценки от нуля до трёх, для наглядности раскрашенные в цвета от красного до зеленого.
Ниже покажу:
Как пользоваться матрицей.
Как её составить.
Как поддерживать.
Дополнительные плюшки
Использование матрицы
Начну с примера.
Перед вами срез компетенций на момент онбординга Сидорова и Васечкина. Они – юные падаваны. Не по знаниям, а по опыту на нашем проекте. Линус Торвальдс, попади он в эту таблицу, тоже был бы весь красным.
Цель работы с матрицей.
Для каждой компетенции улучшить метрику Bus Factor, то есть число джедаев с оценкой не менее двух.
Что делать для достижения цели?
Найти строки с критичными компетенциями и маленьким Bus Factor
В примере выше это:
CI/CD. Если сломается во время отсутствия Петрова, то не будет релизов. Да, многие умеют релизить, но из-за падения CI/CD все встанет.
Обработка заявок. Без Петрова возникнут сложности.
Интеграции. Без Иванова не обойтись.
Предложить новичкам задачи из области проблемных компетенций. Не дать им залипнуть на чем-то одном.
Так они прокачают всего понемногу и выйдут из красной, а затем и из желтой зоны.
В нашем примере падаванам лучше начать с задач по заявкам и по CI/CD под менторством Петрова. А еще пусть покурят интеграции под присмотром Иванова.
Как долго делать?
Пока Bus Factor не станет равным половине людей в команде, но не менее двух. По критичным компетенциям – не менее трёх.
Меньше нельзя: риски. Больше – неоправданные вложения.
Сама по себе метрика не гарантирует устойчивость. Важно, чтобы по каждой компетенции всегда был доступен хотя бы один из разработчиков. Учитывайте это, работая с графиком отпусков и рисками ротации или увольнений.
Предупреждение
Когда дадите падаванам незнакомые им задачи – перфоманс деградирует. Но лучше словить просадку в контролируемой среде, чем в момент ухода старших джедаев в отпуск. И хорошо, если просто в отпуск.
К тому же, падение перфоманса можно сделать прозрачным для бизнеса, введя понятие «Кривая обучения». Скажем, первая задача выполняется со скоростью 50% от идеала, вторая – 75%, третья – 90%. Вначале числа выбираются эмпирически, затем корректируются по мере накопления реальных кейсов обучения.
Да, в реальном мире возможно всякое. Задач по дефицитным компетенциям может и не быть. Джедаи могут не иметь возможности, желания или способности менторить. Бизнес хочет функционал еще вчера.
Я не призываю все бросить и учиться ради обучения. Но я предлагаю переложить на бумагу то, что вы и так уже знаете. Сделать прозрачным для команды и для начальства. Управлять рисками, а не игнорировать их.
Окей, что делать с матрицей плюс-минус понятно. Но сначала её придётся составить, а для этого нужен список компетенций.
Как составить матрицу.
Составление списка компетенций
Теория
У вас в команде наверняка сложилась своя терминология. То, что вы понимаете без уточнений. Выражения, которые вы постоянно используете. Названия того, чем занимается команда. На что прилетают требования и инциденты. Возьмите в качестве компетенций от 20 до 40 терминов, классифицируйте их и поместите в матрицу.
Диапазон 20-40 – эмпирический. Не берите слишком мало, чтобы не упустить что-то критическое. И не берите много, чтобы не словить расфокус. Для вашей команды и вашего проекта оптимум может отличаться. Экспериментируйте.
Хороший пример
Если у вас каждый раз все холодеет от вопроса «А почему это тарифы так странно рассчитываются?», значит, «Расчёт тарифов» – хорошая, годная компетенция. Классифицируем её как критический функционал и заносим в матрицу.
Если вам нужно то одно, то другое закинуть в интеграционный поток, то «Интеграционный сервис» – подходящая компетенция. Классифицируем – и в матрицу.
Если у вас в команде постоянно говорят «Ошибка обновления кэша», «Кэш тормозит», «Кэш ест память», «ууу, это надо кэш править», то «Кэш» – отличная компетенция. Берем его на карандаш. Даже если заказчик не подозревает о его существовании.
Очевидно плохой пример
Нельзя переносить в компетенции навыки и знания.
Предположим, вы делаете приложение для инвесторов. Плохая компетенция: «Знания GRPC». Она слишком абстрактная. Вряд ли на вас упадет инцидент «Вы плохо знаете GRPC». Хорошая компетенция: «Интеграция с Московской биржей». Ведь вполне вероятны инциденты типа «Остановился поток котировок c Московской биржи».
Не очевидно плохой пример
Не стоит вытягивать компетенции из архитектурных схем и другой документации. Даже если документы регулярно актуализируются (что не факт), они описывают прошлое. А вам надо вынести в компетенции сегодняшние и завтрашние боли.
Допустим, мы заведем три компетенции на ядро системы (оно ведь такое важное), и одну – на отчеты. Тогда будут «мёртвые» компетенции, по которым задач нет и не предвидится. Как их тогда качать? Полезность компетенции зависит от востребованности доработок. Лучше завести по компетенции на каждый вид постоянно изменяющихся отчетов, и только одну – на стабильное ядро.
Классификация компетенций
Полученный список я распределяю на группы:
Функционал: опыт разработки конкретных модулей проекта.
Релизы: все, что обеспечивает непрерывную поставку ценности на продуктив.
Поддержка: знания по решению инцидентов и оказанию консультаций.
В каждой группе делю компетенции на критичные (без них проект встанет) и не критичные (все остальные). Классификация нужна, чтобы не было одной большой кучи, с которой непонятно что делать.
Каркас матрицы
Итак, вы составили список компетенций: часто меняющихся и фрустрирующих зон проекта. Напишите наверху список людей, а сбоку – компетенций. Всё, каркас матрицы готов. Теперь его надо наполнить оценками.
Как давать оценки.
Я предлагаю оценивать уровни компетенции по шкале от 0 до 3. Шкала нелинейная: каждый следующий уровень значительно сложнее предыдущих. Но так и задумано.
Чтобы оценивать всех одинаково и непредвзято вводим объективные критерии перехода на следующий уровень. Во избежание вопросов типа «а чего это ты мне единицу влепил?», заранее договариваемся о критериях с командой.
Уровни джедаев:
Ранг: 0 – Бот.
Знания: Отсутствуют, либо они сугубо теоретические. Опыта нет.
Ранг 1: Падаван.
Знания: фрагментарны.
Критерий: Выполнил пару несложных задач под присмотром ментора.
Ранг 2: Джедай
Знания: покрывают практически все, но не везде они достаточно глубоки.
Критерий: Самостоятельно выполнил тройку задач разного уровня сложности.
Ранг 3: Магистр
Знания: Что нужно знает всё. Постиг тонкости устройства мироздания компетенции. Знания его освещают путь.
Критерий: Задач сложных и инцидентов решил десяток
Математическая точность в оценках не нужна. Это грубые числа, влияющие на распределение будущих задач. В конце-концов, оценки ведь на хлеб не намажешь и в карман не положишь. Непредвзятость и регулярность важнее точности.
Актуализация матрицы.
Дальше – регулярно актуализируйте компетенции. Делайте это упражнение раз в 2-4 недели. Или раз в спринт, если работаете по скраму. В идеале введите новый ритуал незадолго перед планированием. На нем просто вспомните (или спросите), кто и что делал, и накиньте им баллы за эти активности. Каждый балл должен быть подтверждён кейсом. Также (к счастью, редко) приходится срезать баллы. Не трогал что-то полгода – минус балл.
Я актуализирую компетенции на общедоступной странице в Confluence. Рекомендую начать с ручного ведения матрицы, чтобы почувствовать инструмент. Для одной команды ручные трудозатраты оправданы. Если же у вас несколько команд, то отчет можно автоматизировать. Указывайте в каждой задаче компетенции, например, в поле «Компоненты». Далее при помощи магии JQL рассчитайте уровень компетенций и через макрос выведите его в Confluence.
После актуализации вы увидите компетенции с минимальным Bus Factor. Учитывайте это знание, когда возникает вопрос «Кому поручить задание?».
Задача со звездочкой: составьте для каждого джедая план развития компетенций. Не для обучения крутым технологиям, а для закрашивания красных квадратиков напротив его фамилии. Звучит как ерунда, но на деле это «пушка-бомба». По моим замерам, с планом и ценными указаниями джедаи погружаются в проект в три раза быстрее.
Тонкий момент: официально выделяйте время менторов на развитие. Не допускайте, чтобы стоял выбор между помощью и своей задачей. Не перегружайте менторов: «Всегда есть два, не больше, не меньше. Мастер и ученик».
Мы пробежались по тому «как» и «что» делать. Давайте подробнее вернемся к вопросам «зачем» и «почему».
Почему ещё стоит использовать матрицу.
Про Bus Factor все понятно. Что ещё можно получить от матрицы?
Даёт быстрые результаты
Поднять силу джедаев с нуля до единицы – легко. Немного осознанного распределения задач, и все в вашей команде «потрогают» наиболее важные детали проекта. И пусть и с оговорками, смогут брать задачи из разных областей.
А когда вы подтяните всех до двойки, у вас будет команда универсалов. Каждый джедай сможет прикрыть другого.
Легко внедрить.
Если один раз напрячься и составить матрицу, то дальше её очень легко актуализировать. А значит, нет когнитивного сопротивления. Нет искушения «забить».
У меня на составление матрицы 4х28 ушло часа четыре. Потом потратил еще пару часов вместе с командой. Надо же всех познакомить с инструментом и провалидировать оценки. А на актуализацию готовой матрицы я трачу минут пятнадцать.
Обеспечивает измеримость.
Тепловая карта – наглядная штука. По ней легко ставить цели и отслеживать прогресс. Удобно обосновывать инвестиции в обучение.
Фокусирует.
Где красное – там и риски. Сразу видно, чем надо заняться, чтобы их минимизировать.
Систематизирует развитие команды.
Развитие привязано к реальным потребностям проекта. Понятно, кому и что именно нужно прокачать, в том числе, в случае онбординга.
Балансирует нагрузку.
Уходим от ситуации, когда обладатель уникальных знаний «зашивается», а кто-то простаивает. И речь даже не про комфорт перерабатывающих, а про устойчивость системы.
Не используйте матрицу для performance review
Это путь на тёмную сторону. Начнутся «заигрывания» с цифрами, появится риск «инфляции» оценок и потери доверия к инструменту. И вы не сможете больше получать все описанные выше «плюшки».
Хотите оценивать перфоманс – берите отдельный инструмент.
Чек-лист
Вот что надо для внедрения у себя матрицы компетенций:
Собрать список «болей» на проекте и свести их в 20-40 компетенций.
Классифицировать по двум измерениям:1) Критично или нет. 2) Поддержка, Релиз, Функционал.
Оценить людей по шкале 0-3.
Выделить критичные красные зоны.
Назначить задачи на развитие и менторство.
Обновлять матрицу раз в спринт или раз в 2–4 недели.
Если захотите использовать у себя в команде этот инструмент, помните: «Не пробуй. Делай. Или не делай. Не пробуй»