🪅 Квантовая призма #2. Квантовая модель компетенций

В прошлом году в статье "Управление рабочей силой будущего" я писал, что нам нужна новая "деградирующая модель компетенций". Давайте посмотрим, как такая модель может выглядеть.

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

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

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

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

Погнали. 🚀

1. Классическая модель компетенций и ролей

1.1. Карьерная лестница

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

В любой специализации у вас доступно два пути: либо вы линейный сотрудник, он же IC (individual contributor), либо вы менеджер, управляющий другими сотрудниками. По мере роста компетенции, влияния, уважухи, стажа работы и т.п. ваша профессия прирастает атрибутами старшинства.

• Джуны (Junior) сменяются мидлами (Middle), мидлы сеньерами (Senior), сеньоры стаффами (Staff), стаффы принципалами (Principal), принципалы сеньерами принципалами...
• Менеджеры сменяются старшими менеджерами, те директорами, те старшими директорами, те вице-президентами, те старшими вице-президентами...

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

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

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

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

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

Если вы сотрудники, заинтересованные в своем росте, то вы можете начать задавать интересные вопросы. Например, что нужно сделать, чтобы перейти на следующий уровень (или грейд)?

Или вот этот человек, который с вами в одной комнате работает и имеет более крутую приставку и на ваш взгляд делает все то же, что и вы (а то и меньше, sic!), – почему так?

1.2. Уровни развития

Если в компании развитый HR-отдел и продумана система компетенций и уровней (грейдов) специалистов, то вам объяснят открытые карьерные пути с детальной раскладкой. Если нет, то попробуют объяснить все то же самое, только размыто и на пальцах.

Расскажут вам примерно следующее:

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

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

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

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

1.3. Карта скиллов и ролей

Вы не унимаетесь. В целом все понятно, но хотелось бы конкретики и примеров, что такое хорошо и что такое плохо. "Что именно нужно делать, – спрашиваете вы, – чтобы получить повышение?" Причем, желательно, чтобы это было зафиксировано в документе, на который можно опираться, а не как обычно эти ваши "вась-вась".

Между делом отмечу, что разговоры о карьерном развитии, повышении, сопровождающиеся готовностью к собственному развитию и взятию на себя дополнительной ответственности и нагрузки – это нормально. Хотя в некоторых культурах и компаниях так не принято, и исходят из того, что кто хорошо работает, тем воздастся по заслугам их. В таких ситуациях нужно помнить, что обещанного [максимум!] три года ждут, а потом уходят.

В этот момент HR или менеджер, – в достаточно зрелой компании, – разворачивает перед вами карту компетенций, которую они тщательно составили для каждой роли (или скопировали у соседа).

Например, вот так выглядит карта для Software Engineer в Dropbox (визуализация моя):

Эта же схема, но с учетом прогресса каждого из скиллов при переходе по уровням выглядит так:

Дальше каждый уровень подробно расписан в разбивке по отдельным скиллам, и все вместе это дает целостную картину ожиданий от сотрудника. Если немного потрудиться, то подобную информацию можно упаковать в визуально обозримый фреймворк, как это сделала Figma для дизайнеров, и использовать вместе с командой.

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

Ну теперь-то, дорогой друг, тебе все понятно? – Ну в целом да.

Здесь важно подчеркнуть, что приведенные мной примеры от Dropbox и Figma – это очень круто. Вот прямо 🔥! Это показывает, что компании не просто имеют высокий уровень зрелости HR-процессов, но и сознательно думают о развитии компетенций сотрудников и, как следствие, интегральной компетенции компании.

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

2. Наследие ремесленничества

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

Логика линейного роста повторяется из раза в раз, в какую бы нишу вы ни отправились: в разработке софта джуны вырастают в принципалов, в науке студенты – в академиков, в управлении – менеджеры (руководители) в председателей совета директоров.

Каждый раз мы предполагаем верными простые "истины":

• мастерство не пропьешь и приходит с опытом;
• старшинство создает подчинение и порядок;
• продолжай усердно работать – и тебя заменят.

Вероятно, многое из этого было ±верным в индустриальную эпоху, но времена меняются.

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

Внешние контекст и окружение быстро меняются и эволюционируют, но:

• Устаревшие знания. Предметные знания протухают в мгновение ока. Если вы руками не в материале, то уже спустя год вы, вообще говоря, потеряли экспертизу. А кто у нас не в материале? Правильно, управленцы. Поэтому работодатели зачастую переплачивают за эфемерные протухшие люминесценциибылого.
• Организационная слепота. Организационная иерархия не отображает целостного актуального состояния коллективной экспертизы относительно внешнего мира. У вас нет инсайтов на пробелы и узкие места. И вы буквально понятия не имеете, на что способна ваша организация, а на что нет.
• Движение от загрузки. Мы нанимаем людей под задачи, требуя каждый раз обосновать найм наличием загрузки для человека. Сначала покажи, где вы заваливаете участок, потом обсудим, кем закрыть дыру. Мы спрашиваем, что необходимо сделать, а не что мы должны быть способны свершить. Идем от бэклога, а не от модели свершений.

