Грейди : оцифровка програмістів. Додаток 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 |
Вуаля! Проста система класифікації готова.
Рулетка чи російська?
Може виникнути питання за назвою статті: російський ІТ-стандарт - це рулетка в сенсі «рулетка» або старовинна гусарська забава? На думку автора, вищенаведений приклад доводить, що при всіх своїх недоліках і низької точності класифікації, російський ІТ-стандарт цілком оригінальний і придатний до застосування, як мінімум, в якості точки відліку.
Звичайно, в ньому не вистачає більш детального опрацювання ряду вимог, обліку нюансів стека технологій, а для складних завдань класифікації параметри все ж повинні мати ієрархічну структуру. Тим не менш, на базі російського ІТ-стандарту можливо швидко і з відносно малими витратами створювати прості системи класифікації і ранжирування усередині ІТ-компанії, якщо вимоги до точності та обгрунтованості ранжирування невисокі.
Опубліковано: 29/05/12 @ 11:51
Розділ Різне
Рекомендуємо:
Не працює плагін qTranslate
Організаторський звіт про EPAM Open Day , присвяченому cloud computing
Нова система обміну контекстними посиланнями та статтями - недорого ;)
У Росії Мадонна стала « платинової »
2 червня, Донецьк - GDG / GTUG Donetsk