Грейды: оцифровка программистов. Приложение 2, или Русская рулетка
(Предыдущие статьи серии: Часть I, Часть II, Приложение 1: Перфотаблицы Хея.)
В 2006 г. в России стартовал проект по разработке профессиональных стандартов для ИТ-отрасли при участии министерств информационных технологий и связи, образования и Ассоциации Предприятий Компьютерных и Информационных Технологий (АП КИТ). Финансирование проводилось за счет ИТ-компаний спонсоров, в том числе Intel, IBM, Microsoft, IBS, 1C, Яндекс, Лаборатория Касперского и других. Минимальный взнос спонсора составлял от 400 тыс. руб.
Планировалось разработать принципы и базовый классификатор, единый глоссарий компетенций, новые профессиональные стандарты в требуемом формате, а также создать интернет-ресурс с базой стандартов, поиском и навигацией.
Первая версия стандартов была опубликована в 2007 году, а в мае 2011 года стандарты с небольшими изменениями были утверждены комиссией при РСПП (Российском союзе промышленников и предпринимателей).
Стандарты представляют собой набор таблиц с общими требованиями по уровням квалификации, перечнем должностных обязанностей и соответствующих им основных знаний, умений и навыков, а также необходимые качества личности. Для каждого уровня каждой профессии — одна таблица.
Следует отметить, что сразу бросается в глаза смысловая погрешность, ведь умения — это совокупность знаний и навыков, необходимых для применения знаний. В российских же стандартах знания, умения и навыки — понятия одного уровня.
Заявляется, что стандарты «сопрягают квалификационные требования, необходимые для выполнения должностных обязанностей, с требованиями к уровню образования». В стандартах представлены 9 профессий:
- Программист;
- Системный архитектор;
- Специалист по информационным системам;
- Системный аналитик;
- Специалист по системному администрированию;
- Менеджер информационных технологий;
- Менеджер по продажам решений и сложных технических систем;
- Специалист по информационным ресурсам;
- Администратор баз данных.
Для каждой из них определено несколько квалификационных уровней. Для программистов — 4, а для менеджеров по продажам решений — 7, что «как бы намекает» на пропорции состава разработчиков стандартов.
Сообщается, что стандарты исходят из наличия двух групп компетенций:
1) универсальные: общенаучные, инструментальные, социально-личностные и общекультурные
2) профессиональные: проектная, аналитическая, производственно-технологическая, организационно-управленческая, научно-исследовательская деятельности;
и 5 областей компетенций:
- Современные информационные технологии;
- Макро- и микроэкономика (функционирование предприятий на рынке);
- Особенности отрасли, вида деятельности предприятий-заказчиков;
- Взаимодействие с заказчиком: предприятием в целом и его представителями (коммуникативные навыки);
- Управление проектами, организация работ (в том числе технологии проектного внедрения).
Считается, что эти стандарты могут быть полезны 4 группам:
- работодатели;
- сфера образования;
- работники;
- государство (last, but not least).
Не будем присоединяться к хору критиков, указывающих на ряд методологических погрешностей (к примеру, выше сказано о каше из знаний, умений и навыков), местами слишком общее описание (вроде «Современные технологии в области работы специалиста»), плоскую структуру требований и их неполноту (отсутствие упоминания таких областей как архитектура вычислительных систем, алгоритмы и анализ сложности) и пеняющих авторов стандартов за чрезмерное увлечение требованиями из областей менеджмента, педагогики, психологии и конфликтологии в ущерб коренным знаниям ИТ-профессий.
Вместо этого призовем на помощь сферического PHP-программиста из предыдущих приложений, а также двух его собратьев (младшего и старшего), и протестируем российский стандарт для задачи классификации в рамках небольшой проектной команды.
Три сферических богатыря
Так как в цели статьи не входит комплексное тестирование, а лишь простая иллюстрация, то выделим из стандарта для программистов только перечень основных требований (на субъективный взгляд). Вариант такого списка представлен в таблице, нумерация задач изменена в целях удобства просмотра, наименования и квалификационный уровень задач в основном соответствуют оригиналу.
Определим каждому из участников теста перечень задач, обозначая в списке как тип и уровень, и посчитаем сумму баллов как сумму уровней задач (очевидно, что перечень подобран достаточно произвольно и его, как и вес баллов, можно варьировать, исходя из реально выполняемых задач).
Тип задач | Уровень | Наименование задач | Младший | Средний | Старший |
Анализ требований и создание сценариев использования проекта | |||||
1 | 1 | Участие в анализе требований и создании сценариев использования проекта | 1 | ||
1 | 2 | Сбор и анализ требований, создание сценариев использования проекта | 2 | ||
1 | 4 | Анализ требований и создание сценариев использования проекта | 4 | ||
Разработка требований и спецификаций | |||||
2 | 1 | Участие в разработке требований и/или спецификаций к программному проекту | 1 | ||
2 | 2 | Разработка требований и/или спецификаций к программному проекту | 2 | ||
2 | 4 | Контроль разработки требований и спецификаций к программному проекту | 4 | ||
Разработка | |||||
3 | 1 | Разработка кода программного проекта на основе готовых спецификаций на уровне модулей | 1 | ||
3 | 2 | Разработка кода программного проекта на основе готовых спецификаций | 2 | ||
4 | 2 | Разработка и отладка сосредоточенных, распределенных и многопоточных приложений | 2 | 2 | |
5 | 1 | Участие в интеграции программных компонент в единое целое | 1 | ||
5 | 2 | Интеграция программных компонент | 2 | 2 | |
5 | 4 | Контроль интеграции программных компонент | 4 | ||
Отладка и тестирование | |||||
7 | 1 | Отладка и тестирование кода на уровне модулей | 1 | ||
7 | 2 | Отладка кода на уровне модулей, межмодульных взаимодействий и взаимодействий с окружением | 2 | 2 | |
7 | 4 | Контроль разработки кода программного проекта на основе готовых спецификаций | 4 | ||
8 | 1 | Разработка тестовых наборов и тестовых процедур | 1 | ||
8 | 2 | Планирование тестирования и разработка тестовых наборов и процедур | 2 | 2 | |
8 | 3 | Разработка и адаптация к проекту средств автоматизации тестирования | |||
Измерение характеристик программного проекта | |||||
9 | 1 | Участие в измерении характеристик программного проекта | 1 | ||
9 | 2 | Измерение характеристик программного проекта | 2 | ||
9 | 3 | Планирование выполнения и процесса измерения проекта | 3 | ||
9 | 4 | Анализ результатов выполнения проекта на основе метрик | 4 | ||
Документирование | |||||
10 | 1 | Участие в ревьюировании технических документов | 1 | ||
10 | 2 | Ревьюирование технических документов | 2 | ||
10 | 3 | Разработка и ведение проектной и технической документации | 3 | 3 | |
10 | 4 | Контроль разработки и ведения проектной и технической документации | 4 | ||
Эффективность | |||||
11 | 2 | Анализ эффективности инструментальных средств для проекта | |||
12 | 2 | Инспекция программного кода | 2 | ||
12 | 4 | Участие в инспекциях программного обеспечения | 4 | ||
13 | 4 | Анализ и оптимизация кода c использованием специальных инструментальных средств | 4 | ||
Взаимодействие с заказчиками | |||||
14 | 3 | Сдача документации и программного обеспечения заказчику | 3 | ||
14 | 4 | Взаимодействие с заказчиками в ходе всего проекта | 4 | ||
Участие в управлении | |||||
15 | 2 | Обучение и консультирование других сотрудников | 2 | 2 | |
16 | 3 | Руководство небольшой проектной группой | 3 | ||
16 | 4 | Руководство проектной группой | |||
17 | 3 | Участие в совершенствовании процесса разработки в рабочих группах и технических советах | 3 | ||
17 | 4 | Участие в разработке корпоративных и проектных стандартов разработки | |||
Сумма | 8 | 28 | 58 |
Вуаля! Простая система классификации готова.
Рулетка или русская?
Может возникнуть вопрос по названию статьи: российский ИТ-стандарт — это рулетка в смысле «рулетка» или старинная гусарская забава? По мнению автора, вышеприведенный пример доказывает, что при всех своих недостатках и низкой точности классификации, российский ИТ-стандарт вполне оригинален и годен к применению, как минимум, в качестве точки отсчета.
Конечно, в нем не хватает более детальной проработки ряда требований, учета нюансов стека технологий, а для сложных задач классификации параметры все же должны иметь иерархическую структуру. Тем не менее, на базе российского ИТ-стандарта возможно быстро и с относительно малыми затратами создавать простые системы классификации и ранжирования внутри ИТ-компании, если требования к точности и обоснованности ранжирования невысоки.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
23 коментарі
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.