Мы интуитивно понимаем, что сетевые структуры обходят иерархии, но:

• Усиливаем иерархичные структуры. Линейный рост вверх встроен в систему. Достигнутый уровень в роли – это регалия. Мы даже не рассматриваем сценарий, когда человек должен быть понижен в уровне. Только вверх. Горизонтальные перемещения и внутренняя мобильность скованы. Но ты можешь попробовать пересидеть начальника и занять его место.
• Замороженная адаптивность. Контроль и авторитет основаны на достигнутом уровне и выражаются в звучности должности, которая соответствует скорее продолжительности (стажу) работы, чем экспертизе, уникальности и способности сшивать разрывы. Организационная модель предпочитает долгосрочную лояльность, устойчивость структуры и возможность годового планирования способности перестроиться завтра, гибкости и адаптивности.

А потом приходят они..., и мы снова загоняем их в рамки прошлого.

Выросли новые поколения, закаленные в онлайн-сражениях, но:

• Бинарная логика. Мы предлагаем им только две траектории: либо ты линейный сотрудник (IC), либо ты менеджер. Как будто управленческая наука не изобрела других альтернатив. А можно я буду танком, хилером иди дамаге-дилером? А? Шутки шутками, но координация ролей в сетевых играх на порядок динамичнее, чем то, с чем сотрудники сталкиваются, выходя на работу. "Ну да, ну да, – ворчите вы, – работа не игрушки."
• Навязанное подчинение. Наш главный рецепт для молодежи неизменен: делай хорошо свою работу, покажи свой настоящий потенциал, усердно трудись – и тебя заметят и оценят. Давайте уже признаем, что это не работает. Это расплывчатый, эгоистичный и вводящий в заблуждение совет. В иерархичных структурах это всегда решение конкретных людей с властью.

А потом приходят они... Или оно. В общем вот это...

В эпоху ИИ меняется определение работы, но:

• Потеря контроля. Мы пытаемся все еще смотреть на роль целостно, считая ИИ всего лишь инструментом в правильных руках. Но что, если потенциал ИИ намного больше? Что если ИИ может заменить целый навык, а искусственный агент может неразличимо мимикрировать и замещать собой целиком роль? Вы точно понимаете, какое место ChatGPT занимает в ваше оргмодели, а не в вашем браузере?
• Навыки без владения. Мы продолжаем считать, что держателем компетенции является человек и она неотторжима от него. Но что, если сотрудник тренирует ИИ-копилота, дополняющего его? Может ли сотрудник, увольняясь забрать пилота с собой? Вы наверняка скажете, что нет. Но если развернуть ситуацию наоборот: готовы ли вы, чтобы кандидат принес с собой искусственное расширение своих способностей?

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

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

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

3. Квантовая модель компетенций и ролей

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

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

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

3.1. Карта домена

В основании квантовой модели лежит карта домена, в котором работают сотрудники (да и организация в целом) и по которому мы определяем роли.

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

3.1.1. Система координат

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

Также и в вашем домене экспертизы: как только вы задали базовый слой рассмотрения (baseline, который удобно выравнивать по стартовым компетенциям новичков), вы относительно легко можете сказать:

• что является более глубоким знанием, описывающим природу вещей и внутреннюю кухню системы;
• что является более "высоким" знанием, описывающим отношение системы с внешним контекстом и их взаимное влияние.

Идете вниз – копаете вглубь до атомов. Идете вверх – формируете образ влияния и зависимостей до платформ, экосистем и космоса. Микроскоп и телескоп, если хотите.

Отмечу сразу, что это нелинейная картина. Она в реальности многомерна: система вложена во множество других надсистем, имеет соседей, и содержит внутри множество подсистем. И так для каждой системы. 🤯

У многоуровневой схемы есть удобное плоское представление, которое эксплуатирует наши врожденные навигационные способности, – отсюда "карта домена". Это плоскость, замощенная тайлами (плитками, лично я предпочитаю шестиугольники), в которой можно уменьшать и увеличивать масштаб. При этом, конечно, приходится жертвовать размерность и рисовать трехмерную проекцию, простите за такую математическую подробность.

3.1.2. Пример: написание кода

Проще всего понять, как это работает на примере. Поэтому давайте уже его посмотрим:

Что тут изображено?

