Некоторые пояснения к карте компетенции аналитика - про ячейки

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


Про ячейки

Каждая ячейка представляет собой пересечение домена знаний и уровня навыков использования этих знаний. Читать это надо буквально следующим образом (для начала рассмотрим на примере Выявления и анализа требований):
  1. Аналитик должен знать техники Выявления и анализа требований
  2. Если аналитик знает эти техники, но может их эффективно и правильно использовать только под контролем старшего товарища (руководителя группы, наставника и т.п. - не суть), то он находится на низшей степени владения навыками Выявления и анализа требований. Он "Знает".
  3. Если аналитик способен самостоятельно собирать исходные данные, анализировать их, выявлять и формулировать требования, и при этом за ним не надо следить, то степень владения навыками Выявления и анализа требований соответствует уровню "Применяет". Т.е. человек может самостоятельно выполнять эти работы в соответствии с процессом, который поставлен на проекте. При этом мы от него не требуем организации процесса Выявления и анализа требований.
  4. Если специалист не просто успешно выявляет и анализирует требования, но еще при этом он понимает специфику выполнения конкретного проекта и умеет исходя из этого выбрать наиболее эффективную технологию выполнения работ и оптимизировать ее под условия выполнения проекта, то он владеет навыками выявления и анализа требований на уровне "Оптимизирует применение".
  5. Если человек, понимая процесс, может выбрать наиболее подходящие практики разных подходов и на их основе выстроить свою технологию ведения работ по Выявлению и анализу требований, которая будет наиболее эффективна в конкретных условиях конкретного проекта, то он бизон, он "Адаптирует и развивает".
В принципе по такой схеме можно описать смысл всех ячеек, для этого достаточно ударить домены о навыки, применив для этого (как показал приведенный пример) минимум фантазии. Но тем не менее это очень важный момент и я буду очень признателен за любые комментарии - замечания - пожелания по этому поводу.


Приоритеты навыков

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

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


Как понять, в какую ячейку "попадает" человек

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

Сделать это можно исходя из следующих соображений:
  1. Человек приобретает как положительный, так и отрицательный опыт.
  2. Отрицательный опыт конечно полезен, но только в том случае, когда специалист переваривает его и это приводит к росту положительного опыта.
  3. Количество опыта определяется не количеством решенных задач, а их трудоемкостью, поскольку чем больше человек работал над достижением положительного результата, тем больше он получил опыта. При этом надо все-же определить критерии, что мы подразумеваем под успешным выполнением задачи.
  4. Оценивать опыт необходимо на протяжении некоторого ограниченного периода времени: квартал, полугодие или типа того.
Теперь пытаемся оценить опыт. Чтобы много не писать, приведу вот такой рисунок:
Здесь по абсциссе мы имеем трудоемкость задачи, по ординате - опыт. Диаграмма нарисаована для одного домена. Пусть это будет "Выявление и анализ требований". Раз уж начали надругаться, то чего уж там...

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

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

Как оценить, успешно ли сделал человек задачу? Ну в этом, как мне кажется, нет ничего сложного :)

Други, если кто вдруг дочитает до этого места, поделитесь пожалуйста мнением относительно всего этого дела. Я буду очень признателен.

 Subscribe in a reader

