4.1. Разработка и написание программного кода

.Net-разработчик обязан разрабатывать программный код на языках C# и (при необходимости) TypeScript/JavaScript в рамках серверной части приложений, следуя принципам SOLID, DRY и KISS. Основные обязанности включают:

• написание чистого, читаемого и поддерживаемого кода с использованием конструкций языка C# последних версий (LINQ, async/await, records, patterns);
• проектирование и реализацию RESTful API, gRPC-сервисов и очередей сообщений (например, RabbitMQ, Azure Service Bus);
• создание и модификацию сценариев работ по интеграции со сторонними системами (банковские шлюзы, CRM, ERP) через протоколы HTTP, TCP/IP и веб-сокеты;
• разработку компонентов для работы с базами данных (MS SQL, PostgreSQL, MongoDB) с использованием Entity Framework Core, Dapper и хранимых процедур;
• обеспечение безопасности кода через внедрение аутентификации (JWT, OAuth 2.0) и авторизации (ролевая модель, политики).

4.2. Рецензирование кода и обеспечение качества

В рамках контроля качества .Net-разработчик обязан выполнять следующие функции:

• участвовать в процессе формального рецензирования кода (Code Review) всех изменений, предлагаемых для слияния в основную ветвь репозитория (main, develop);
• составлять конструктивные замечания по стилю, архитектуре, производительности и безопасности кода, с обязательной фиксацией комментариев в системе управления версиями (GitHub, GitLab, Azure DevOps);
• проверять соответствие кода принятому в организации стандарту кодирования (например, на основе рекомендаций Microsoft или согласованного StyleCop-конфига);
• инициировать автоматическое тестирование в пайплайнах CI/CD, следить за покрытием кода модульными и интеграционными тестами (минимальный порог — 80 %);
• документировать в чек-листах этапов все выявленные замечания и факты их исправления до передачи задачи на функциональное тестирование.

4.3. Подготовка и выполнение тестирования

.Net-разработчик выполняет следующие виды тестирования:

• модульное тестирование (Unit Testing) с использованием фреймворков xUnit, NUnit или MSTest, покрывая все критические методы и классы с логикой;
• интеграционное тестирование для проверки взаимодействия компонентов с внешними системами (базы данных, API сторонних сервисов, файловые системы);
• тестирование производительности (нагрузочное и стресс-тестирование) с помощью инструментов JMeter, k6 или NBomber, фиксируя время отклика и потребление ресурсов;
• тестирование безопасности — проверка уязвимостей типа SQL-инъекций, подделки межсайтовых запросов (XSRF), и разглашения конфиденциальных данных;
• составление и актуализацию сценариев работ по регрессионному тестированию после каждого релиза для предотвращения возврата старых дефектов.

4.4. Документирование и формирование отчетности

.Net-разработчик обязан:

• составлять техническую документацию на разработанные модули (в формате Markdown или с использованием систем Swagger/OpenAPI);
• вести журнал изменений (CHANGELOG) с перечнем исправленных ошибок, новых возможностей и известных проблем;
• формировать по итогам спринта отчет о выполненных работах с указанием количества закрытых задач, объема написанного кода (число коммитов, измененных файлов) и коэффициента дефектности;
• подготавливать инструкции по развертыванию и эксплуатации разработанных компонентов для команд эксплуатации (DevOps) и службы техподдержки;
• вносить изменения в карту бизнес-процессов своего участка при введении новых процедур или изменении существующих регламентов.

4.5. Взаимодействие с заказчиками и смежниками

В обязанности .Net-разработчика входит:

• участие в ежедневных стендапах (Daily Stand-up), спринт-планировании (Sprint Planning) и демонстрациях результатов (Sprint Review) в рамках Agile-процесса;
• уточнение нефункциональных требований (производительность, масштабируемость, надежность) совместно с архитектором и системным аналитиком;
• проведение технических митапов (Tech Talks) для передачи опыта внутри команды, освещение новых технологий или паттернов на платформе .NET;
• взаимодействие с DevOps-инженерами для настройки сред разработки, тестирования и продуктивного окружения, а также для отладки проблем на этапах CI/CD;
• сбор и обработка обратной связи от заказчиков и конечных пользователей для корректировки приоритетов и улучшения юзабилити.

