Матрица знаний для продуктовой команды

Body

Матрица знаний для продуктовой команды

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

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

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

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

Список подсистем и процессов

При составлении этого списка нужно соблюдать баланс между излишней детализацией и слишком грубыми границами подсистем. Безусловно, можно разбить систему на две части (front-end и back-end) и считать задачу выполненной. Но пользы от такого разбиения будет немного, потому что обе части окажутся слишком большими, чтобы можно было оценить уровень понимания данной подсистемы отдельным членом команды.

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

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

Оценка уровня знаний

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

Процесс заполнения матрицы знаний проще, чем для матрицы навыков. Хотя метод взаимного оценивания может быть применён и в данном случае особого смысла в нем нет. Самостоятельная оценка своих знаний по каждой подсистеме и процессу вполне достаточна. Работнику выгодно показать реальное положение дел. Завышенная оценка может привести к тому, что ему поручат задачу по подсистеме, в которой он не разбирается. Занижение оценок может повлиять на карьерные перспективы.

Что делать с результатами?

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

  1. Проблема ключевого работника – в вашей матрице знаний есть столбец, в котором для всех подсистем и процессов стоят высокие оценки. То есть у вас есть человек, который знает всё обо всём. Казалось бы, что тут плохого? Ничего, если таких людей несколько (а в идеале – такие у вас все). Хуже, если у остальных объём знаний гораздо меньше или вообще их знания сосредоточенны только в узких областях. И тут дело не только в том, что потеря такого работника грозит большими проблемами. Слабое понимание системы в целом не позволяет другим работникам находить более эффективные решения для возникающих проблем.
  2. Проблема «магической» подсистемы – в вашей матрице есть строка, полная очень низких оценок. Другими словами, у вас есть подсистема или процесс, в котором никто не разбирается. Если с ним возникнут проблемы решить их быстро и эффективно у вашей команды не получится. Очень часто такая картина наблюдается после того, как команда теряет работника из предыдущего пункта – он или она уходит, но передать все свои знания просто не успевает.

Как видим, основная задача матрицы знаний – наглядно показать слабые места в передаче знаний между работниками. Поэтому, где-то раз в год нужно обновлять матрицу знаний и на основе её анализа принимать решения о внутреннем обучении сотрудников. Задача руководителя в данном случае избежать перекосов и постараться сделать так, чтобы у каждой подсистемы или процесса было как минимум два «опекуна».