Матрица — это карта, а не табель
Команды обычно приходят к матрице навыков, когда найм становится непоследовательным, а разговоры о повышении — субъективными. Возникает соблазн создать десятки строк и поставить уровни от одного до пяти. Но цифры не дают точности, если никто не может показать, чем третий уровень отличается от четвёртого.
Начните с компетенций, которые дают наблюдаемый результат: исследование, написание и редактура, информационная архитектура, работа с API, инструменты, выпуск документации, автоматизация качества и взаимодействие со стейкхолдерами.
Описывайте масштаб и самостоятельность
Для каждой компетенции укажите, какой класс задач человек способен решать и насколько самостоятельно. Начинающий автор может обновить существующую процедуру под ревью. Более опытный — исследовать процесс, проверить его с инженерами, спроектировать структуру и настроить ревью для будущих изменений.
Это полезнее характеристик вроде «отлично коммуницирует», потому что обсуждение опирается на реальные артефакты и решения.
Отделяйте ремесло от знания конкретного домена
Не превращайте стек одного продукта в определение senior-уровня. Kubernetes может быть критичен для одной позиции и не нужен другой. Долговечные навыки документации должны быть отделены от локальной предметной экспертизы.
То же относится к инструментам. Git может быть обязательным в Docs-as-Code-команде, но знание конкретного генератора само по себе не определяет карьерный уровень.
Используйте матрицу в обе стороны
Матрица нужна не только руководителю. Она должна помогать самому специалисту выбирать следующий навык для практики. Добавьте примеры доказательств: переработанная навигация, API reference с проверяемыми примерами, миграция терминологии, quality gate в CI или план документации между несколькими командами.
При найме проверяйте только то, что важно для роли. При развитии выбирайте несколько целей, а не требуйте максимума по каждой строке.
Пересматривайте матрицу вместе с работой
ИИ-черновики, структурированный контент и documentation engineering меняют распределение времени. Обновляйте матрицу, когда меняется сама работа, а не при появлении нового модного термина. Главный вопрос остаётся прежним: какую полезную проблему документации этот человек способен надёжно взять на себя?
Практический разбор
Используйте «Матрица навыков технического писателя, которая измеряет реальную работу» как упражнение для команды, а не как набор названий должностей. Возьмите недавнюю документационную задачу и восстановите, кто принимал ключевые решения: кто обнаружил потребность пользователя, нашёл технические факты, спроектировал структуру, провёл ревью и будет отвечать за следующую редакцию. Обычно сразу видно, что профессия определяется не списком инструментов, а уровнем решений, которые человек способен принимать надёжно.
Сравнивайте задачу с наблюдаемыми способностями, а не с характеристиками личности:
- какую проблему человек может вести без пошагового контроля;
- с какими экспертами он умеет работать и спорить по существу;
- какие риски качества замечает до публикации;
- какой процесс или документационную систему способен улучшить, а не просто использовать.
Хорошая модель профессии подсказывает следующий сложный навык для практики. Если она выдаёт только ярлыки «junior», «senior», «коммуникабельный» или «знает инструмент», для развития и найма она слишком расплывчата.
Короткий редакционный чек-лист
- Матрица — это карта, а не табель. Команды обычно приходят к матрице навыков, когда найм становится непоследовательным, а разговоры о повышении — субъективными.
- Описывайте масштаб и самостоятельность. Для каждой компетенции укажите, какой класс задач человек способен решать и насколько самостоятельно.
- Отделяйте ремесло от знания конкретного домена. Не превращайте стек одного продукта в определение senior-уровня.
- Используйте матрицу в обе стороны. Матрица нужна не только руководителю.
