Привет! Я Коля Димов, руковожу дизайном и исследованиями продукта в Делимобиле. Хочу поделиться тем, как можно оценивать и помогать сотрудникам расти, чтобы их развитие было неотделимо от работы.
Ловушки матрицы компетенций
На рынке существует негласно принятый стандарт — матрица (или карта) компетенций. В ней есть уровни, по которым мы пытаемся понять, на каком грейде находится сотрудник. А дальше решаем — какие навыки стоит подтянуть, чтобы вырасти, например, в сеньора из мидла.
На практике этот подход часто таит типовые ловушки (даже если в команде сильный лид и все искренне заинтересованы в развитии сотрудников).
В списке навыков могут оказаться те, которые сотрудник не сможет прокачать внутри компании. Просто потому что нет подходящих задач, на которых реально можно развить этот навык;
Любой человек не ограничен только скиллами из матрицы. Из-за этого легко не заметить андердога, который может в разы повысить качество работы всей команды, но «по матрице» выглядит средне;
Карта компетенций не всегда отвечает запросам самой компании (или лида, формирующего команду). Она помогает оценить сотрудников по рыночному стандарту. Но далеко не все эти навыки вам действительно нужны, чтобы закрывать текущие боли;
Карты компетенций часто не дают сотрудникам ясного понимания, как расти финансово. Они концентрируют внимание на том, чтобы прокачать навык любой ценой, вместо того чтобы решать реальные задачи компании. Чаще всего эти компетенции так и остаются невостребованными в текущих задачах. А если нет реального применения — нет и оснований для пересмотра оклада.
В какой-то момент я понял, что вес этих ограничений для меня становится слишком большим. А потребность расти никуда не делась — её всё равно нужно было как-то закрывать. Поэтому пришлось собирать свой велосипед — как способ связать ожидания от команды, задачи и развитие в одну систему.
Начинаем копать
Пришлось откатиться к самому началу. Команда (в идеале) не должна появляться просто так. Она рождается из запроса компании: закрыть конкретную боль (а точнее — комплекс болей).
В идеальном мире на старте нанимают сильных лидов, которые помогают правильно определить проблему — и уже под неё нанимают нужных людей.
На практике, конечно, часто происходит иначе: структуру начинают строить по рыночному стандарту (и это логично — так получается быстрее закрывать текущие запросы). Но иногда за видимыми преимуществами прячутся подводные камни. Особенно остро это чувствуется в стабильных командах: недостатки быстро закрепляются в процессах и превращаются в структурное легаси, которое потом сложно вычищать.
Когда формулируешь запрос не как «мне нужен продуктовый дизайн», а как «мне нужно задизайнить удобное приложение для каршеринга с предсказуемыми темпами, без сюрпризов по качеству и срокам» (подставь свой пример) — фокус сразу меняется. Это уже не про поиск абстрактных специалистов. Это про конкретные навыки и опыт, которые действительно помогут решить задачу.
Как сформировать необходимые навыки
Здесь начинается самое интересное и самое сложное — рефлексия. Нужно остаться наедине с собой и подумать: какие навыки нужны команде, чтобы закрыть хотелки компании и твои, как лида. Именно компетенции команды, не конкретных сотрудников или направлений.
Мне помогло разделение навыков на 4 направления:
Руки (про прикладное исполнение)
Мозг (про мышление)
Коммуникация (про отношения со смежниками и внутри команды)
Процесс (про организацию работы)
Внутри каждого направления можно расписывать конкретные навыки. Но важно: не просто составить перечень, а честно обосновать — зачем каждый из них нужен компании, команде и тебе как лиду. В этот момент часть навыков отсеивается сама — оказывается, что реальной потребности в них нет.
Я бы рекомендовал по каждому направлению выделять не больше 12 необходимых навыков. Важно помнить, что они могут быть как общепринятыми (например, UX-исследования), так и специфичными (например, понимание работы финансовых рынков).
Когда список навыков готов, нужно сформировать градацию. Например, разделить на 4 уровня (потом это можно менять):
Уровень 1 — не владею навыком;
Уровень 4 — верх вашего ожидания (и запроса);
Уровни 2–3 — промежуточные состояния между ними.
И совет: в каждый уровень закладывать конкретику. Так будет проще и тебе (запрашивать что-то при найме или оценке), и сотруднику (честно себя оценить).
Очерчиваем круг
Теперь нужно понять: какие роли нужны, чтобы закрыть все необходимые хотелки. Тут можно вернуться к рыночной практике — вспомнить про существующие роли или использовать уже имеющиеся в команде.
Сделать это просто: например, сказать себе «мне нужен продуктовый дизайнер» и для каждого навыка самостоятельно проставить желаемую оценку. И так по каждому направлению.
Для удобства все эти оценки перекладываем на лепестковую диаграмму. И вуаля — мы видим места, где навыки, требуемые от команды, проседают:
«Проседающие» зоны — те, которые нужно закрыть при помощи новой роли, чтобы команда в целом покрывала запрос. Здесь уходим на второй круг: думаем, как лучше трансформировать роли и кто сможет взять на себя необходимые навыки.
Оцениваем и корректируемся
Переходим к оценке. Формат можно выбирать любой — от чистой самооценки до 360 со смежниками. Главное, чтобы этот способ помогал выполнить запросы трёх сторон — тебя (как лида), бизнеса (как стороны, которая запрашивает конкретику) и сотрудников (людей, стремящихся не просто получить оклад, но и развиваться).
После сбора оценок нужно скорректировать их с сотрудником, как в классическом перфоманс-ревью, и зафиксировать итоговый уровень скиллов. В момент обсуждений сразу можно ориентироваться на ожидаемую оценку и составлять экшн-план — как можно прокачать навык на реальных задачах.
И ещё одна важная штука: во время корректировки могут обнаружиться скрытые таланты, которые сильно помогут целям компании. В дизайне это особенно актуально: нередко встречаются специалисты, которые умеют в 3D, или исследователи, которые владеют навыками классной вёрстки, — и это поможет закрыть пробелы в команде.
Надуваем круг
Когда есть полная, скорректированная оценка по всей команде, мы сразу видим места, которые по итогу не дотягивают до ожидаемой планки (на диаграмме это проседающие в конкретной роли места). Это будет сигналом и для лида (можно держать фокус на слабых местах), и для команды (это понятный, полезный трек развития). В конечном итоге нам нужно «надуть круг» — чем меньше острых граней в пределах круга, тем быстрее и качественнее команда закрывает потребности и запросы.
Два примера
Приведу примеры, как это может работать на практике с двух сторон.
Сторона лида и бизнеса
Кейс: Сроки всё время едут, хотя все молодцы
Представим, что у вас есть условная продуктовая команда. Все сильные, макеты красивые, исследования делаются. Но релизы постоянно сдвигаются — то недооценили, то переделали задачу или дизайн, то не договорились.
Как это раскладывается через круг:
В навыках «Процесс» и «Коммуникация» вы фиксируете то, что реально нужно: декомпозиция, постановка задач, синк со смежниками, управление рисками, умение говорить «нет» / торговаться по скоупу;
На лепестковой диаграмме видно: «Руки» и «Мозг» у команды в порядке, а «Процесс» проседает не у одного человека, а по команде в целом;
Дальше не нужно пытаться всем сразу прокачивать процесс без привязки к реальным задачам — лучше выбрать 1–2 конкретные просадки, привязать их к реальным ритуалам и артефактам. Например: единый формат постановки задач, критерии готовности и простая схема согласований;
И только потом строить план действий: кому что прокачать, на каких задачах и как понять, что стало лучше (меньше возвратов на переделку, меньше незапланированных сдвигов, меньше конфликтов из-за ожиданий).
Сторона сотрудника
Кейс: Казалось, засиделся на уровне, а на самом деле просто не видел, куда расти в работе.
Есть продуктовый дизайнер. По ощущениям он крепкий мидл: задачи делает стабильно, но без рывков, и на встречах 1:1 периодически звучит: «Я не понимаю, что именно мне прокачивать дальше — всё плюс-минус одно и то же».
Мы строим круг по ролям и навыкам (те самые «руки/мозг/коммуникация/процесс») и сравниваем ожидаемое и фактическое по команде. Внезапно видим, что сильнее всего проседает навык из «Процесса»: управление неопределённостью и рисками в дизайне. Это умение заранее находить «скользкие места», формулировать допущения, договариваться о скоупе/компромиссах и фиксировать решения так, чтобы команда не возвращалась к ним каждые два дня.
И тут происходит важный момент: дизайнер говорит, что это как раз то, что ему интересно — он давно хотел «не просто рисовать», а влиять на предсказуемость и скорость.
Как мы превращаем это в развитие на примере конкретных задач:
Берём ближайшую инициативу, где обычно возникают сложности: новый сценарий в приложении, много стейкхолдеров, зависимость от разработки и аналитики, сроки горят;
Отдаём дизайнеру роль «хозяина риска» по дизайну (не менеджера проекта, а именно по дизайну). Перед стартом он собирает список рисков и допущений, отмечает, что нужно проверить при помощи исследований и данных, а также что нужно зафиксировать решением;
Он вводит один простой артефакт: лист решений (к чему пришли, почему, какие есть ограничения, когда пересматриваем) и короткий еженедельный синк на 15 минут со смежниками, чтобы риски не копились;
На ретро измеряем не просто «прокачал ли дизайнер навык», а ощутимые эффекты: стало ли меньше возвратов на переделку, сократилось ли количество блокеров и время на согласования.
Что получает дизайнер:
У него появляется понятная точка роста, которая не выглядит как «пройди курс» или «прокачай навык вне контекста задач»: она встроена в рабочий контекст;
Дизайнер поднимается на новый уровень — не потому что стал делать другие макеты, а потому что команда перестаёт спотыкаться об одно и то же.
Что получает команда:
Закрывается проседающий навык: решения становятся устойчивее, меньше хаоса на стыках, дизайн перестаёт быть источником неожиданностей;
Лиду проще масштабировать подход: этот кусок процесса легче потом «упаковать» как стандарт команды, а не держать в голове.
Как итог
С помощью подхода «надуваем круг» можно сделать запросы к команде прозрачнее и собрать реальный трек развития: сотрудник качает навык не «потому что так написано в матрице», а потому что это закрывает текущие потребности команды и компании.
Единственное — «надуваем круг» работает только на одном уровне структуры команды. Если вы лид лидов, то круг стоит формировать для своих прямых подчинённых — а они уже создают круги для своих команд.
Я Коля Димов, дизайн-директор с опытом в шеринге, ретейле и тревеле.
Пишу свои мысли и наблюдения в телеграм-канале @quitdesign
