HeatMap + StarMap + Velocity = Happy Team :)

Довольно часто у компаний возникает несколько крайностей:

• отсутствие ресурсов/компетенций в команде;
• переизбыток каких-то ресурсов/компетенций

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

В этой статье я поделюсь с вами своим опытом и подходом к определению достаточности ресурсов и компетенций в команде.

Довольно часто компании в начале пути формируют дизайн команд с использованием инструмента, который известен нам по фреймворку LeSS. Когда уже команды существуют, внутри создаются карты компетенций — StarMap — чаще всего, с целью понимания Bus Factor (сколько участников команды должен сбить автобус, чтобы она остановила свою деятельность) и мало где я вижу соединение двух этих инструментов HeatMap + StarMap. Именно взгляд на StarMap через призму HeatMap позволит ответить нам на вопрос “Оптимален ли дизайн нашей команды?”

Итак, перейдём немного к теории, чтобы выровняться с тем, как это делаю я.

Составление HeatMap. За несколько лет составления HeatMap я пришла к тому, что составление карты с градацией частоты появления компетенции в виде: 1-никогда; 2-редко; 3-часто вызывает много дискуссий и озадачивают составителей в тех моментах, которые являются второстепенными. Поэтому я изменила подход, возможно, так делаете и вы или где-то уже о таком читали — это явный признак того, что сформировался определённый паттерн и это радует.

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

Этапы составления HeatMap:

• В таблице по вертикали “Задачи бэклога продукта”, по горизонтали все требуемые компетенции. Задачи бэклога продукта я рекомендую брать на ближайший период квартал-полугодие.
• После того, как вы выписали все предполагаемые задачи и все требуемые компетенции для реализации, переходим к проставлению цифры “1” там, где для реализации рассматриваемой задачи требуется данная компетенция, т.е. по умолчанию на данном этапе мы ставим — требуется 1FTE.
• После того, как вы это сделаете для всех, переходим к этапу подсчёта. Суммируем количество 1 в каждой компетенции. Например, у вас требуется компетенция “JavaScript”, суммируем сколько раз данная компетенция появилась в реализации элементов бэклога продукта. Допустим, у вас участвовало в этом упражнении 50 элементов бэклога, компетенция JS проявилась в 20 из них. Следующим шагом будет вычисление доли данной компетенции в бэклоге продукта. В нашем случае 20/50 = 40%

Из опыта чаще всего происходит такое понимание:

70% и выше = компетенция на full-time нужна в команде

50% — 70% — возможно будет недозагрузка, если будет выделенный человек

50% и ниже — скорее всего — это те задачи, на которые мы будем привлекать смежников, либо кто-то у нас в команде будет уметь это делать, выделенная FTE не требуется.

Данная градация не является истинной в последней инстанции, поэтому всегда смотрите на тот контекст, который у вас в компании.

Соединение HeatMap со StarMap:

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

Чаще всего команды делают градацию: 0 — ничего не знаю, 1 — знаю в теории; 2 — есть небольшая практика; 3 — знаю, практикую, либо просто проставляют значки с определённым цветом. Я предпочитаю цветовую градацию, так выглядит нагляднее

HeatMap+StarMap

Из данного примера можно увидеть, достаточно ли у команды компетенций относительного того, что у неё лежит в бэклоге продукта. При первом приближении видно, что не очень востребованной компетенцией 6 владеют 2 участника команды, однако, надо посмотреть как выстроена работа у данных участников, так как они владеют и другими компетенциями, которые наиболее востребованы при реализации бэклога продукта. Одновременно с этим надо смотреть на контекст задач, так как возможно не все амбиции на продукт указаны в бэклоге продукта.

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

Velocity

При чём тут velocity спросите вы, всё очень просто. Когда вы делаете HeatMap и StarMap, вам не хватает ещё одного параметра — скорости, с которой вы можете данный бэклог продукта сделать за отведённое время. Например, у вас задача сделать все 50 элементов бэклога за полгода. У вас есть команда, которая может самостоятельно выпускать элементы бэклога, НО! velocity команды такова, что сделать они это смогут только через 8–12 месяцев при верхнеуровневой оценке. В таком случае, компания будет принимать решение либо о сроках, либо о возможности ещё одной команды через усиление текущей и вы придёте к LeSS

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

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

Приятного вам составления карт и анализа.

Be Ag:)e