Home

Публикация компании SEADMEX

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

Прежде всего, при найме человека не думаем о том, что «нанимаем человека на позицию «Лидер группы разработчиков». Я нанимаю человека с компетенцией «Лидер группы разработчиков» на позицию Разработчик уровня 3. Принципиальных отличий в формулировках вроде бы не видится, но они есть. В чем отличие?

Компетенции

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

Оценки по уровням умений выставляются следующим образом.

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

Поясним определение примером.

Компетенция «System Architect — .NET Platform»

Итак, мне нужен человек, обладающий компетенцией System Architect — .NET Platform. Задаю умения, которыми он должен обладать, и уровень владения этими умениями, который считаю достаточными.

Умения

Технология

1. ASP . NET Programming : 4> (обратите внимание — чтобы соответствовать требованиям компетенции, надо набрать четыре или более баллов)
2. C# Business Logic Programming: 4>
3. WinForms Development: 4>
4. MS SQL Programming: 4 >
5. Alghoritms and data structures: 4>

Навыки общения

1. Interviewing skills: 3>
2. Team work: 3>

Бизнес

1. Presentation skills: 2>
2. Technical writing: 3>

Техники моделирования

• UML language: 3>
• Sparx Enterprise: 3>
• Rational Rose: 2>
• ARIS: 2> (оцпионально )
• ErWin: 2> ( опционально )

Человек с набором таких умений уровня не ниже заданного уровня точно сможет быть системным архитектором. Если не все умения в нужном уровне (например, всю жизнь работал в ErWin и лишь «игрался» со Sparx — то нет никакого сомнения, что он изучит и Sparx) или одного-двух нет (использует нотацию Гейна-Сарсона для моделирования — значит, освоит и UML), то его все равно можно брать, оговорив, что он должен получить эти умения во время программы адаптации (см. Программа Адаптации)

Корреляция компетенции и уровня

С тем, что такое «компетенция», разобрались. Теперь что такое «уровень». Уровень — это не более чем позиция в тарифной сетке.

Для последовательных компетенций определенной компетенции соответствует определенный уровень зарплатной сетки. Примеры последовательных компетенций: Разработчик (Уровень 1 зарплатной сетки) – Ключевой разработчик (Уровень 2) — Архитектор (Уровень 3) и т.д.

Табл. 1. Соотношение уровня и последовательной компетенции (выдумано из головы)

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

Табл. 2. Доплата за параллельную компетенцию (выдумано из головы)

Разработать систему компетенций и (крайне желательно) надбавок в масштабах компании достаточно сложно. Это породит массу вопросов и споров — например, считать Архитектора и Лидера группы последовательными или параллельными компетенциями? Я однозначно считаю, что последовательные: от Лидера требуется гораздо больше умений, чем от Архитектора — все те же знания + организаторские навыки + календарное и сетевое планирование + коммуникации. Однако наверняка найдутся те, кто не согласятся.

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

Определение уровня умений

Теперь самое интересное. Определение действительного, а не задекларированного, уровня умений. Что такое действительный уровень умений? Действительный — это значит «имеющий место быть». Иначе кто-то может задекларировать уровень умений «эксперт», прочитав тонкую брошюрку по теме. Страшно подумать, как «повезет» тем, к кому он попадет на проект... Как определить уровень умений при приеме кандидата? Опять будем смотреть на примере. Пришел к нам на интервью человек, который претендует на компетенцию «Архитектор ПО». Как его проверить? Интервью делим на 2 части — собственно интервью и тест после него.

Интервью

1. Короткое введение . Немного разговоров ни о чем и шуток — чтоб перестал бояться.
2. Обсуждение предыдущих проектов — составить представление о бэкграунде.
3. Теперь начинается самое интересное. Поскольку среди умений есть Навыки презентации на английском языке, то за несколько дней мы просим его подготовить презентацию Management Lesson I've learned hard way (15 минут — не меньше). Оценить ее просто: сделал текст и связно проговорил — 2. Знает общие принципы, вставил картинки в текст и рассказал хорошо — 3. Способен использовать анимацию, связный рассказ, соблюдена логическая структура — 4. Глубокие знания, ну просто «зажег» — 5.
4. Навыки извлечения требований — расспросить меня о том, что должна уметь делать подсистема печати в бухгалтерской системе (по выданной вводной). Расспросил связно и смог из меня вытащить 3 из 5 функций системы, которые я держу в голове — 3, смог вытащить все — 4, смог предложить разделить это все на вкладки или сделать «мастер печати» — 5.
5. Записать это все в виде функциональных требований (Технический писатель). Все требования есть и изложены связным языком — 3, изложены так, что не допускают двойного толкования — 4, изложены и на вопрос «как бы это описать совсем точно, чтоб исключить недопонимание» предложены юзкейсы и сториборды – 5.
6. Если задекларировано знание Sparx или Rational , то просим предложить соотв. модели и отрисовать их в системе, произведя из Sparx такой же список требований и модели в виде документа. (знание UML language и Sparx Enterprise). Отрисовал — 3, отрисовал, сохраняя ссылки, использовал идентификаторы юзкейсов и выделение реквайрементов — 5.
7. Если не знает тулов, просим нарисовать Диаграмму развертывания и классов системы с последнего проекта. Нарисовал — 3, нарисовал диаграммы классов и последовательностей — 4, нарисовал диаграммы взаимодействия — 5.