4.6. Участие в архитектурных решениях и техническом сопровождении

.Net-разработчик участвует в:

• выборе стеков технологий для новых проектов и микросервисов (веб-фреймворки, ORM, очереди, кэширование, NoSQL);
• проектировании схем баз данных (ER-диаграммы) и миграций с использованием Entity Framework Migrations или FluentMigrator;
• настройке и сопровождении бизнес-процессов непрерывной интеграции и доставки (CI/CD) в GitLab CI, GitHub Actions или Azure DevOps;
• проведении технических расследований (Post-mortem) после инцидентов на продуктивной среде с формированием плана корректирующих действий;
• мониторинге производительности приложений с использованием Application Insights, Prometheus или Grafana и оптимизации узких мест.

5.1. Право на доступ к информации и системам

.Net-разработчик имеет право на:

• доступ к репозиториям исходного кода (Git) всех проектов, к которым он прикреплен как участник команды;
• получение полной технической документации, схем данных, спецификаций API и результатов предшествующих этапов работ;
• запрос и получение от смежных служб (безопасность, администрирование баз данных, сеть) необходимых прав доступа для развертывания и отладки приложений на тестовых и продуктивных серверах;
• использование корпоративной базы знаний, вики-страниц и библиотек кода в процессе разработки;
• ознакомление с чек-листами этапов и сценариями работ, утвержденными для данного проекта, а также с планами тестирования и приемки.

5.2. Право на ресурсное и организационное обеспечение

.Net-разработчик имеет право:

• на своевременное предоставление рабочего места, оснащенного современной вычислительной техникой (ПК/ноутбук) с необходимым лицензионным программным обеспечением (Visual Studio, JetBrains Rider, Docker Desktop, базы данных);
• запрашивать и получать выделение дополнительных вычислительных мощностей (облачные среды) для нагрузочного тестирования или отладки сложных сценариев;
• вносить предложения руководству о корректировке сроков выполнения задач в случае выявления технических рисков или непредвиденных сложностей;
• на защиту от давления со стороны заказчиков в части нарушения утвержденной карты бизнес-процессов и пропусков обязательных чек-листов качества;
• участвовать во внутренних профессиональных конкурсах, хакатонах и программах повышения квалификации за счет организации.

5.3. Право на принятие технических решений и делегирование

.Net-разработчик обладает правом:

• самостоятельно выбирать способы реализации функциональности в рамках утвержденного технического задания, если это не противоречит стандартам и архитектурным ограничениям;
• привлекать временно других членов команды для решения узких технических вопросов (замена или распределение частей задач) с уведомлением Tech Lead;
• отклонять требования заказчика, которые ведут к нарушению безопасности, производительности или целостности данных, с обязательным письменным обоснованием;
• инициировать внеплановые рефакторинги и технические улучшения, если они не угрожают текущему графику релизов и согласованы с архитектором;
• делегировать часть вспомогательных работ (написание простых тестов, настройка конфигураций) младшим разработчикам (Junior .Net Developer) с контролем результатов.

6.1. Дисциплинарная ответственность за нарушение регламентов

.Net-разработчик несет дисциплинарную ответственность за:

• нарушение сроков выполнения поставленных задач без уважительной причины и без предварительного уведомления руководителя;
• отказ от прохождения обязательных этапов контроля качества (тестирования, рецензирования кода) перед сдачей задачи в релиз;
• несоблюдение требований карты бизнес-процессов и чек-листов этапов, зафиксированных в нормативных документах организации;
• сокрытие дефектов или искажение информации о статусе выполнения работ в отчетах и системах управления проектами (Jira, Azure Boards);
• нарушение правил корпоративной этики и субординации при взаимодействии с заказчиками и коллегами.

Дисциплинарные взыскания могут применяться в форме замечания, выговора или увольнения (при систематических нарушениях) в порядке, установленном Трудовым кодексом РФ.

6.2. Материальная ответственность

.Net-разработчик несет материальную ответственность в пределах, установленных законодательством, за:

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

Материальная ответственность ограничена среднемесячным заработком, если иное не установлено договором о полной материальной ответственности.

