Оценка и развитие персонала в it-компании

Чтобы развивать сотрудников, необходимо уметь их оценивать; на базе этой оценки можно строить планы развития специалистов. В IT-секторе основной капитал компании — это высококвалифицированные специалисты, поэтому руководству жизненно важно знать, какую работу кому из них можно поручить. А значит, необходимы серьезные методы оценки компетенций.

Р аботающие в IT-индустрии люди уделяют очень много внимания своему профессиональному и личностному развитию, поэтому для адекватной оценки навыков здесь нужны кастомизированные — «подогнанные» под потребности отрасли методы. Чем более индивидуализированные, «штучные» услуги предлагает компания своим клиентам, тем более квалифицированные (а часто и уникальные) специалисты в ней работают. Поэтому ее эйчарам нужны собственные разработки — типовые «стандартные» методы оценки персонала им не подходят: к своим внутренним клиентам они обязаны подходить так же уважительно, как и к внешним… При этом IT-эйчары должны уметь не только объективно оценить текущий уровень квалификации каждого специалиста, но и разработать для него план дальнейшего профессионального развития и карьерного роста.

Отраслевой стандарт

Оценка «айтишников» — это не тот случай, когда «сапожник без сапог»: эксперты регулярно предлагают практикам огромное количество технологий и методов, большинство из которых вскоре тихо уходят с рынка. Плохо это или хорошо? Разумеется, конкурентный отбор помогает провайдерам создать оптимальный продукт, но начинающий эйчар в ситуации избыточного предложения может прийти к выводу, что стабильный метод оценки персонала в этой области разработать невозможно. И ошибется!

При более внимательном рассмотрении обнаруживается, что при внешней изменчивости продуктов основы — методология ведения проектов, разработки, тестирования и администрирования программного обеспечения (ПО) — остаются достаточно стабильными. Например, в области разработки есть две линии развития основной методологии: одна идет от RUP к CMM, другая включает в себя семейство более динамичных подходов, таких как Agile и Scrum. «Исторически» сложилось, что в «Миратех» используется линия RUP-CMM, поэтому и наша система оценки компетенций «идейно» восходит к стандартам CMM.

Стандарты cmm

В середине 1990-х годов правительство США сделало запрос на создание метода оценки — для выбора лучших субподрядчиков в области разработки программного обеспечения (ПО). Проанализировав ситуацию с госзаказами в этой области, эксперты американского «Института программной инженерии» (Software Engineering Institute, SEI) пришли к выводу, что проблема заключалась не столько в отсутствии критериев для выбора провайдера, сколько в неспособности компаний управлять большими проектами: во многих из них разработка ПО выполнялась со значительным опозданием и превышением бюджета…

Для улучшения внутренних процессов в компаниях, занимающихся разработкой ПО, эксперты SEI совместно с Mitre Corporatio№ в 1986 году предложили свой подход — оценку зрелости процессов. Они выпустили краткий обзор процессов разработки ПО (с описанием уровней их зрелости), а также подготовили опросник, предназначенный для выявления тех участков работы, на которых требовались улучшения.

Поскольку большинство IT-компаний восприняло предложенный опросник как готовую модель для оценки качества разработки ПО, эксперты SEI доработали его до целостной модели, назвав «Модель  оценки зрелости процессов компаний — разработчиков ПО» (Capability Maturity Model for Software CMM). Первая версия отраслевого стандарта СММ 1.0 была представлена в 1991 году. Американское профессиональное сообщество разработчиков поддержало идею, поэтому теперь CMM (Versio№ 1.1) активно используется во всем мире.

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

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

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