• В центре в фиолетовой ячейке у нас группа компетенций (или навыков) по написанию кода (coding). Она делится на разные подобласти: написание кода, чтение кода, сборка/компиляция кода, отладка кода, тестирование и т.п. Закрашенные области условно обозначают то, что нашей организации важно или, скажем, "закрыто".
• В больших шестиугольниках обозначены соседние области знаний и навыков: девопс, безопасный код, совместная разработка, упаковка программы, платформы. Некоторые из внутренних подобластей также раскрыты, если организация до них "доросла".
• Внутри с выносками подписано возможное дополнительное деление (см. также далее).

От организации к организации, от специалиста к специалисту, от стека к стеку, эта схема может отличаться в деталях и расставленных акцентах. Но важны две вещи:

1. Она отображает мировосприятие своего домена эксперитзы сотрудниками компании.
2. Она динамически развивается с набором экспертизы и выходом в новые области: вверх, вниз или вбок.

Мы нажимаем магическую кнопку и уменьшаем масштаб:

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

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

Нажимаем другую кнопку – и масштаб увеличивается:

Мы заглянули вглубь написания кода. Оказывается, тут все не так просто:

• Внутри нужно знать язык, парадигму программирования (например, ООП), структуры, алгоритмы, среду разработки, логирование, работу с памятью.
• В каждом из разделов уже проглядывается своя внутренняя детализация, за которой проглядывается уже не "база", а следующий уровень глубины понимания мира.

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

В примерах выше: написание кода – это целостный навык, но и вложенное в него понимание методологии ООП – тоже целостный навык, но и вложенное уже в него понимание работы классов (например, на контрасте с другими типами описания объектов) – тоже целостный навык. Каждый такой навык важен сам по себе. Отмечу также, что знание всех входящих компонентов не гарантирует овладевание выше стоящим навыком.

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

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

3.1.3. Букво-формы

В следующем разделе мы подробнее обсудим навыки, но предварительно отмечу, что карта домена позволяет на практике понять, что значат все эти I-shape, T-shape, П-shape и т.д.

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

T, F, E-Shape: специалист прокачался не только в своей вертикали, но и на одном или нескольких уровнях вышел за пределы своего базового домена вширь.

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

Очевидно, что эту алфавитную тему можно продолжить и предложить вариации на тему Ш-Shape, O-Shape, A-Shape и т.п. ;)

3.1.4. Важные нюансы

Что еще важно отметить:

• Не зацикливайтесь на гексагонах просто потому, что они вам, как и мне, нравятся. В конце концов, это граф, описывающий связность систем. Используйте любую подходящую визуализацию. Например, шестиугольники. Хехе.
• Выберите свой подход к детализации, декомпозиции и сборке. Опирайтесь на свое ощущение связности и важности. Отмечайте, что является критичным, системообразующим именно для вашей организации и домена экспертизы.
• Если ваша карта выглядит общей (вы бы то же самое нарисовали и в другой организации на тех же ролях), вы мало поработали, копайте дальше. У вас не может не быть отличительных черт. Карта для веб-разработки не такая, как карта для мобильной, и обе отличаются от карты для встроенных систем.
• Не усложняйте то, что и так сложно. Убедитесь, что описывая домен, вы используете понятные термины, как минимум общие с вашими коллегами.
• Карта домена – это не камень и не бетон. Она должна быть живой и развиваться во времени. Если это не так, проверьте, если ли пульс у вашей организации. Возможно, она присмерти.
• Для каждой роли у вас будет своя карта доменов, но сами карты связаны между собой примерно также, как связана ваша организация. Поэтому само собой напрашивается "мегакарта", покрывающая всю организацию. Это очень правильная мысль!

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

"Возможно, – подумаете вы (я вас не заставлял!), – это неплохая основа для вузовской программы." Вы не далеки от истины.

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

Так, но где там роли? Когда мы уже дойдем до сотрудников? Сейчас...

3.2. Карта навыков

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

3.2.1. Свертка карты доменов

Но для дальнейшего шага нам придется сделать свертку, понизив "размерность".

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

Для этого нам нужно раскрасить карту домена, объединяя блоки по смыслу.

Если в какой-то группе есть опорный элемент, то можно смело отталкиваться от него:

В итоге поверх карты домена у нас получилась свертка композитных навыков.

3.2.2. Пример: написание кода

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

Наш средний слой (из трех рассматриваемых в примере) можно условно разделить на четыре группы композитных навыков:

• Умение писать масштабируемый и поддерживаемый код
• Умение внедрить практику непрерывной интеграции (обратите внимание, что блок Source Control общий для двух навыков)
• Умение поддерживать коллективную разработку
• Умение оптимизировать свой код под целевую платформу

Наш верхний слой может, например, раскладываться на пять композитных навыков:

• Умение разворачивать DevSecOps процессы на облачной инфраструктуре
• Умение внедрять SDL (Security Development Lifecycle)
• Умение руководить инженерной командой
• Умение управлять разработкой софтверного проекта
• Умение создавать софтверные платформы

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