6.3. Ответственность за качество кода и безопасность продукта

Персональная ответственность .Net-разработчика распространяется на:

• качество и надежность написанного кода, включая его устойчивость к сбоям и корректность обработки ошибок;
• безопасность приложения в части предотвращения распространенных векторов атак (OWASP Top 10), в частности $\text{SQL-инъекции}$, $\text{межсайтовый скриптинг (XSS)}$ и $\text{подделка запросов (CSRF)}$;
• соблюдение требований по защите персональных данных в соответствии с $\text{152-ФЗ}$ и применимыми внутренними политиками;
• своевременное исправление критических дефектов, обнаруженных как в процессе тестирования, так и в эксплуатации;
• поддержание актуальности документации и конфигурационных файлов в соответствии с реальными изменениями в коде.

Нарушения в этой области, приведшие к инцидентам информационной безопасности, рассматриваются как грубые дисциплинарные проступки.

7.2. Профессиональные технические компетенции

.Net-разработчик обязан владеть следующими профессиональными компетенциями и инструментами:

• глубокое знание платформы .NET (не ниже версии .NET 8) и языка C#, включая последние синтаксические конструкции и асинхронное программирование;
• практический опыт работы с фреймворками ASP.NET Core Web API, Minimal API, SignalR и gRPC;
• умение проектировать и оптимизировать реляционные базы данных (MS SQL, PostgreSQL) с использованием Entity Framework Core и T-SQL;
• навыки работы с системами управления версиями (Git), ветвления и разрешения конфликтов, знание стратегий Git Flow и GitHub Flow;
• опыт контейнеризации (Docker) и оркестрации (Kubernetes), навыки написания Dockerfile и Helm-чартов;
• понимание принципов тестирования и опыт написания модульных и интеграционных тестов;
• знание основ сетевых протоколов (HTTP/HTTPS, TCP/IP, WebSocket) и взаимодействия с внешними API;
• умение читать и анализировать логи, профилировать приложения (dotTrace, PerfView), работать с системами мониторинга (ELK, Grafana).

7.3. Надпрофессиональные навыки (Soft Skills)

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

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

8.2. Требования к рабочему месту и техническому оснащению

Рабочее место .Net-разработчика должно быть оснащено:

• персональным компьютером с процессором не ниже Intel Core i7 (или AMD Ryzen 7), оперативной памятью от 32 ГБ, твердотельным накопителем (SSD) объемом не менее 1 ТБ;
• двумя мониторами с диагональю не менее 24 дюймов для эффективной многозадачности;
• лицензионным программным обеспечением: операционная система Windows 10/11 Pro, среда разработки Visual Studio 2022 Enterprise, JetBrains Rider, Docker Desktop, Git, клиенты для работы с базами данных (SQL Server Management Studio, Azure Data Studio, DBeaver);
• доступом к корпоративной системе управления версиями (GitHub Enterprise, GitLab), системам управления проектами (Jira, Azure DevOps) и коммуникационным платформам (Microsoft Teams, Slack);
• регулируемым офисным креслом и столом, а также возможностью использования наушников для шумоподавления.

8.3. Охрана труда и информационная безопасность

.Net-разработчик обязан:

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

9.1. Количественные KPI (измеряемые показатели)

.Net-разработчик оценивается по следующим количественным KPI за отчетный период (квартал/год):

• процент выполненных задач в срок — не менее 95 % от общего числа задач, закрепленных за сотрудником в рамках спринта (измеряется по системе Jira);
• покрытие кода модульными тестами — не менее 80 % для нового кода и не менее 70 % для поддерживаемого (измеряется с помощью Coverlet или SonarQube);
• количество критических дефектов — не более 2 критических дефектов (Severity $\ge$ High) на релиз, обнаруженных в продуктивной среде;
• время обработки инцидентов — среднее время восстановления (MTTR) не более 2 часов для инцидентов 2-го уровня;
• производительность приложений — сохранение времени отклика API (p95) в пределах согласованного SLA (не более 200 мс).

9.2. Качественные KPI и оценка компетенций