Комментарии

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

    Но вот с понятием «опыт» у нас описанный подход не заработал.
    Причина в том, что в данном подходе Руководитель должен в состоянии оценить и результат Аналитика (его правильность, полноту и пр.), и метод, которым он его достиг.
    Как мне кажется, это возможно при условии выполнения сравнительно типовых задач. Когда я участвовал в проектах внедрения систем документооборота, то технология внедрения там достаточно стандартные и Руководитель всегда может оценить качество материалов Аналитика, хотя и не может оценить правильность (полноту, точность). Просто потому, что он не знает, какие требования были предъявлены и насколько точно их изложил Аналитик. И не знает он до тех пор, пока вдумчивый заказчик их не проверит (в форме подписания документа с требованиями или проверки системы, в которой эти требования реализованы). Т.е. успешность опыта или провал (зеленая или красная линии) мы часто сможем определить значительно позже завершения работы Аналитиком.
    Есть сложности с определением уровней «Оптимизирует применение» и «Адаптирует и развивает». Отличить «Осознанные действия» от «Мне повезет» может быть не так просто. По результатам этого, как правило, не видно, а другого источника информации, кроме, собственно, самого аналитика – нет.
    Еще одна проблема для нас состояла в том, что производительность сотрудников часто сильно отличается. Причем у одного сотрудника в разных областях знания она тоже, как правило, разная. В результате трудоемкость – это либо субъективная оценка Руководителя, либо очень примерный показатель.
    Последняя проблема для нас оказалась в уникальности большинства решаемых задач. В таких задачах ни Руководитель, ни Аналитик не обладают опытом, поэтому и оценивать что-либо очень трудно.

    Сталкиваетесь ли вы с такими проблемами?
    Как решаете их?

    ОтветитьУдалить
    Ответы
    1. Дмитрий, спасибо за комментарий!

      Про оценку опыта. То, как мы сейчас пытаемся это делать, выглядит следующим образом. Оценку качества и эффективности работы аналитика дает не только Руководитель (ресурсный менеджер или менеджер проекта), а те люди, которые непосредственно используют результаты работы аналитика. Причем это не только люди от Бизнеса, но и люди из проектной команды - как минимум лид разработчик и лид тестер. Ведь именно они могут сказать, на сколько качественно в итоге были написаны требования.Это субъективная оценка, но она ближе всего к истине, поскольку Бизнес обычно довольно быстро узнает в описанных требованиях ожидаемое решение, а вот команда - нет. При передаче требований в команду как правило начинают всплывать вопросы об однозначности, непротиворечивости, понятности, детальности и т.п. Т.е. о всем том, что существенно определяет качество требований к реализации программного обеспечения.

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

      Удалить
    2. Дмитрий, как Вы используете подобную карту для формирования команд? Тема тоже довольно интересная, по крайней мере для меня :)

      Удалить
    3. Между"Оптимизирует применение" и "Адаптирует и развивает" действительно довольно сложно увидеть разницу. Здесь я обычно иду следующим образом. Я предполагаю, что роста на уровень "Адаптирует и развивает" человек может достичь тогда, когда:
      - он самостоятельно ставит аналитику на проекте (т.е. он либо работает на проекте "с нуля", либо призван отрефакторить процесс на проблемном проекте);
      - проект, на котором он этим занимается, имеет особенности, не позволяющие применить классические подходы к выполнению задач (либо ограничивающие такое применение);
      - специалист умеет растить людей до уровня "Оптимизирует применение", поскольку без глубокого понимания технологии и способности ее гибко использовать вырастить человека на этот уровень очень сложно.

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

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

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

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

      Удалить
    5. У нас есть разные проекты / виды деятельности: сопровождения ранее созданных систем, проектирование и создание новых, участие в проработке решения на ранних стадиях (до старта проекта), ИТ-консалтинг, иногда, даже бизнес-консалтинг.

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

      Обычно, раз-два в год (иногда чаще) мы корректируем карту и заполняем ее. Совсем "планово" у нас как-то не получается.
      Чаще карта заполняется по тем, кто активно работает над своим развитием и им требуется постоянная обратная связь и более частая фиксация успехов.
      Заполняют независимо ключевые сотрудники и руководители, которые непосредственно работают с сотрудником, а потом они сопоставляют результаты и вырабатывают консолидированную оценку. Иногда, только непосредственный руководитель.
      Каждый сотрудник может увидеть свой результат (раздел «Личные качества», опять же по опыту, не показываем).

      • Квалификация – специализация. По основным областям указывается квалификация: знаю, умею, обладаю навыком, осознанно применяю (то, что у вас называется «Оптимизирую») и умею создавать (у вас – «Адаптирую и развиваю»).
      • Квалификация – общая (качественная оценка: Высокая, Средняя, Низкая):
      - Производительность
      - Стабильность результата (прогнозируемость результата, отсутствие большого количества ошибок)
      - Коммуникативные навыки
      - Умение работать в команде
      - Умение обучать
      - Умение структурировать действительность (это спорный пункт, но есть люди, обладающие навыком наводить порядок во всем, к чему они прикасаются).
      • Личные качества (качественная оценка: Высокая, Средняя, Низкая)
      - Проактивность / активность / реактивность
      - Движим мотивацией или стимуляцией
      - Лидерские качества
      - Обучаемость
      - Самообучаемость
      - Доминирующие и дополнительные центры жизни: Работа, личные хобби, семья, родители и пр.
      - Рассеянность / сосредоточенность (сильно влияет на количество ошибок, особенно на сложных задачах)

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

      Какие проблемы:
      1. Самая большая – самим сотрудникам такая оценка не всегда нужна. Она их напрягает.
      2. Субъективность оценки – тут все понятно.
      3. Средняя трудоемкость – 10 минут на человека на заполнение и примерно 20-30 минут на обсуждение результатов.
      4. Карта компетенции частично меняется во времени, что не позволяет сравнивать результаты.

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

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

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

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

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

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

      Про изменение карты компетенции я напишу отдельно, тема довольно интересная.

      Удалить
    7. Поясните более подробно, как вы ограничиваете субъективность оценки за счет использование матричной структуры управления.
      Насколько типовые у вас проекты? Насколько высока ротация сотрудников между проектами/менеджерами?

      Вот некоторые из проблем, которые мы не знаем, как решать. Радует то, что они не фатальны и удается субъективно компенсировать эффекты. Как их решаете вы?

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

      Удалить
    8. Дмитрий, матричная структура позволяет разнести оценку на два этапа. На первом этапе работу аналитика оценивает руководитель проекта. Он, как правило, не должен оценивать квалификацию аналитика, он оценивает эффективность и полезность аналитика на своих проектах.

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

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

      Удалить

Отправить комментарий

Популярные сообщения из этого блога

Карта компетенции аналитика

Драйв

Оценка эффективности работы руководителя проектов