Теперь тестируем его на предмет знания технологий в BrainBench и после задаем ему дополнительные вопросы и тестовую задачу (имплементация класса и юнит тестов к нему).

«Боевая задача» очень хорошо покажет стиль кодирования и знания алгоритмов и структур данных. «Боевая задача» обычно состоит в том, чтобы разработать нечто, руководствуясь принципами SCRUD — снизу вверх, от таблиц сиквела и хранимых процедур до веб-страницы, отображающей информацию. Этим проверяются след. Умения:

1. ASP .NET Programming: 4>
2. C# Business Logic Programming: 4>
3. WinForms Development: 4>
4. MS SQL Programming: 4 >
5. Alghoritms and data structures: 4>

Вопросы и задачи на интервью можно формализовать и использовать повторно.

Компетенции или умения? (заметки на полях)

А теперь внимание — вопрос: а в чем различие между умениями (skills) и компетенциями (competencies)? Зачем группировать умения в компетенции?

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

Разработчик требований не просто должен уметь писать документы, но также должен уметь извлечь требования из Заказчика.

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

Программа адаптации

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

Кроме «подтягивания» уровня во время этой программы он изучает следующие вещи:

1. Обзорно — процессы разработки внутри компании.
2. Конкретно — PWA и групповой узел проекта и свои действия и обязанности в нем.
3. Разделение работы внутри группы и его обязанности.
4. Порядок работы в группе — VSS , подходы к моделированию, инструменты, порядок и время сборки билдов и т.п.

На все время адаптации у него есть куратор (как правило, тим лид или key developer группы, в которую он пришел). Куратор проводит несколько уроков, дает задания на закрепление и консультирует в повседневной работе.

По хорошему конечно очень было бы хорошо если бы был недельный курс для каждой компетенции. Зачем так? Например, пришел новый супер-архитектор. Он привык использовать для обозначения требования символ юзкейса, а мы уже используем символ реквайремента (новая версия языка UML, 2.0). Надо ему рассказать, как его использовать и как устанавливать трэйсабилити — а то он будет делать по своему и всех путать. Вообще же : «Better ways to achieve convergence of method are Training: People do what they know how to do. If you give them all a common core of methods, they will tend use them.» (Peopleware, 2 nd Edition). Я считаю, что каждой уважающей себя компании уже пора иметь корпоративную систему тренингов (набор курсов для каждой компетенции), собственных или отданных на аутсорсинг тренинговой компании. При этом, конечно, крайне желательно договориться об адаптации тренингов под конкретную тренинговую компанию.

Аттестации

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

Кстати, возможно, обновленные балы его компетенции позволят назвать его «экспертом» (см. Ниже).

Отдельной оценкой является Team Work (работа в команде) — социометрическое исследование на тему, сколько членов команды проекта (сотрудников отдела) принимало или отторгало данного человека. Это и многое другое является основанием для начисления баллов в Программе продвижения руководителей, но это тема отдельного большого документа. Могу написать, если интересно.

Также хочется предостеречь от проставления баллов экзаменационным методом советского ВУЗа – по личному мнению преподавателя. Гораздо более целесообразно проводить нечто вроде тестов, которым подвергают Microsoft или Novell. Если уж никуда не деться от аттестации человеком — то попытайтесь придумать что-то, ограждающее от субъективизма аттестующих.

Эксперты

Человек, у которого самый большой балл в данной компетенции, является экспертом на этот квартал. Он получает некое вознаграждение и новые обязанности, как-то: консультирование других, участие в SEPG (группа разработки процессов) или аналогичной тематической группе. Еще одна обязанность — внимание! — обновить существующий тренинг его тематики (например, Leading Development Team для Лидера группы) своими личными идеями и лучшими практиками и прочесть его. Естественно, перед тем, как читать, он пройдет тренинг для тренеров и несколько раз потренируется.

Ресурсное планирование

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

Рис 1. Простой пример прогноза доступности компетенции.

На рис 1. приведен простой пример ресурсного прогноза, выполненного на основании данных из системы управления проектами организации ( EPMS , Enterprise Project Management System ). Зеленая линия — сколько часов рабочего времени специалистов с компетенцием System Architect — . NET Platform нам доступно в месяц. Синяя линия — на сколько часов обладатели этой компетенции используются по прямому назначению (как специалисты-архитекторы в .NET; исходя из доступности 160 часов в месяц). Красная прерывистая линия — полиноминальный трэнд, отрисованный по данным об использовании (задачи на конкретных проектах).

Соответственно для того, чтобы определить «точку дефицита» данного ресурса, достаточно найти пересечение красной и зеленой линий. Это февраль 2006го, значит, в феврале у нас возникнет «ресурсный голод» на специалистов System Architect — . NET Platform . Логично заранее принять меры для того, чтобы подготовить новых специалистов к этому времени.

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

Компетенции как основа кадровой политки

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

Если Вы сейчас думаете, как организовать свой отдел разработки или компанию, специализирующуюся на разработке ПО — то советую начать с разработки системы компетенций. А уже отталкиваясь от нее, Вам будет легко выстроить «зарплатную сетку», спланировать потребности в ресурсах и впоследствии выстроить стройную систему ресурсного планирования.

Желаю удачи!