Спускаемся на уровень ниже и обобщаем в четыре композитных навыка:

• Умение использовать инструментарий на полную катушку
• Умение трезво следовать за эволюциея языка программирования
• Умение грамотно выбирать структуры данных и алгоритмы под кейс
• Умение управлять потреблением ресурсов программой

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

Давайте попробуем ее собрать!

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

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

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

3.2.3. Граф навыков

Композитные навыки удобны для работы как свертка пространства и обобщения, но вместе с этим они несут под собой связность доменов на разных уровнях. Мы можем представить это в виде связанного графа, заменив шестиугольники точками (вершинами графа), а "проливаемый" свет – связями (сторонами графа).

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

Может показаться сложным, но этот пункт – самый механический. Это просто граф связей композитных навыков в соответствии с картой домена.

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

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

3.2.4. Пример: пчелка, котики и панда

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

• Пчелка у нас низкоуровневый разработчик начального уровня (джун), но она единственная в команде знает, как запихнуть код на маленькую плату, помещающуюся в свистке и умееть писать на низком уровне и немного оптимзировать. Хотя кажется, что без пчелки не обойтись, она на уровне 0 (ноль). Фаундер стартапа уверен, что она ценна только одним навыком, а значит ее можно легко заменить на другую пчелку.
• Серый котика у нас пилит облачное ядро системы и является мидлом (уровень 1). Он ценен не только тем, что пишет поддерживаемый код, но и умением общаться с пчелкой на ее языке. Еще серый котик понимает, как работать в команде по аджайлу и настроить девопс. Серому котику кажется, что он делает дофига и пилит самую важную часть, но почему-то он все еще мидл.
• Рыжий котик присматривает за серым и убеждается, что команда разработки идет в фарватере современных требований и подходов, следит за развитием их основного языка программирования и поддерживает команду в курсе новинок (фаундер говорит, что для стартапа это очень важно). Рыжий котик тоже пишет код ядра, но, в отличие от серого, понимает, что происходит под капотом системы и как из общих наработок выстроить платформу. Поэтому сеньор (уровень 2) – рыжий котик, а не серый.
• Панда – CTO стартапа и любит считать себя главным архитектором (уровень 3), она почти не пишет код, но зато рулит командой, отвечает за внедрение безопасной разработки и вместе с серым котиком настраивает девопс, а еще является публичным лицом стартапа по техническим вопросам.

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

Наша схема подсказывает каждому из участников, куда копать, чтобы стать круче:

• Пчелке надо прокачаться в новом домене, углубившись в оптимизацию аудио-стека не железке.
• Серому котику надо побольше общаться с пандой и перейти от внедрения CI к полноценному CI/CD и дальше подтянуть базу по DevSecOps.
• Рыжему котику надо тоже начать выступать на профильных конференциях, но не конфликтуя с пандой.
• Панде надо поднять ставки для стартапа – и начать влиять на индустриальные стандарты через свои публичные выступления.

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

3.2.5. Покрытие графа

Приведенный пример можно обобщить:

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

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

• У вас нет слепых зон – навыков, которые важны, но никем не закрыты.
• У вас нет узких мест – востребованных и критичных навыков, закрытых одним человеком.
• У вас нет дыр в коммуникациях – между двумя соседними вершинами всегда есть хотя бы один человек, который их связывает (и работает как переводчик).

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

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

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

3.2.6. Ходоки и хабы

Оптимизация покрытия – это критичная задача, которую, на моей практике, многие не замечают. Это можно понять из следующей схемы:

У нас есть два ключевых вопроса:

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

Два вопроса – два ответа. Вам нужны ходоки и хабы.

• Ходоки – это уникальные люди в организации, которые способы в ограниченное время закопаться в своем домене эксперизы до самых кишок и протянуть полученные инсайты на самый верх долгосрочных последствий. Они же способы любую принципиальную инициативу с верхнего уровня абстракции декомпозировать вниз как минимум в свой домен. Классический пример таких людей в технологических компаниях – это позиции Technical Fellow / Distinguished Engineer. Причем люди на них могут быть менеджерами, а могут не быть. Резюме: ходоки тем круче, чем между большим количеством уровней они могут перемещаться.
• Хабы – это уникальные люди в организации, которые способны понимать максимальное количество соседей и согласовывать их разногласия. Это системные синтетики, наиболее эффективно сшивающие организацию и видящие противоречия через два уровня сумрака. Они первые скажут, что это не будет работать, потому что Джон и Анжела из департаментов на этаж выше и на этаж ниже, соответственно, не договорятся, и объяснят почему и что с этим делать. Обычно, про них говорят, что они все знают, но не в смысле всех сплетен, а в смысле, как тут все работает на самом деле.