Качественные KPI определяются на основе экспертной оценки руководителем, Tech Lead и коллегами при проведении 360-градусной обратной связи:

• качество кода — оценка по результатам автоматических проверок (SonarQube / Code Quality Gates) и рецензий (количество замечаний, сложность доработок);
• инновационность — количество внедренных технических предложений, улучшающих архитектуру или производительность;
• вклад в документацию — актуальность и полнота ведения технической документации, частота обновлений вики-страниц;
• экспертность — участие в решении сложных технических вопросов команды, проведение внутренних семинаров и демонстраций;
• удовлетворенность заказчика — оценка оперативности и качества решения запросов со стороны внутренних и внешних заказчиков на основе опросов.

9.3. Периодичность оценки и принятие решений

Оценка выполнения KPI проводится ежеквартально на основании данных автоматизированных систем (Git, CI/CD, Jira, мониторинг) и отзывов руководителя. По итогам оценки формируется индивидуальный план развития (План обучения и развития) и принимаются решения о:

• размере квартальной премии (бонуса), привязанном к выполнению плановых показателей;
• пересмотре должностного оклада (при систематическом перевыполнении);
• переводе на проект с повышенной сложностью или в архитектурную группу;
• рекомендациях к прохождению сертификации (Microsoft, AWS, безопасность);
• необходимости проведения внеочередной аттестации при низкой эффективности (менее 50 % выполнения KPI).

10.1. Бизнес-процесс «Разработка новой функциональности» (BPMN/EPC)

Бизнес-процесс «Разработка новой функциональности» включает в себя следующие этапы, представленные в нотации EPC:

• Событие «Поступила заявка на разработку» → Анализ требований (Аналитик совместно с разработчиком) → Функция «Формирование технического задания» → Ветвление «ТЗ утверждено?» → Если нет, возврат на доработку;
• Функция «Оценка трудоемкости и планирование» → Создание задач в системе управления проектами (Jira) → Функция «Разработка кода» (включает написание кода, покрытие тестами, локальную отладку);
• Функция «Рецензирование кода (Code Review)» → Результат проверки (замечания есть/нет) → При наличии замечаний — возврат к разработке;
• Функция «Интеграционное тестирование» → Чек-лист этапа (проверка интеграции с БД, внешними API, производительности) → Функция «Функциональное тестирование» (QA-инженер);
• Функция «Подготовка к релизу» → Формирование артефактов (Docker-образы, сборки) → Функция «Развертывание в среде UAT» → Приемочное тестирование → Если успешно — Событие «Передача в продуктивную среду».

В нотации BPMN данный процесс моделируется как пул «Разработка», с дорожками для ролей: Аналитик, Разработчик, Tech Lead, QA-инженер, DevOps. На диаграмме выделяются шлюзы проверки качества (Gateway) и события завершения.

10.2. Бизнес-процесс «Устранение критического дефекта в продуктивной среде»

Бизнес-процесс по устранению критического дефекта (P1/P2) в продуктивной среде включает:

• Событие «Обнаружен инцидент» (из системы мониторинга или сообщение пользователя) → Функция «Регистрация инцидента» в Jira Service Management;
• Функция «Диагностика и локализация ошибки» (анализ логов, дампов, трассировки) → Функция «Разработка исправления» (hotfix) с обязательным созданием модульного теста, воспроизводящего ошибку;
• Функция «Проверка исправления» (Code Review) → Функция «Тестирование исправления» (регрессионное тестирование);
• Функция «Утверждение изменений» (Change Advisory Board) → Функция «Развертывание hotfix» в продуктивную среду по процедуре CI/CD;
• Функция «Валидация исправления» в продуктивной среде → Закрытие инцидента → Функция «Проведение Post-mortem» (корневые причины, меры предотвращения).

Для этого процесса разработан чек-лист этапов, включающий пункты «логи собраны», «воспроизведено локально», «написан тест», «изменения документированы».

10.3. Чек-лист этапа «Разработка кода» (Development Stage Checklist)

Чек-лист этапов для .Net-разработчика при выполнении задачи «Разработка кода»:

