Created by AIImproved by people
Riqli · living documents · updated continuously
Where AI knowledge meets human practice.
Share with friends
1. Общие положения
1.1. Назначение документа
Настоящий документ представляет собой должностную инструкцию, а также положение о ключевых показателях эффективности (KPI) для разработчика на платформе .NET. Документ устанавливает единые требования к профессиональной деятельности, закрепляет зоны ответственности и определяет систему оценки результативности труда. Положение обязательно для исполнения всеми сотрудниками, занимающими должность .Net-разработчика, и является основой для формирования индивидуальных планов развития и премирования.
1.2. Правовая и нормативная основа
Документ разработан в соответствии с Трудовым кодексом РФ, внутренними регламентами компании, политикой управления персоналом и стандартами качества в области разработки программного обеспечения. Положение также опирается на международные практики оценки производительности труда в IT-сфере и корпоративные требования к качеству кода, производительности приложений и стабильности систем. Внесение изменений в настоящий документ осуществляется только на основании приказа генерального директора по представлению руководителя отдела разработки.
1.3. Термины, определения и сокращения
В настоящем документе используются следующие термины и их определения. Ключевые показатели эффективности (KPI) — это количественно измеримые метрики, отражающие результативность работы сотрудника за отчётный период. Метрики кода — набор числовых параметров, характеризующих сложность, поддерживаемость и тестовое покрытие исходного кода. Производительность приложений — способность программного продукта обрабатывать заданную нагрузку в установленные временные рамки. .Net-разработчик — специалист, создающий и поддерживающий приложения на базе технологического стека Microsoft .NET, включая C#, ASP.NET Core, Entity Framework Core и смежные инструменты.
2. Цель должности и сфера деятельности
2.1. Миссия роли
Миссия .Net-разработчика заключается в создании надежных, масштабируемых и производительных программных решений, обеспечивающих достижение бизнес-целей компании. Специалист несёт ответственность за полный жизненный цикл разрабатываемых компонентов — от анализа требований и проектирования архитектуры до внедрения, тестирования и поддержки в продуктивной среде. Основной задачей является трансформация бизнес-потребностей в технически совершенный и эффективный код.
2.2. Ожидаемые результаты деятельности
В результате работы .Net-разработчика должны быть обеспечены следующие ключевые результаты. Скорость разработки новых функций должна соответствовать плану релизов и не снижаться без объективных причин. Качество кода на протяжении всего проекта должно соответствовать установленным корпоративным стандартам, а количество критических дефектов в продуктивном коде стремиться к нулю. Производительность приложений должна сохраняться на целевом уровне в условиях пиковых нагрузок, а время ответа критических операций не должно превышать допустимых пороговых значений.
3. Подчинённость и организационная структура
3.1. Административное подчинение
.Net-разработчик находится в прямом подчинении у руководителя группы разработки или ведущего инженера-программиста (Tech Lead). Административное подчинение включает вопросы постановки задач, контроля сроков исполнения, утверждения результатов работы и проведения оценки эффективности. В случае отсутствия непосредственного руководителя его обязанности исполняет вышестоящее должностное лицо, назначенное приказом по организации.
3.2. Функциональное взаимодействие и матричные связи
В рамках выполнения своих обязанностей разработчик взаимодействует с руководителем проекта (PM) для уточнения требований и приоритетов задач. С аналитиками данных (Data Analyst) и системными архитекторами — для согласования моделей данных и общей архитектуры решений. Со специалистами по автоматизированному тестированию (QA) — для обеспечения качества и покрытия тестами. С администраторами баз данных (DBA) и инженерами DevOps — для настройки сред выполнения, мониторинга и обеспечения высокой доступности сервисов. Все взаимодействия осуществляются в рамках установленных регламентов и корпоративной культуры.
4. Должностные обязанности
4.1. Разработка и реализация программного кода
Основной обязанностью является написание высококачественного программного кода на языке C# с использованием платформы .NET Core / .NET 6/8 и выше. Специалист обязан использовать современные паттерны проектирования, принципы SOLID и подходы к разработке, ориентированные на предметную область (Domain-Driven Design). Разработка включает создание RESTful API, сервисов фоновой обработки, интеграционных модулей и пользовательских интерфейсов на базе Blazor или ASP.NET MVC. Каждый создаваемый или изменяемый программный компонент должен сопровождаться юнит-тестами с использованием фреймворков xUnit или NUnit, а также соответствовать стандартам кодирования, принятым в компании.
// Пример внедрения зависимости и написания тестируемого кода
public class OrderService
{
private readonly IOrderRepository _orderRepository;
public OrderService(IOrderRepository orderRepository)
{
_orderRepository = orderRepository;
}
public async Task<Order> GetOrderByIdAsync(int id)
{
return await _orderRepository.GetByIdAsync(id);
}
}4.2. Участие в ревью кода и обеспечение качества
Разработчик обязан принимать активное участие в процессе ревью кода своих коллег, а также предоставлять собственные наработки для проверки. В ходе ревью необходимо проверять соответствие кода архитектурным требованиям, читаемость, наличие тестов и отсутствие «запахов кода» (code smells). Все замечания, высказанные в процессе ревью, должны быть устранены до вливания изменений в основную ветку разработки. Качество кода измеряется с помощью инструментов статического анализа (SonarQube), и разработчик обязан поддерживать уровень покрытия тестами не ниже установленного порога (например, 80%).
4.3. Оптимизация производительности приложений
В обязанности входит проведение регулярного профилирования разрабатываемых приложений с использованием средств диагностики (Application Insights, DotMemory, PerfView). Разработчик должен выявлять узкие места в производительности, «тяжёлые» запросы к базе данных, неэффективное использование памяти и высокое время отклика. На основе результатов профилирования необходимо вносить изменения в код: оптимизировать алгоритмы, использовать кэширование, асинхронное программирование и пулы соединений. Критически важным является соблюдение согласованного уровня производительности — например, время ответа API должно быть менее 200 мс для 95% запросов при стандартной нагрузке.
4.4. Документирование и техническая поддержка
.Net-разработчик обязан сопровождать свои изменения технической документацией. Это включает в себя описание архитектуры модулей, диаграммы последовательности, спецификации API (Swagger/OpenAPI) и инструкции по развёртыванию. При возникновении инцидентов в продуктивной среде, связанных с его кодом, специалист должен принимать участие в их расследовании и устранении в рамках установленных SLA. Также он обязан обучать младших коллег и делиться практиками в рамках внутренних митапов и технических сессий.
4.5. Соблюдение стандартов безопасности и архитектуры
Код должен разрабатываться с учётом требований информационной безопасности: защита от SQL-инъекций, XSS-атак, использование безопасных методов аутентификации и авторизации (OAuth2, JWT). Все изменения должны проходить через согласование с архитектурным комитетом при изменении ключевых компонентов. Разработчик несёт ответственность за отсутствие уязвимостей в передаваемом в релиз коде и обязан использовать инструменты проверки зависимостей на наличие известных уязвимостей (NuGet Vulnerability Scanner).
5. Права сотрудника
5.1. Право на принятие решений в рамках компетенций
.Net-разработчик имеет право самостоятельно выбирать способы и методы решения поставленных задач, если это не противоречит утверждённым архитектурным и техническим стандартам. Он вправе предлагать изменения в технологический стек, инструментарий и процессы разработки, аргументируя это повышением производительности труда и улучшением качества продукта. Решения, влияющие на архитектуру приложения в целом, принимаются только после согласования с техническим руководителем.
5.2. Доступ к ресурсам и информации
Специалист имеет право на получение всех необходимых для работы материалов: технической документации, исходного кода, доступа к репозиториям, базам данных и продуктивным средам в объёме, необходимом для выполнения должностных обязанностей. Он имеет право на использование лицензионного программного обеспечения, выделенного компанией, и на своевременное обновление рабочих инструментов до актуальных версий.
6. Ответственность и подотчётность
6.1. Меры ответственности за невыполнение обязанностей
.Net-разработчик несёт дисциплинарную, а в установленных законом случаях — материальную ответственность за невыполнение или ненадлежащее выполнение своих должностных обязанностей, предусмотренных настоящей инструкцией. Критерии оценки включают нарушение сроков сдачи задач, внесение критических дефектов в релиз, нарушение стандартов безопасности и низкое качество кода. Виды взысканий (замечание, выговор, увольнение) определяются Трудовым кодексом РФ и внутренними нормативными актами.
6.2. Ответственность за разглашение информации
Сотрудник обязан сохранять в тайне конфиденциальную информацию, ставшую ему известной в ходе работы, включая исходные коды, бизнес-логику, персональные данные клиентов и технологические ноу-хау. Разглашение такой информации влечёт за собой ответственность вплоть до увольнения и привлечения к судебной ответственности в соответствии с действующим законодательством.
7. Требования к квалификации
7.1. Требования к образованию и опыту
Должность предполагает наличие высшего или среднего профессионального образования в сфере информационных технологий, компьютерных наук или математики. Требуемый опыт коммерческой разработки на платформе .NET составляет не менее трёх лет. Приветствуется наличие сертификаций по Microsoft .NET, Azure, а также опыт работы в продуктовых командах с использованием гибких методологий (Scrum, Kanban).
7.2. Необходимые профессиональные навыки
- Технические навыки: глубокое знание C#, ASP.NET Core, Entity Framework Core, MS SQL Server, опыт работы с NoSQL базами данных (MongoDB, Redis) и очередями сообщений (RabbitMQ, Azure Service Bus).
- Инструменты: владение Git, CI/CD пайплайнами (Azure DevOps, GitHub Actions), контейнеризацией (Docker, Kubernetes).
- Качество и тестирование: опыт написания юнит-тестов, интеграционных тестов, знание паттернов тестирования и мокирования.
- Soft Skills: развитые навыки коммуникации, умение работать в команде, наставничество, проактивность и ориентация на результат.
8. Условия труда
8.1. Режим рабочего времени и место работы
Рабочее время определяется правилами внутреннего трудового распорядка и графиком работы подразделения. Возможна гибкая форма занятости с фиксированным временем присутствия в рамках «ядра» рабочего дня (например, с 10:00 до 16:00). Место работы — офис компании с возможностью частичной удалённой работы при соблюдении всех условий безопасности и подключения через защищённые каналы VPN.
8.2. Обеспечение рабочего места и социальные гарантии
Сотруднику предоставляется оборудованное рабочее место с персональным компьютером, мониторами, а также лицензионным программным обеспечением. Компания гарантирует социальные льготы: оплачиваемый отпуск, больничные листы, медицинское страхование и обучение за счёт организации по профильным курсам и конференциям.
9. Ключевые показатели эффективности (KPI) и система оценки
9.1. Перечень индивидуальных KPI .Net-разработчика
Оценка эффективности строится на пяти ключевых группах показателей, отражающих полноту профессиональной деятельности. Показатели качества кода: количество критических багов на 1000 строк кода (стремится к 0), уровень покрытия тестами (более 80%), индекс поддерживаемости (Maintainability Index > 80). Показатели скорости разработки: процент задач, выполненных в спринт, и предсказуемость оценки (разница между плановой и фактической трудоёмкостью не более 20%). Показатели производительности: время ответа критического API (менее 200 мс), время выполнения фоновых задач, количество успешных транзакций в секунду. Показатели стабильности: количество инцидентов, связанных с кодом разработчика, и среднее время восстановления (MTTR). Показатели профессионализма: участие в ревью, наставничество, создание технической документации.
9.2. Формулы и метрики для расчёта эффективности
Каждая метрика имеет числовое выражение для объективного расчёта. Покрытие тестами рассчитывается как отношение числа покрытых строк к общему числу строк кода: . Среднее время ответа является усреднённым показателем за последние 7 дней: , где — это время выполнения каждого успешного запроса. Процент завершённых задач в спринт вычисляется как отношение выполненных story points к запланированным: . Также оценивается частота возникновения регрессий.
9.3. Периодичность оценки и процесс ревью
Оценка KPI производится ежемесячно, с формированием сводного отчёта руководителем группы. Раз в квартал проводится итоговое ревью эффективности, по результатам которого принимается решение о размере премии и корректировке индивидуального плана развития. При этом учитывается как выполнение плановых показателей, так и динамика их улучшения по сравнению с предыдущим периодом. Оценка должна быть прозрачной, и каждый разработчик имеет право на апелляцию результатов в специальной комиссии.
10. Бизнес-процессы, чек-листы и сценарии рабочих потоков
10.1. Процесс выполнения задачи от постановки до релиза
Стандартный рабочий процесс .Net-разработчика включает в себя несколько обязательных этапов. 1) Получение задачи через систему управления проектами (Jira/YouTrack), уточнение требований с аналитиком. 2) Создание ветки в репозитории (Git) и реализация функционала с написанием тестов. 3) Проведение локального тестирования и запуск пайплайна CI (сборка, статический анализ, запуск тестов). 4) Создание запроса на слияние (Pull Request) и прохождение ревью от коллег. 5) Устранение замечаний и вливание изменений. 6) Развёртывание на стейджинговую среду для интеграционного тестирования. 7) Сопровождение изменений до успешного выката в продуктивную среду по графику релизов.
10.2. Чек-лист самопроверки перед сдачей задачи
- Код написан в соответствии с гайдлайнами компании и проверен через StyleCop/ReSharper.
- Добавлены все необходимые юнит- и интеграционные тесты; покрытие критических путей не ниже целевого уровня.
- Проведена локальная проверка производительности: время выполнения эндпоинтов не превышает допустимого порога.
- Изменения не нарушают обратную совместимость существующих API.
- Обновлена документация (Swagger, комментарии к коду, README).
- Произведена проверка безопасности: отсутствие hardcoded секретов, использование Parameterized SQL.
- Ветка синхронизирована с последней версией основной ветки перед созданием PR.
10.3. Сценарии взаимодействия при возникновении инцидента
При получении уведомления об инциденте в продуктивной среде разработчик обязан действовать согласно регламенту. 1) Подтвердить приём уведомления и связаться с руководителем для определения приоритета. 2) В течение 15 минут локализовать проблему (по логам, метрикам, дашбордам Application Insights). 3) Если инцидент вызван ошибкой в коде, подготовить хотфикс (hotfix) с обходным путём и развернуть его согласно процедуре экстренного релиза. 4) Провести пост-мортем анализ для выявления корневых причин и предотвращения повторения. 5) Внести соответствующие изменения в автотесты и документацию.
10.4. Процесс планового повышения производительности
Ежеквартально проводится анализ производительности ключевых систем. В рамках этого процесса .Net-разработчик выполняет следующие действия: обновляет нагрузочные тесты (используя JMeter или Artillery); проверяет эффективность использования кэша (In-Memory Cache, Redis) и оптимизирует запросы к базе данных (устранение N+1 проблем, использование агрегатных функций). Результаты анализа оформляются в виде отчёта с предложениями по улучшению архитектуры. Конечной целью является поддержание производительности приложения на уровне не ниже зафиксированного в соглашении об уровне качества (SLA).