Ходоки и хабы – самые ценные специалисты компании, каждый по-своему, стягивающие ее в работающий организм. Но, как правило, ни один из них не умещается в типовую номенклатуру. Например:

• Ваш верхний пороговый уровень для специалистов, скажем, – 4, но по факту ваш лучший ходок – маг 6-го уровня.
• Ваша система уровней настроена так, что привязывает человека к месту и умеет считать только от него. И в итоге ваш лучший хаб, связывающий половину организации, продолжает сидеть на 2м разряде, а дать хилеру 4й – вас жаба задушит.

Эти два кейса интересны также тем, что они показывают, что выбор метрики на графе очень многое говорит о вашей организации:

• Наиболее лояльный к развитию организации "бирюзовый" путь (как в примерах с пчелкой, котиками и пандой, а также ходоками) – считать число звеньев в подграфе конкретного сотрудника. Но он может показаться вам 1) дорогим, 2) нарушающим привычную картину должностей и иерархии (что с этим делать, обсудим в следующем разделе). Этот способ поощрает сетевые структуры.
• Наиболее жесткий и контролируемый "красный путь" (как в примере с хабом) – считать максимальное число звеньев в подграфе от фиксированного места конкретного сотрудника. Этот способ поощряет иерархичные структуры, не давая возможности случиться слишком сильной кооперации на местах.

3.2.7. Важные нюансы

Подчеркну еще раз сказанное выше в разных местах. Карта навыков:

• отображает коллективную организационную способность (суммарную компетенцию) решать тот или иной класс задач;
• одновременно говорит, в чем ваши приоритеты по людям, и в чем ваши затыки или особенности настройки;
• позволяет планировать расширение компетенций компании через призму людей, фактически являясь схемой освоения нижележащей карты доменов;
• позволяет показать сотрудникам пути развития за пределами классических "горизонтального" (на самом деле – углубление и расширение экспертизы) и "вертикального" роста (на самом деле – выход конкретно в домен управленческой вертикали);
• переопределяет логику уровней сотрудника через активные компетенции и способность "стягивать" и "провязывать" организацию, а не через выслугу лет – мы поменяли систему координат, в которой описываем развитие.

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

3.3. Квантовые уровни и доказательства работы

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

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

Но есть еще один аспект, который мы пока обходили стороной. А что означает, что конкретный человек так или иначе представлен на карте навыков?

3.3.1. Пример: панда

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

Ну, например, это может означать, что мы внимательно ходили за пандой в течение года (квартала, месяца – выберите вашу степень дотошности) и записывали, на что панда тратила свое время. И выяснили, что:

• 30% времени панда разводила бурную деятельности по управлению командой: распределяла таски, отсиживала на 1:1 с каждым из сотрудников, менторила серого котика жизни, рисовала со своим HRD карьерные траектории и проводила перформанс-ревью;
• 14% + 18% = 32% времени панда засучивала рукава и вместе с котятками внедряла безопасность в процессы разработки и разворачивания платформы умных свистков в облаке, попутно получая сертификацию CISO;
• 20% времени панда присматривала за деятельностью серого котика по настройке CI/CD и давала ему умные советы как более старшая и опытная коллега, натюскивая смотреть шире и видеть перспективы – а на самом деле перевешивала на него свои старые обязанности и помогала разобраться в своем прошлом гениальном коде;
• 13% времени панда ездила по конференциям, общалась со СМИ и сопровождала фаундера на встречах с потенциальными инвесторами; еще панда написала две статьи и завела телеграмм-канал;
• 5% времени панда отвела на погружение в дебри форума по стандартизации интернета вещей и перепискам на разные темы, чтобы зарекомендовать там свое доброе имя.

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

Но, что важно, хотя это и не идеально (обсудим дальше, как улучшить и не ходить за всеми с часами), это уже радикально отличается от того, что могло бы быть...

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

• 2 года назад она внедрила непрерывную интеграцию кода в стартапе на моменте его запуска (сейчас это поддерживает серый котик);
• 1 год назад она руководила переносом инфраструктуры в облако, задавая все правильные вопросы, которые выучила на курсах для CISO, и наставляя жизни серого котика, который реализовывал это руками;
• 1 год назад она возглавила команду разработки, менторясь у тогдашнего CTO, и с тех пор рулит ей;
• 0.5 года назад, чтобы показать всей команде, что она огого и сечет фишку и не зря получала сертификацию, начала внедрять (и все еще внедряет) в компании SDL;
• эпизодически она вынуждена ходить вместе с фаундером по встречам с инвесторами, но на самом деле пытается зарекомендовать себя как эксперт высшего уровня, строя свой личный имидж, поэтому выступает на конференциях и фоново проводит разведку и заводит знакомства через форум по стандартизации.