• Понимание требований: задача в Jira понята, все вопросы к аналитику заданы и зафиксированы в комментариях к задаче.
• Подготовка среды: локальное окружение настроено (переменные среды, подключение к тестовой БД, кэш, очереди), все зависимости обновлены.
• Разработка функциональности: написан код в соответствии с принятыми паттернами (например, Repository, Mediator, CQRS) и стандартами кодирования (Naming, Formatting).
• Написание тестов: созданы модульные тесты (Unit Tests) и/или интеграционные тесты (Integration Tests) для новой логики, покрытие не менее 80 %.
• Локальная отладка и проверка: выполнена отладка всех сценариев успеха и ошибок, проверена обработка исключений (try-catch, middleware для ошибок).
• Документирование изменений: обновлены комментарии в коде, OpenAPI-спецификация (Swagger) и вики-страница с описанием API.
• Создание запроса на слияние: открыт Pull Request (Merge Request) с корректным описанием, указанием связанных задач и результатами тестирования.
• Прохождение рецензии: все замечания рецензента устранены, комментарии закрыты, код повторно проверен.
• Слияние и интеграция: код влит в целевую ветвь (develop), пайплайн CI успешно выполнен (сборка, тесты, анализ качества).

10.4. Чек-лист этапа «Тестирование и приемка» (Testing & QA Checklist)

.Net-разработчик совместно с QA-инженером участвует в выполнении следующего чек-листа этапов перед передачей функциональности в релиз:

• Модульное тестирование: все тесты (Unit) успешно пройдены в CI-пайплайне без ошибок и пропусков.
• Интеграционное тестирование: проверены все точки взаимодействия с базами данных, внешними сервисами, файловой системой, очередями сообщений; тесты стабильны.
• Тестирование API: выполнены ручные или автоматизированные проверки всех эндпоинтов через Postman / Swagger, корректность кодов ответов (200, 400, 401, 404, 500).
• Нагрузочное тестирование: проведены замеры производительности, система выдерживает пиковую нагрузку (не менее N запросов в секунду) с временем отклика в рамках SLA.
• Тестирование безопасности: проверены уязвимости (авторизация, валидация данных, защита от инъекций) с использованием OWASP ZAP или Burp Suite.
• Регрессионное тестирование: убедиться, что новые изменения не сломали существующую функциональность (запуск набора регрессионных тестов).
• Проверка логов и мониторинга: добавлены необходимые логи (Informational, Warning, Error) и метрики для мониторинга в Application Insights.
• Приемочное тестирование: заказчик или владелец продукта подтвердил работоспособность в тестовой среде (UAT).

10.5. Чек-лист этапа «Развертывание и релиз» (Deployment & Release Checklist)

Чек-лист этапов для .Net-разработчика и команды DevOps при развертывании новой версии или компонента:

• Подготовка артефактов: выполнена сборка релизных конфигураций (dotnet publish -c Release), созданы Docker-образы и загружены в реестр (Azure Container Registry, Docker Hub).
• Проверка конфигураций: все переменные окружения (Connection Strings, API Keys, Feature Flags) актуальны и соответствуют целевой среде.
• Выполнение миграций БД: скрипты миграции (EF Migrations) проверены и выполнены в безопасном режиме (с резервным копированием схемы).
• Развертывание в тестовую среду (Staging): выполнено автоматическое развертывание через CI/CD пайплайн, проверена работоспособность компонента в окружении, близком к продуктивному.
• Тестирование после развертывания: проведены sanity-тесты (дымовые тесты) на основных сценариях, проверено логирование и мониторинг.
• План отката (Rollback Plan): подготовлен сценарий и инструменты для быстрого отката к предыдущей стабильной версии (например, через Kubernetes Rollout или переключение трафика).
• Развертывание в продуктивную среду: выполнено по утвержденному графику (окно изменений), с уведомлением заинтересованных сторон и службы поддержки.
• Пострелизный мониторинг: в течение 24 часов после релиза ведется усиленный мониторинг ошибок, производительности и использования ресурсов.
• Закрытие релиза: документально оформлено завершение релиза, сценарии работ обновлены, тикет в Jira переведен в статус «Done».

10.6. Сценарии работ по взаимодействию со смежными системами (интеграционные сценарии)

