Я в эти выходные внимательнее заглянул в компетенции SFIA, и сейчас делюсь впечатлениями, имея ввиду потенциал использования этого у нас в компании. Потому что впечатления - положительные.

Надо отметить, что в целом мы идем в ногу со временем. SFIA появилась в 2003 году, а мы в компании принимали положение о разрядах в конце 2004 года. Правда, как у нас водится - относительно оригинальные, но был ли тогда общедоступный сконцентрированный мировой опыт - неясно.

Тем не менее, сейчас такой мировой опыт - есть, и правильно приводить внутренние конструкции к нему, отступая только сознательно в тех местах, где для этого имеются существенные причины. Мы, собственно, уже имеем определенные проблемы с нашей квалификацией "инженера", для которой нет аналогов и потому ее необходимо переводить при каждом разговоре с внешним миром. Думаю, SFIA - не единственная возможная платформа для наведения таких мостов, но российские профессиональные стандарты, к сожалению, оказались кривоватыми и использовать их как базу - не хочется, а SFIA - общедоступна, компактна и мне попалась. Если кто вытащит альтернативы - не вопрос.

Компания - растет, насколько я представляю, на повестке дня стоит рефреш старых стандартов по аналитикам и руководителям, и у меня есть предложение использовать для этого некоторую общемировую базу, а не продолжать конструировать собственную. Заодно понять - кто есть наш инженер с точки зрения всего мира.

Еще одна область возможного применения - более четкое деление обязанностей внутри компании. Это процесс, связанный с нашей continuis reorganization. Авторы SFIA подумали и поделили весь спектр IT-деятельности на 90 областей с уровнями внутри, и, в общем, ничего не забыли. Там есть и админы, образование, управление ресурсами, взаимодействие с клиентами и поставщиками, в общем, все то, о чем Володя периодически спрашивал "где это в SCRUM". Эти части - они есть объективно, а дальше надо провести границы - чем занимаются команды, что на профессиональной инфраструктуре, что на различных рабочих группах. И деление тут не только по областям, но и внутри области. Например, 2-3 уровень компетенции 79 PROF Programme and project support office у нас возложены на команду - в виде burndown, доски, планирования и ретры, а далее акцент смещается к менеджерам. Тоже самое можно сказать о 57 SMLO Service level management.

Заметим, что деление на компетенции тут местами непривычно (посмотрите на упомянутые выше компетенции), и есть большой соблазн в него не погружаться, а провести свои границы. Но дело в том, что о своих границах - у каждого собственные представления и их провести - непросто. А дальше еще их надо будет объяснять... Так что использование уже выполненного разделения имеет свои преимущества. Тем более, что компетенции, в которых говорит SFIA - это не должности, и если мы считаем на определенной позиции совмещать несколько смежных умений, то артефакты, которые нужны для коммуникации при их разделении меняют смысл.

Итак, детали.

Семь уровней SFIA хорошо соответствуют уровням разрядов у нас в компании, если начинать со второго.

1 - follow: у нас такого нет, по сути стажер на испытательном сроке, работа под плотным присмотром

2 - assist: младший разработчик/аналитик-тестировщик/инженер сопровождения - работа под детальным руководством. Но собственные платы на коротком горизонте - есть, и работа в команде тоже..

3 - apply: разработчик/аналитик/инженер - работа в соответствии с общими указаниями

4 - enable: ведущий разработчик/ведущий аналитики - работа в заданном направлении при ясной области ответственности. Планирование собственной работы.

5 - ensure, advise: руководитель группы (по сути это "младший" руководитель проекта) - работа в общем направлении, полная ответственность за технические аспекты или проект, управление командой, делегация ответственности. Включая выполнение работы группой к сроку с качеством.

6 - initiate, influence: руководитель проекта (по сути это "старший" руководитель проекта, сейчас руководитель группы проектов) - автономная работа в заданной области, включая технику, бюджет и качество.

7 - set strategy, inspire, mobilise: руководитель направления - полная ответственность за значительную область работы, включая формирование политики и стратегии.

Напомню, в SFIA описание уровней сквозное по всем компетенциям, и для каждого из уровней есть описание по 4 характеристикам -

• Autonomy - это способность к самостоятельным действиям в заданном направлении
• Influence - это уровень взаимодействия с окружением - командой, коллегами, заказчиками, и уровень влияния на них
• Complexity - сложность и нестандартность решаемых задач, умение учитывать различные аспекты
• Business skills - это, собственно, демонстрируемый уровень работы.

Соответствие с нашей шкалой достаточно хорошее. Только исторически у нас планка ведущего разработчика несколько занижена, а руководитель группы все-таки не столь нагружен в части работы с клиентами. Что касается высших технических уровней Программиста-эксперта и Архитектора, то в SFIA есть существенный акцент на внешнюю составляющую их деятельности, то есть люди на этих позициях не просто знают, но и активно несут свое знание, даже не занимаясь руководством. При этом как правило речь идет о 5 и 6 уровне по SFIA.