И снова, кто-то скажет: "Панда, так держать!" А кто-то: "Гнать такую панду ссаными тряпками".

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

• это навык из прошлого, который больше не практикуется и поэтому мог устареть;
• это поверхностный навык, на развитие которого объективно потрачено слишком мало усилий;
• это теоретизированный навык, который не имел личной прикладной проекции (и вероятно, идет подмена между руководить кем-то, кто делает, что сказано, и сами делать то, что нужно);
• это пустой навык, который (пока) не имеет результата для организации, поэтому не понятно, он вписывается в домен или это найс-ту-хев свистелки.

3.3.2. Деградирующая логика

Мы подошли к важному откровению: каждый навык должен иметь весомое подтверждение в рассматриваемый период – или его не было.

Перечитайте еще раз.

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

Когда мы говорим, что человек находится на уровне N, то мы подразумеваем, что он не просто умеет (умел) что-то делать в N+1 соответствующих навыкам блоках доменов, но и что это происходило в достаточной степени в рассматриваемом периоде времени (например, за год или ежеквартально).

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

Фактически, я имею в виду следующее:

Если мы утверждаем, что человек отработал год на уровне N, то это означает, в зависимости от модели оценки, что:

• по времени: он осуществлял деятельность, релевантную каждому из композитных скиллов достаточное количество времени, чтобы это пошло в зачет (например, больше порога в 15%); либо
• по свершениям: он своей деятельностью добился достаточного количества (например, больше половины) "зачетных" результатов, релевантных каждому из композитных скиллов.

Вы правы в своих догадках, это начинает походить на игру, в которой вы проектируете сеттинг.

Что тут важно еще отметить:

• Если вы исходите из оценки времени (не буду вас отговаривать), то чем более график рваный, тем больше это похоже на паттерн "ходока" или "хаба". Если же график четко поделен на области: сначала тут поработал, потом там, потом сям, то, возможно, что человек просто ищет себе место и снизив окно выборки с года до квартала вы увидите, что человек не третьего уровня, а второго. Это требует тонкой настройки и прозрачности правил игры.
• Если вы исходите из оценки свершений (не буду настаивать), то тут важно соблюсти баланс: добиться примерной равновесомости задач. Например, решить, что ваша минимальная планка для оценки трудоемкости – это одна человеко-неделя. Настойка сетинга может при этом включать какие-то задачи как обязательные, а какие-то опциональные (под развитие).

3.3.3. Пример: панда

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

Смотря на свои результаты за год, панда сияла от гордости. Судите сами:

• Управление инженерной командой: ✅ провела с каждым членом команды каждые две недели 1:1 про личные цели, результаты и развитие; ✅ стала ментором и наставником для серого котика; ✅ управляла приоритетами разработки с учетом загрузки коллег; ✅ сводила всех на тим-билдинг; ⬜ но не успела расширить команду, наняв новых разработчиков на поднятые стартапом деньги.
• Внедрение SDL: ✅ провела для всех членов команды тренинг по ключевым принципам и подходам по следам своего обучения на CISO; ✅ разработала прикладной план по внедрению в стартапе; ⬜ но не успела перейти к практике.
• Реализация облачного DevSecOps: ✅ получила сертификацию от облачного вендора; ✅ помогла серому котику обновить и мигрировать инфраструктуру; ✅ помогла серому котику составить план по внедрению DevSecOps для железа вместе с пчелкой.
• Реализация CI: ✅ помогла серому котику разобраться в своем легаси-коде; ⬜ отказалась переписывать его под платформенные требования рыжего котика (все сделал серый); ⬜ не стала разбираться в обновлениях CI-тулов от поставщика; ✅ вычитала и поправила внутреннее руководство по новому подходу к CI, составленное серым котиком.
• Публичный спикер: ✅ провела пять выступлений перед потенциальными инвесторами про технологические особенности платформы; ✅ помогла рыжему котику подготовить и отрепетировать презентацию про платформу стартапа для технологической конференции; ⬜ не стала писать статьи на популярные площадки; ✅ завела телеграмм-канал, где пишет свои CTO-заметки.
• Инфлюенсер по стандартам: ✅ зарегистрировала стартап официальным участником форума (ок, это было просто); ✅ включилась во все релевантные обсуждения от лица компании, консультируясь время от времени с пчелкой; ⬜ пока не добилась принятия изменений в протокол.

Я бы тоже гордился пандой. Но что еще важно: на следующий год список потенциальных свершений будет другим, потому что то, что сделано, дважды в зачет не идет. И это будет интересный разговор с ее собственным руководителем (фаундером) прогрессивного стартапа, который вероятно, будет повторяться как минимум каждый квартал, внося свои коррективы.

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

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

3.3.4. Пример: пчелка

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