.Net-разработчик участвует в реализации и отработке следующих интеграционных сценариев работ:

• Сценарий «Получение данных от внешнего поставщика»: инициирование HTTP-запроса (с повторными попытками при ошибках), парсинг ответа (JSON/XML), маппинг на внутреннюю модель, сохранение в БД, отправка уведомления в очередь (RabbitMQ) для дальнейшей обработки;
• Сценарий «Обработка входящего вебхука»: прием POST-запроса от внешней системы, аутентификация (JWT, API Key), валидация подписи, запись в лог, вызов внутреннего бизнес-сервиса;
• Сценарий «Отправка уведомлений»: формирование и отправка электронных писем (SMTP) или уведомлений в мессенджеры (Telegram, Slack) через API-шлюз, с обработкой статусов доставки;
• Сценарий «Экспорт отчетов»: генерация сложных отчетов в форматах PDF, Excel, CSV на основе данных из БД, с использованием библиотек iTextSharp, EPPlus;
• Сценарий «Обмен через очереди»: публикация и подписка на события в Azure Service Bus или RabbitMQ, обработка сообщений с идемпотентностью, гарантией доставки и dead-letter-очередью для сбоев.

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

10.7. Контрольные точки и управление рисками в бизнес-процессах

В рамках управления бизнес-процессами .Net-разработчик обязан учитывать и отрабатывать следующие контрольные точки и риски:

• Риск изменения требований: контрольная точка — согласование любых изменений с аналитиком и владельцем продукта до начала разработки, фиксация в протоколе.
• Риск технической неопределенности: контрольная точка — проведение Proof of Concept (Spike) до оценки, если технология или библиотека новая.
• Риск низкого покрытия тестами: контрольная точка — автоматическая проверка покрытия в CI, блокировка слияния при падении ниже порога (80 %).
• Риск нарушений безопасности: контрольная точка — обязательное сканирование зависимостей (OWASP Dependency Check) и кода на уязвимости в CI.
• Риск производительности: контрольная точка — проведение нагрузочных тестов в среде, приближенной к продуктивной, при каждом значимом изменении.
• Риск сбоя развертывания: контрольная точка — наличие отработанного сценария отката и оповещение всех участников процесса релиза.

Обнаружение любого из рисков является основанием для остановки процесса и пересмотра плана работ.

10.8. Документирование бизнес-процессов с использованием BPMN 2.0

.Net-разработчик должен уметь читать и понимать диаграммы BPMN, а также участвовать в их создании для оптимизации процессов. Основные элементы, используемые в документации:

• Пул (Pool) — основной контейнер для процесса, обычно соответствует отделу или системе (например, «Отдел разработки»);
• Дорожка (Lane) — подразделение пула, соответствует роли или исполнителю (например, «Разработчик», «QA-инженер», «DevOps»);
• События (Events): стартовое событие (Start Event), промежуточные (Intermediate Event — таймер, сообщение), конечное (End Event);
• Задачи (Tasks): выполняемые действия, например, «Написать код», «Выполнить тестирование», «Развернуть»;
• Шлюзы (Gateways): точки ветвления и слияния потоков (исключающий OR, параллельный AND, инклюзивный).

Документирование процессов в нотации BPMN позволяет унифицировать понимание сценариев работ и обеспечивает прозрачность для всех участников проектной деятельности, включая руководство и заказчиков.

10.9. Использование IDEF0 для функционального моделирования на этапе проектирования

На этапе высокоуровневого проектирования архитектуры .Net-разработчик может применять нотацию IDEF0 для функционального моделирования системы. IDEF0 описывает функции системы как иерархию блоков, каждый из которых имеет входы, выходы, управления и механизмы (подход ICOM). Пример применения:

• Блок A-0 «Разработать программный продукт»: вход — требования заказчика, управление — стандарты и регламенты, механизмы — команда разработчиков, инструменты (IDE, CI/CD), выход — готовый релиз.
• Декомпозиция A0: A1 «Анализ требований», A2 «Проектирование архитектуры», A3 «Кодирование», A4 «Тестирование», A5 «Развертывание».
• Декомпозиция A3 «Кодирование»: A3.1 «Написание кода», A3.2 «Рецензирование», A3.3 «Модульное тестирование».