Теперь по самим компетенциям. В SFIA их 90, и они покрывают IT-область. Из них уверено выделяются компетенции, которые нас интересуют. Напомним, что компетенция - не есть должность, это просто некоторое направление деятельности, которое считается достаточно отличающимся от других, чтобы его стоило выделить. Я приведу далеко не полный список, и не буду уделять большого внимания старшим компетенциям, в которых присутствуют только верхние разряды - просто не успел.

Начнем с разработки и смежных компетенций.

41 PROG - Programming/software development, level 2-5

The design, creation, testing and documenting of new and amended programs from supplied specifications in accordance with agreed standards.

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

40 DBDS - Database/repository design, level 2-6

The specification, design and maintenance of mechanisms for storage and access to both structured and unstructured information, in support of business information needs.

В наших проектах - тесно связана с разработкой, и разработчик, как правило, должен ей обладать.

36 DTAN - Data analysis, level 2-5

The investigation, evaluation, interpretation and classification of data, in order to define and clarify information structures which describe the relationships between real world entities. Such structures facilitate the development of software systems, links between systems or retrieval activities.

Это - смежная активность между разработчиком и аналитиком. Крупноуровневая схема обычно возникает на ранней стадии проектирование, а дальше нужно ее развитие и уточнение.

38 DESN - Systems design, level 2-6

The specification and design of information systems and the design or selection of components to meet defined business needs, retaining compatibility with enterprise and solution architectures, conforming to corporate standards, within constraints of cost, security and sustainability.

Еще одна смежная активность разработчик - аналитик.

Чисто аналитические активности этапа постановки задачи.

37 REQM - Requirements definition and management, level 2-6

The definition and management of the business goals and scope of change initiatives. The specification of business requirements to a level that enables effective delivery of agreed changes.

32 BSMO - Business modelling, level 2-6

The production of abstract or distilled representations of real world/business situations to aid the communication and understanding of existing, conceptual or proposed scenarios. Predominantly focused around the representation of processes, data, organisation and time. Models may be used to represent a subject at varying levels of detail/ decomposition.

Теперь пойдем в другую сторону - выпуск версий, внедрение и сопровождение.

60 RELM - Release management, level 3-6

The management of the processes, systems and functions to package, build, test and deploy changes and updates which are bounded as ?releases? into the ?production? environment establishing or continuing the specified Service, to enable controlled and effective handover to Operations and the user community.

Выпуск релизов и обновлений тесно интегрирован в нашу разработку.

45 TEST - Testing, level 2-6

The concurrent lifecycle process of engineering, using and maintaining testware (test cases, test scripts, test reports, test plans, etc) to measure and improve the quality of the software being tested. Testing embraces the planning, design, management, execution and reporting of tests, using appropriate testing tools and techniques and conforming to agreed standards (such as ISO 29119), to ensure that new and amended systems, configurations, packages, or services, together with any interfaces, perform as specified.

Тестирование, оно у нас обычно отделено от разработки, но есть тренды к автоматизации этого процесса.

59 CHMG - Change management, level 3-5

The management of change to the service infrastructure including service assets, configuration items and associated documentation, be it via request for change (RFC), emergency changes, incidents and problems, so providing effective control and mitigation of risk to the availability, performance, security and compliance of the business services impacted.

Здесь - проектирование внедрения и вообще внесения изменений в IT-ландшафт

70 USUP - Service desk and incident management, level 1-5

The processing and coordination of appropriate and timely responses to incident reports, including channelling requests for help to appropriate functions for resolution, monitoring resolution activity, and keeping clients appraised of progress.

Простое сопровождение

64 ASUP - Application support, level 2-5

The provision of application maintenance and support services. Support may be provided both to users of the systems and to service delivery functions. Support typically takes the form of investigating and resolving issues and providing information about the systems. It may also include monitoring their performance. Issues may be resolved by providing advice or training to users about an application's functionality, correct operation or constraints, by devising work-arounds, correcting faults, making general or site-specific modifications, updating system documentation, manipulating data, or defining enhancements - often in close collaboration with the system's developers and/or with colleagues specialising in different areas, such as Database administration or Network support.

Сопровождение сложное

69 PBMG - Problem management, level 4-5

The resolution of incidents and problems throughout the information system lifecycle, including classification, prioritisation and initiation of action, documentation of root causes and implementation of remedies.

Решение проблем при сопровождении

Я перечислил 12 из 90. Кроме них есть множество компетенций, необходимых компании и отдельным проектам в той или иной мере:

• технических - портирование систем, интеграция, управление конфигурациями или usability разных видов;
• управленческих - ведение проектов, взаимодействие с клиентами, менеджмент качества и улучшения процессов, управление компанией в крупном;
• инфраструктурных - администрирование, маркетинг, образование персонала и другие.

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