Грейды: оцифровка программистов. Приложение 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 |
Вуаля! Простая система классификации готова.
Рулетка или русская?
Может возникнуть вопрос по названию статьи: российский ИТ-стандарт — это рулетка в смысле «рулетка» или старинная гусарская забава? По мнению автора, вышеприведенный пример доказывает, что при всех своих недостатках и низкой точности классификации, российский ИТ-стандарт вполне оригинален и годен к применению, как минимум, в качестве точки отсчета.
Конечно, в нем не хватает более детальной проработки ряда требований, учета нюансов стека технологий, а для сложных задач классификации параметры все же должны иметь иерархическую структуру. Тем не менее, на базе российского ИТ-стандарта возможно быстро и с относительно малыми затратами создавать простые системы классификации и ранжирования внутри ИТ-компании, если требования к точности и обоснованности ранжирования невысоки.
23 коментарі
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.