Модели IDEF0 помогают структурировать бизнес-процессы, выявлять дублирование функций и определять необходимые ресурсы для каждого этапа.

10.10. Практические шаблоны сценариев работ для типовых задач

Для повышения стандартизации и сокращения времени на разработку .Net-разработчику рекомендуется использовать типовые сценарии работ (Checklist Templates) для часто повторяющихся действий:

• Шаблон «Создание нового REST-контроллера»: создать класс-контроллер, определить маршруты (Route Attributes), реализовать методы (GET, POST, PUT, DELETE), добавить модели запроса/ответа (DTO), внедрить сервисы через Dependency Injection (DI), настроить валидацию (FluentValidation), добавить логирование (ILogger), создать тесты.
• Шаблон «Добавление новой сущности в базу данных»: создать класс сущности, настроить конфигурацию в DbContext (Fluent API), создать миграцию (dotnet ef migrations add), обновить БД (dotnet ef database update), создать репозиторий или сервис для доступа к данным, протестировать CRUD-операции.
• Шаблон «Подключение к внешнему API»: создать клиентский класс (HttpClient), настроить политику повторных попыток (Polly), сериализацию/десериализацию JSON, обработку ошибок и маппинг данных, добавить кэширование (при необходимости), покрыть тестами.
• Шаблон «Написание модульного теста»: создать проект тестов (xUnit), добавить атрибут [Fact] или [Theory], использовать библиотеки Moq, AutoFixture, FluentAssertions для создания фейковых объектов и проверок, обеспечить изоляцию тестов.

10.11. Пример оценки трудоемкости на основе сценариев работ

.Net-разработчик обязан участвовать в оценке трудоемкости задач, используя сценарии работ и чек-листы этапов для разбиения на подзадачи. Пример оценки для задачи «Реализовать функционал восстановления пароля»:

• Анализ и проектирование (0,5 дня): уточнить требования, спроектировать последовательность действий (генерация токена, отправка email, проверка токена, смена пароля).
• Разработка (2 дня): написание контроллера AuthController, сервиса PasswordRecoveryService, интеграция с EmailService, добавление таймаута для токена (15 минут), покрытие тестами.
• Рецензирование и доработка (0,5 дня): открыть Pull Request, исправить замечания (безопасность, наименования).
• Тестирование и документирование (1 день): интеграционные тесты, ручное тестирование сценариев (успех, неверный токен, истекший токен), обновление документации в Swagger и вики.
• Итого: 4 дня (без учета времени на развертывание и мониторинг).

Использование единых сценариев работ позволяет повысить точность оценок и согласованность в команде.

10.12. Мониторинг и контроль выполнения бизнес-процессов

Для контроля выполнения бизнес-процессов .Net-разработчик использует следующие инструменты и мероприятия:

• Доски задач в Jira/Azure Boards — отслеживание статуса каждой задачи, контроль соблюдения сценариев работ на каждом этапе жизненного цикла.
• Пайплайны CI/CD — мониторинг прохождения сборок, тестов и развертываний, автоматическая блокировка при нарушении чек-листов.
• Dashboard мониторинга (Grafana, Kibana) — отслеживание метрик производительности, ошибок, времени отклика для своевременного реагирования на инциденты.
• Еженедельные отчеты — предоставление руководителю данных о ходе выполнения запланированных работ, выявленных рисках и необходимых корректировках.
• Ретроспектива спринта — анализ выполненных сценариев работ и чек-листов этапов для выявления узких мест и возможностей улучшения.

Результаты мониторинга используются для корректировки планов, повышения эффективности и пересмотра KPI.

10.13. Актуализация и изменение карты бизнес-процессов

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

• подготовку предложения (с обоснованием и проектом изменений) на имя руководителя отдела разработки;
• согласование изменений с техническим комитетом и юридической службой (при необходимости);
• утверждение изменений и доведение до сведения всех сотрудников, участвующих в бизнес-процессах;
• обновление электронных версий документации и рассылка уведомлений.

Актуализация карты бизнес-процессов позволяет поддерживать ее соответствие современным требованиям и повышает эффективность работы всего коллектива.