Польза должностной инструкции

В фирме появляется задача по разработке должностных инструкций. На одного из руководителей падает эта «почетная обязанность». Как вынести пользу из этой формальной задачи?

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

Как правило исполнитель тратит 5 минут на гугление примеров и скачивает чужой шаблон с авторскими ошибками и особенностями той другой организации. В другом случае автор пишет «отсебятину» вводя собственную терминологию и систему, рождая инструкцию в творческих муках. Формально задача вроде бы решена, все довольны, не так ли?

Я тоже одно время ломал голову над задачкой, пока не нашел другой, правильный подход. IEEE разработала документ – 📚 Software Engineering Competency Model (SWECOM). Модель компетенций подробно описывает всевозможные hard-скилы - навыки, требующиеся для разработки ПО. Навыки разложены на 13 областей:

🔹 Software Requirements
🔹 Software Design
🔹 Software Construction
🔹 Software Testing
🔹 Software Sustainment
🔹 Software Process and Life Cycle
🔹 Software Systems Engineering
🔹 Software Quality
🔹 Software Security
🔹 Software Safety
🔹 Software Configuration Management
🔹 Software Measurement
🔹 Human-Computer Interaction

Основной «атомарный» элемент модели – это активность, определяющая какое-либо выполняемое действие. К примеру, Создание прототипов для выявления требований к ПО, или Проведение проверки и рецензирование кода. Активности разделены на 5 уровней повышения компетентности (Technician, Entry Level Practitioner, Practitioner, Technical Leader, Senior Software Engineer). Пользуясь этой пятиуровневой градацией, можно легко составить степени компетентности от техника до техлида и синьора по каждому из направлений - областей. Как правило техник лишь следует инструкциям, написанным другими. Синьор сам создает методы и инструкции для остальных. Чаще всего такая широкая градация даже избыточна. Вместе с тем по ней легко провести оценку текущего состояния персонала, найти слабые места команд, выявить риски и построить работающий план совершенствования и прокачки сотрудников. Для HR-менеджеров модель тоже окажется полезной для процессов найма и обучения.

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

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

Александр Кузовлев
Телеграм-канал @aheadofthepack