• пойти вглубь экспертизы и "затащить" для стартапа низкоуровневую оптимизацию аудио; либо,
• запартнериться с серым котиком и "втащить" в контур своей деятельности практики CI/CD, которые они с котиком как раз описали в руководстве.

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

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

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

И вот на этом фоне план достижения нового уровня и, соответственно, освоения нового навыка для пчелки играет уже другими красками:

• ⬜ Разобраться и задокументировать для стартапа, как на двух целевых платах реализуется аудио-стек и как на него можно влиять (не только прокачать понимание железа, но и создание поддерживаемого кода);
• ⬜ Собрать минимальный прототип с пользовательским интерфейсом, позволяющим клиенту выбрать кастомный аудио-файл, вырезать из него короткий фрагмент, оптимизировать под железку и залить на нее (не только упаковать свои наработки, но и поработать с рыжим котиком над интеграцией в общую платформу);
• ⬜ Предложить и обосновать изменение в индустриальный стандарт (не только понять принципы стандартизации и правила игры, но и начать играть с пандой в лоббизм).

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

Формула действия: обновление карты домена ➡️ атомарные или композитные навыки ➡️ критерии подтверждения проявления навыка.

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

Многие из этих аналогий мигрируют в корпоративное управление. Возможно, у ваших конкурентов. :)

3.3.5. Квантовые параллели

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

• В рамках организации через свертку карты доменов в карту (граф) навыков мы описываем потенциальные состояния, которые сотрудник может занимать в ходе своей рабочей деятельности, но не все сразу.
• У каждого из состояний может быть некоторая "пропускная" способность: сколько сотрудников максимум одновременно может в нем находиться.
• Человек является целостным, неделимым, у него есть определенный уровень развития как специалиста, который пропорционален количеству разных состояний, которые он может в достаточной степени проявлять в некоторый диапазон времени.
• Можно сказать, что специалист является суперпозицией состояний (навыков), проявляя их с некоторой вероятностью. Но если мы заявимся к нему прямо сейчас, он "вывалится" в одно конкретное состояние, соответствующее текущей задаче. Наш квантовый сотрудник сколлапсирует в свою текущую функцию.
• Дальше мы пытаемся понять, проявил ли конкретный человек свой уровень, реализовался ли его потенциал? Для этого нам нужны "ловушки" – конкретные задачи, в которых этот потенциал засвечивается, если приложены достаточные усилия.

3.3.6. Рост

Когда человек поднимает уровень, это значит, что его набор состояний дробится, появляется еще одна опция, на которую тоже нужно найти ресурс. Но ресурс ограничен. Если формальный уровень слишком высокий для человека, то мы будем наблюдать такие характерные проявления (каждое из которых нормально, если оно носит временных характер до оптимизации):

• Суетливость, пускание пыли в глаза: человек формально поработал в десяти разных состояниях, помахав наличием у себя соответствующих навыков, но конкретного результата нет нигде. Нигде не успел "засветиться" в достаточной степени, кроме, возможно, своего истинного интереса.
• Хроническая переработка: человек взял на себя множество формальных обязательств, которые не может оптимизировать в стандартный график и при этом добиваться достаточного уровня "засветки". Но и терять в статусе не готов, поэтому ходит на дополнительные уровни сверхурочно.

Это означает, что в целом возможны три основные модели роста:

• Повышение эффективности: сотрудник умеет упаковывать и эффективно сочетать все больше состояний в то же самое количество времени. Возможны временные выплески в овертайм, но как исключение на этап освоения. Человек берет эффективностью труда и качеством, а не количеством. Но этот путь требует поиска и адаптации инструментов оптимизации, в том числе изменения мышления и процессов, что ограничивает скорость роста.
• Расширение окна труда: сотрудник совмещает все больше состояний, расширяя фактическое время труда. Работа 50-60 часов в неделю и на выходных становится нормой, которая начинает затрагивать остальных сотрудников, потому что потребность во взаимодействии никуда не деется. Человек берет упорностью труда, но объем работы накрывает ближайших соратников. При этом единственное, чем жертвует сам сотрудник – это личное время, поэтому при его избытке можно быстрее растить свою карьеру.
• Имитация труда: сотрудник перескакивает между состояниям, не задерживаясь ни в одном из них существенного количества времени, прибавление нового состояния просто означает, что на каждое в обойме будет тратиться меньше времени. Так как общие трудозатраты остаются неизменными, то каждое состояние "помечено", но не засвечено. Человек берет инициативностью, но за нее расплачивается кто-то другой. При этом такой сотрудник в худшем случае рискует только своей репутацией.

3.3.7. Развитие без роста

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

