Карта компетенции аналитика
Понимание того, что из себя должен представлять аналитик и как он должен развиваться в смысле приобретения новых знаний и навыков, у всех более не менее существует. Но проблема заключалась в том, что любые попытки как-то документировать это понимание, чтобы оно было понятно и прозрачно всем, включая аналитиков, не удавалось. У меня получались либо какие-то огромные феерические формализмы, совершенно не применимые в реальной жизни. либо размытые мало понятные модели.
Первое, с чем сталкиваешься при попытке определить требования к аналитику, является тот момент, что эти требования разваливаются на три большие категории - требования к теоретическим знаниям, требования к практическим навыкам и требования к опыту использования знаний и навыков.
По сути эти категории образуют слоеный пирог, в основе которого лежат теоретические знания. На основе знаний аналитик пытается что-то сделать и приобретает опыт. Опыт оттачивает навыки, что является основой и движущей силой развития специалиста: научившись безукоризненно делать что-то, хочется либо научиться это что-то делать совершеннее, либо научиться чему-нибудь еще.
Знания - навыки - опыт
Что из всего этого первично?
Первичны знания. Прежде, чем что-то попытаться сделать, человек в любом случае пытается понять, как он это может сделать. А наиболее любознательные еще и пытаются найти ответ на вопрос - почему именно так это надо делать? Т.е. всегда перед действием в голове появляется некоторое осоЗНАНИЕ того, как это можно сделать.
Можно ли у специалиста развивать навыки, не вкачивая в него знания? Нет. Любая попытка привить человеку какие-нибудь навыки является обучением, в ходе которого человек обретает знания.
Можно ли оттачивать навыки без опыта? Нет. Навык - это в первую очередь способность эффективно использовать на практике теоретические знания. Много знать и много уметь - это противоположные точки, разделенные опытом.
А теперь посмотрим на аналитика с точки зрения руководителя проекта. С этой позиции важно, чтобы аналитик обладал в должной мере необходимыми навыками и имел положительный опыт их использования, что в совокупности позволит ему эффективно решить проектные задачи. При этом руководителю проекта совершенно все равно, знает ли человек теорию, важно лишь то, чтобы он качественно делал свою работу.
Получается, что для того, чтобы оценить степень соответствия аналитика определенному требованию, совершенно нет необходимости определять уровень его теоретической подготовки, поскольку такой подход не даст объективного представления о квалификации специалиста. Необходимо оценить его умение выполнять работу так, чтобы соответствовать этому требованию (навык) и консолидировать эти оценки для оценки опытности аналитика в использовании этого навыка. Таким образом, оценка соответствия аналитика конкретному требованию лежит в плоскости “навык использования знаний – опыт применения навыка”.
Знания
Какие знания нужны аналитику? Все зависит от того, какие требования мы к нему предъявляем. Т.е. от специфики деятельности компании. Для заказной разработки я бы выделил следующие домены знаний (но они легко могут меняться от компании к компании):
Дальше я столкнулся с проблемой. Для того, чтобы получить полноценную карту экспертизы, мы предприняли попытку детализировать эти домены, расписав каждый из них в виде набора требований к аналитику. В итоге получилась огромная таблица, содержавшая более 230 строк и потому совершенно не пригодная для промышленного использования. Т.е. когда у тебя в отделе 5 человек, то ты можешь позволить себе два раза в год оценивать каждого из них по 230-ти позициям. Но когда их под сорок, это становится проблемой.
Именно по этой причине я решил отказаться от детализации доменов знаний "в лоб", а определить требования по другому принципу, идея которого заключается в следующем: аналитик является ресурсом, который привлекается компанией для решения тех или иных проектных задач. Руководитель проекта использует этот ресурс, ресурсный менеджер его предоставляет. Поэтому и требования к аналитику нужно формулировать как к ресурсу, т.е. с позиции потребителя: что я ожидаю от аналитика для того, чтобы он был мне полезен? Причем каждый из этих вопросов обладает конкретным приоритетом, который определяет важность определенных навыков, соответствующих конкретному домену знаний.
Исходя из этого получаем следующий список вопросов (по каждому из доменов вопросы перечислены в порядке убывания приоритета):
Навыки
Я могу ошибаться в правильности использования термина "навыки", но в этом конкретном случае под навыком я понимаю умение специалиста выполнять свою работу. Чем эффективнее человек выполняет свою работу, тем выше его навыки. Поскольку методы работы аналитика определяются его знаниями, то чем выше навыки, тем больше человек знает и эффективнее использует свои знания. Т.е. навык выполнения работы однозначно связан с навыком использования имеющихся знаний.
Как оценить навык использования аналитиком имеющихся знаний? Я для этого различаю четыре уровня:
Карта компетенций
Понимая ступени развития навыков использования знаний, мы можем сформулировать карту компетенций, которая будет выглядеть как некоторая плоскость с системой координат, определяемой доменами знаний и развитием навыков их использования:
Каждая клетка этой карты определяет степень владения навыками практического применения тех или иных знаний.
Карта компетенции для каждого квалификационного уровня будет определяться комбинацией клеток карты компетенций. При этом каждая клетка для каждой квалификации будет иметь свой собственный приоритет, который позволит понимать различие между требованиями к каждой квалификации.
Как вариант, могут быть предложены следующие уровни квалификации:
Степень важности того или иного уровня навыков для домена знаний указана цифрой. Чем выше цифра, тем меньше приоритет. Для юниора карта может быть прочитана следующим образом:
Ну и так далее.
Плюсом такого подхода к формированию карты компетенций является наглядность результата. В его основе лежит демонстрация квалификации специалиста как функции от навыка владения знаниями в предопределенных доменах. Приоретизация навыков позволяет определить их первостепенность и вторичность для определенного квалификационного уровня, что позволяет выстраивать персональный план развития специалиста.
Основной недостаток такой модели - это ее инвариантность к конкретным методам и технологиям, которые используются в рамках доменов знаний. Недостаток вытекает из исходной постановки задачи - идея была построить такую карту, которая была бы применима к аналитику как ресурсу, востребованному на проекте. А для проекта важен не процесс, а результат.
Модель может легко развиваться путем детализации как координат (домены и навыки), так и содержания ячеек (появление требований в ячейках). Но в любом случае это будет усложнять модель, делая ее детальнее, но при этом лишая прозрачности.
Первое, с чем сталкиваешься при попытке определить требования к аналитику, является тот момент, что эти требования разваливаются на три большие категории - требования к теоретическим знаниям, требования к практическим навыкам и требования к опыту использования знаний и навыков.
По сути эти категории образуют слоеный пирог, в основе которого лежат теоретические знания. На основе знаний аналитик пытается что-то сделать и приобретает опыт. Опыт оттачивает навыки, что является основой и движущей силой развития специалиста: научившись безукоризненно делать что-то, хочется либо научиться это что-то делать совершеннее, либо научиться чему-нибудь еще.
Знания - навыки - опыт
Что из всего этого первично?
Первичны знания. Прежде, чем что-то попытаться сделать, человек в любом случае пытается понять, как он это может сделать. А наиболее любознательные еще и пытаются найти ответ на вопрос - почему именно так это надо делать? Т.е. всегда перед действием в голове появляется некоторое осоЗНАНИЕ того, как это можно сделать.
Можно ли у специалиста развивать навыки, не вкачивая в него знания? Нет. Любая попытка привить человеку какие-нибудь навыки является обучением, в ходе которого человек обретает знания.
Можно ли оттачивать навыки без опыта? Нет. Навык - это в первую очередь способность эффективно использовать на практике теоретические знания. Много знать и много уметь - это противоположные точки, разделенные опытом.
А теперь посмотрим на аналитика с точки зрения руководителя проекта. С этой позиции важно, чтобы аналитик обладал в должной мере необходимыми навыками и имел положительный опыт их использования, что в совокупности позволит ему эффективно решить проектные задачи. При этом руководителю проекта совершенно все равно, знает ли человек теорию, важно лишь то, чтобы он качественно делал свою работу.
Получается, что для того, чтобы оценить степень соответствия аналитика определенному требованию, совершенно нет необходимости определять уровень его теоретической подготовки, поскольку такой подход не даст объективного представления о квалификации специалиста. Необходимо оценить его умение выполнять работу так, чтобы соответствовать этому требованию (навык) и консолидировать эти оценки для оценки опытности аналитика в использовании этого навыка. Таким образом, оценка соответствия аналитика конкретному требованию лежит в плоскости “навык использования знаний – опыт применения навыка”.
Знания
Какие знания нужны аналитику? Все зависит от того, какие требования мы к нему предъявляем. Т.е. от специфики деятельности компании. Для заказной разработки я бы выделил следующие домены знаний (но они легко могут меняться от компании к компании):
- Выявление и анализ требований
- Документирование и моделирование требований
- Управление требованиями
- Коммуникации
- Менеджмент
- Предметная область
- Технические знания
Дальше я столкнулся с проблемой. Для того, чтобы получить полноценную карту экспертизы, мы предприняли попытку детализировать эти домены, расписав каждый из них в виде набора требований к аналитику. В итоге получилась огромная таблица, содержавшая более 230 строк и потому совершенно не пригодная для промышленного использования. Т.е. когда у тебя в отделе 5 человек, то ты можешь позволить себе два раза в год оценивать каждого из них по 230-ти позициям. Но когда их под сорок, это становится проблемой.
Именно по этой причине я решил отказаться от детализации доменов знаний "в лоб", а определить требования по другому принципу, идея которого заключается в следующем: аналитик является ресурсом, который привлекается компанией для решения тех или иных проектных задач. Руководитель проекта использует этот ресурс, ресурсный менеджер его предоставляет. Поэтому и требования к аналитику нужно формулировать как к ресурсу, т.е. с позиции потребителя: что я ожидаю от аналитика для того, чтобы он был мне полезен? Причем каждый из этих вопросов обладает конкретным приоритетом, который определяет важность определенных навыков, соответствующих конкретному домену знаний.
Исходя из этого получаем следующий список вопросов (по каждому из доменов вопросы перечислены в порядке убывания приоритета):
- Выявление и анализ требований
- Собирать исходные данные, не упуская важную информацию
- Обрабатывать информацию, не упуская требований
- Формулировать требования однозначно, четко, ясно, прозрачно
- Понимать взаимосвязи / зависимости между требованиями, учитывать их в ходе анализа
- Обеспечивать полноту и непротиворечивость требований
- Документирование и моделирование требований
- Писать понятные, легко читаемые, пригодные к использованию документы
- Строить понятные, легко читаемые, пригодные к использованию модели
- Делать документы и модели, нужные именно этому проекту
- Уметь лаконично и понятно описать модели
- Управление требованиями
- Отслеживать границы проекта
- Отслеживать актуальный статус требований
- Понимать взаимосвязи / зависимости между требованиями, учитывать их в ходе анализа и документирования
- Коммуникации
- Эффективная коммуникация с командой
- Эффективная коммуникация с Заказчиком
- Менеджмент
- Эскалировать проблемы
- Использовать методы, соответствующие потребностям проекта
- Планировать работы
- Отслеживать выполнение
- Управлять рисками
- Предметная область
- Знать и использовать терминологию
- Знать и использовать стандарты / правила / нормативы
- Технические знания
- Учитывать возможности среды реализации при определении требований
- Учитывать при определении требований архитектуру решения
- Использовать типовые для данной предметной области архитектурные решения
Навыки
Я могу ошибаться в правильности использования термина "навыки", но в этом конкретном случае под навыком я понимаю умение специалиста выполнять свою работу. Чем эффективнее человек выполняет свою работу, тем выше его навыки. Поскольку методы работы аналитика определяются его знаниями, то чем выше навыки, тем больше человек знает и эффективнее использует свои знания. Т.е. навык выполнения работы однозначно связан с навыком использования имеющихся знаний.
Как оценить навык использования аналитиком имеющихся знаний? Я для этого различаю четыре уровня:- Знает - специалист обладает знаниями, но пока не может самостоятельно их использовать. Ему нужен наставник или кто-то, кто будет контролировать его работу.
- Применяет - специалист может самостоятельно использовать имеющиеся знания. Это означает, что он делает работу осознанно, понимает, что и зачем необходимо делать. У человека появляется способность к самоуправлению - он может выбрать необходимые методы, принять решения в части той работы, которую выполняет.
- Оптимизирует применение - специалист не просто использует имеющиеся знания, а использует их оптимально, выбирая наиболее применимые в имеющейся ситуации средства и методы. На этом уровне развития сотрудник уже может полноценно выстраивать аналитическую фазу проекта при условии, что проект не требует неординарных подходов к его выполнению.
- Адаптирует и развивает - уровень владения знаниями таков, что человек способен адаптировать методы и технологии, которыми он владеет, к условиям выполнения проекта. По сути человек на этом уровне владения знаниями является экспертом в соответствующей области.
Карта компетенций
Понимая ступени развития навыков использования знаний, мы можем сформулировать карту компетенций, которая будет выглядеть как некоторая плоскость с системой координат, определяемой доменами знаний и развитием навыков их использования:
Каждая клетка этой карты определяет степень владения навыками практического применения тех или иных знаний.
Карта компетенции для каждого квалификационного уровня будет определяться комбинацией клеток карты компетенций. При этом каждая клетка для каждой квалификации будет иметь свой собственный приоритет, который позволит понимать различие между требованиями к каждой квалификации.
Как вариант, могут быть предложены следующие уровни квалификации:
Юниор:
Степень важности того или иного уровня навыков для домена знаний указана цифрой. Чем выше цифра, тем меньше приоритет. Для юниора карта может быть прочитана следующим образом:
- Юниор должен знать методы выявления и анализа требований, знать, как правильно требования документировать и моделировать. Приветствуется, если он имеет навыки применения этих знаний, но совершенно нормально, если он может их применять под контролем лида.
- Желательно, чтобы юниор знал процессы управления требованиями и был знаком с основами коммуникаций. Но для специалиста этого уровня эти знания, а тем более наличие навыков их применения не критично.
Ну и так далее.
Регуляр:
Синьор
Эксперт
Плюсом такого подхода к формированию карты компетенций является наглядность результата. В его основе лежит демонстрация квалификации специалиста как функции от навыка владения знаниями в предопределенных доменах. Приоретизация навыков позволяет определить их первостепенность и вторичность для определенного квалификационного уровня, что позволяет выстраивать персональный план развития специалиста.
Основной недостаток такой модели - это ее инвариантность к конкретным методам и технологиям, которые используются в рамках доменов знаний. Недостаток вытекает из исходной постановки задачи - идея была построить такую карту, которая была бы применима к аналитику как ресурсу, востребованному на проекте. А для проекта важен не процесс, а результат.
Модель может легко развиваться путем детализации как координат (домены и навыки), так и содержания ячеек (появление требований в ячейках). Но в любом случае это будет усложнять модель, делая ее детальнее, но при этом лишая прозрачности.