В сценарии исследователя у человека вырабатывается некоторая база, вокруг которой линия специалиста на графе навыков начинает извиваться, пробуя разные направления до тех пор, пока человек не сделает ставку. Но при этом мы честно говорим, что все "отпавшие" хвосты – это важный опыт, но устаревший и самое ценное, что человек из него вынес – это связи и картина мира.

• В традиционных реалиях, когда знания не устаревают, мы бы сказали, что человек за эти пять лет (на схеме) драматически вырос и чуть ли не хаб 6-го уровня уже.
• Но в квантовой модели его уровень с точки зрения практических подтверждений проявления навыков остался тем же, хотя потенциал роста, конечно, вырос.

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

• В традиционных реалиях, когда знания не устаревают, мы бы сказали, что человек за эти пять лет (на схеме) драматически вырос и чуть ли не ходок 6-го уровня уже.
• Но в квантовой модели его уровень с точки зрения практических подтверждений проявления навыков остался тем же, хотя потенциал роста, конечно, вырос.

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

3.3.8. Просветка традиционной модели

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

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

Но дальше вы начинаете задавать неприятные вопросы и просите подтвердить фактическими результатами проявление каждого из навыков. И, – о чудо! – вы начинаете понимать, почему все так криво и медленно работает. Кого-то повысили за дружбу, кого-то за компанию, кого-то за выслугу лет, кто-то хорошо себя продал при устройстве, а кто-то пахает за себя и того парня. Как бы там ни было, в новой системе координат старые уровни выглядят иначе.

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

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

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

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

4. "Квантовые" эффекты

Попробуем собрать "специальные" эффекты квантовой модели навыков:

1. Формируя карту домена и далее граф навыков, организация может управлять доступными для сотрудников состояниями, в которые можно развиваться, избегая как недостатка покрытия, так и сверхконцентрации. Такая расширенная карта может служить альтернативой штатному расписанию и оргструктуре.
2. Карта доменов и граф композитных навыков меняются со временем, отображая жизнь компании. При этом, что считать опорными навыками и как делать эту свертку, решает сама организация. С развитием индустрии композитные навыки имеют свойство разрастаться. Требования к джуну сегодня и три года назад – большая разница.
3. Граф навыков не только описывает вашу организацию, но и позволяет судить о том, какого рода роли в вашей организации возможны. Вероятно, вы будете однажды, готовы отказаться от привычной номенклатуры руководителей и линейных сотрудников. Например, вы получаете четкую иллюстрацию для расхожих метафор о I/T/П-Shape профилях сотрудников. (К слову, обсуждавшиеся выше ходоки – это очень длинные I, а хабы – Ж.)
4. Сотрудник находится всегда в суперпозиции разных навыков, распределяя время между ними. Чем больше навыков вероятно может проявить сотрудник, тем больше его потенциальная отдача для организации. Чем больше навыков он проявляет фактически, тем больше его подтвержденный уровень. Важно не путать одно с другим.
5. Модель не говорит, чем конкретно сейчас занимается человек, хотя можно прийти к нему и узнать. Тогда его "волновая рабочая функция" схлопнется в конкретный проект. Но если это делать слишком долго (например, постоянно спрашивать "ну как"), то он может застрять в одном состоянии и эффект рабочей дифракции разрушится. Это к вопросу о мерах контроля и надзора и эффекте наблюдателя.
6. Между сотрудниками, находящимися в одном состоянии (навыке) происходит синхронизация. Но помимо всех прочих человеческих факторов, мы понимаем, что чрезмерное скопление людей с разным уровнем в одном состоянии эту хрупкую "запутанность" разрушает. В целом, вам не нужно знать, как это происходит, но если два человека в двух концах организации перекрываются навыками (и, соответственно, деятельностью), то вероятность прохождения сигналов из одного конца в другой резко повышается. Великая сила совместного труда.
7. Но если между двумя концами организации слишком много таких передаточных звеньев, то сигнал затухает и искажается на переводе с одного языка на другой. Поэтому, чем больше ваша организация, тем больше вам нужны "ходоки", протаскивающие сигналы на себе, и "хабы", работающие усиливающими ретрансляторами и сглаживающими локальные неровности.
8. Поддерживать в организации большое число высокоэнергичных сотрудников опасно: от них будет искрить и замыкать. Поддерживать в организации большое число низкоэнергичных сотрудников тоже опасно: на них все колебания системы будут затухать. Но слаженная высокоэнергичная система малыми силами может делать то, что не по силам большой застоявшейся системе.
9. В системе заложено остывание. Если не прикладывать специальных усилий, то старые навыки забываются и рассеиваются. На каждой памяти стоит таймер стирания. Единственный способ реанимировать память – это приложить достаточное усилие. Пассивные навыки не считаются.
10. Квантовая модель компетенций – это мостик между пониманиями, куда движется компания и кем она это движение приводит в реальность.

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

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