1.3. Определения и сокращения

• Разработчик ПО — сотрудник, занимающийся созданием, модификацией и сопровождением программного обеспечения в рамках закрепленных за ним проектов и задач.
• Fullstack-разработка — разработка как клиентской (frontend), так и серверной (backend) частей веб-приложений.
• Backend-разработка — разработка серверной логики, API, баз данных и интеграционных решений.
• Стек технологий — совокупность языков программирования (Java, Go, .Net, 1С), фреймворков, библиотек и инструментов, используемых для разработки.

2.2. Ожидаемые результаты

• Функционирующие и масштабируемые программные модули в соответствии с техническим заданием.
• Снижение количества дефектов в коде за счет использования современных практик тестирования и код-ревью.
• Соответствие разработанного ПО стандартам информационной безопасности и производительности.
• Своевременная документация всех компонентов и API для поддержки и развития.

3.2. Взаимодействие с подразделениями

В процессе выполнения трудовых функций разработчик взаимодействует с:

• Отделом бизнес-анализа и заказчиками для уточнения требований.
• Командой тестирования (QA) для выявления и исправления дефектов.
• Администраторами баз данных (DBA) и системными администраторами для настройки инфраструктуры.
• Службой поддержки (Help Desk) для анализа инцидентов.
• Другими разработчиками в рамках парного программирования и код-ревью.

4.1. Общие обязанности по разработке

Разработчик ПО обязан:

• Разрабатывать программный код на закрепленных языках и технологиях (Java, Go, .Net, 1С) в соответствии с техническим заданием и внутренними стандартами кодирования.
• Осуществлять Fullstack-разработку (при необходимости), включая создание пользовательских интерфейсов и серверной логики.
• Выполнять Backend-разработку, проектировать и реализовывать RESTful API, микросервисы и интеграционные шины данных.
• Проводить рефакторинг существующего кода для повышения его читаемости, производительности и поддерживаемости.

4.2. Проектирование и архитектура

• Участвовать в проектировании архитектуры новых компонентов и систем, выбирать оптимальные шаблоны проектирования и технологические стеки.
• Разрабатывать схемы баз данных (SQL и NoSQL), оптимизировать запросы и структуры хранения данных.
• Создавать и поддерживать техническую документацию: схемы последовательности, диаграммы классов, описание API в формате OpenAPI (Swagger).

4.3. Работа с системами контроля версий и CI/CD

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

4.4. Тестирование и обеспечение качества

• Покрывать разработанный код модульными (unit) и интеграционными тестами, обеспечивая их актуальность при внесении изменений.
• Участвовать в проведении код-ревью (code review) коллег, предоставлять конструктивную обратную связь и рекомендации по улучшению кода.
• Анализировать результаты тестирования, выявленные дефекты и своевременно их устранять.

4.5. Интеграция и сопровождение

• Разрабатывать и поддерживать интеграции с внешними системами и сервисами через API и очереди сообщений.
• Участвовать в расследовании и устранении инцидентов на продуктивных средах, проводить анализ первопричин.
• Выполнять плановое обновление версий библиотек и фреймворков для поддержания безопасности и актуальности стека.

4.6. Документирование и обучение

• Создавать и актуализировать техническую документацию для разработанных модулей, API и сервисов.
• Участвовать в проведении внутренних технических семинаров и вебинаров для обмена знаниями и повышения компетенций команды.
• Обучать новых сотрудников особенностям внутренней архитектуры и принятым стандартам разработки.

5.1. Право на принятие решений

Разработчик имеет право самостоятельно принимать решения в рамках своих должностных обязанностей, в том числе:

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

5.2. Доступ к ресурсам и информации

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

5.3. Право на инициативу и взаимодействие

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

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

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

7.1. Образование и опыт работы

• Высшее образование (бакалавриат/специалитет) в области информационных технологий, вычислительной техники или прикладной математики.
• Опыт коммерческой разработки на одном из языков: Java, Go, .Net (C#), 1С — от 3 лет.
• Опыт работы с реляционными и нереляционными базами данных: PostgreSQL, Oracle, MongoDB, Redis.

7.2. Технические компетенции

• Владение современными фреймворками: Spring Framework (для Java), .NET Core, Gin (для Go).
• Понимание архитектурных паттернов: микросервисы, событийно-ориентированная архитектура, DDD.
• Опыт работы с контейнеризацией и оркестрацией: Docker, Kubernetes.
• Знание и опыт применения Agile-методологий (Scrum, Kanban) в разработке.

7.3. «Мягкие» навыки (Soft Skills)

• Развитое системное и алгоритмическое мышление.
• Способность работать в команде, аргументировать и отстаивать свои технические решения.
• Ответственность, инициативность и ориентация на конечный результат.
• Английский язык на уровне чтения технической документации (Intermediate и выше).

9.1. Основные метрики

Оценка эффективности работы разработчика производится на основе следующих показателей:

• Выполнение плана по задачам (Story Points / задачи) за спринт — не менее 90%.
• Качество кода: показатель покрытия тестами — не менее 75%, количество критических замечаний на код-ревью на 100 строк кода — не более 3.
• Технический долг: своевременное устранение выявленных уязвимостей и проведение рефакторинга.
• Время решения инцидентов: среднее время исправления критического дефекта — не более 4 часов.
• Удовлетворенность заказчика и команды (оценка в рамках ретроспективы).

10.1. Типовой сценарий разработки новой фичи

Разработка новой функции включает следующие этапы:

1. Анализ требований: изучение задачи в бэклоге продукта, уточнение деталей у бизнес-аналитика или заказчика.
2. Проектирование: создание архитектурного предложения, согласование с техлидом, обновление модели данных.
3. Реализация: написание кода на закрепленном стеке (Java/Go/.Net/1С) с параллельным написанием тестов.
4. Код-ревью: передача кода на проверку коллегам, внесение исправлений по замечаниям.
5. Тестирование: интеграция с тестовой средой, выполнение авто- и ручных тестов совместно с QA.
6. Выкатка в продуктив: развертывание на продуктивной среде по согласованному регламенту.
7. Мониторинг: анализ логов и метрик в течение нескольких часов после релиза.

10.2. Чек-лист «Готовность кода к релизу»

• Все модульные и интеграционные тесты успешно проходят (зеленая сборка).
• Код прошел ревью минимум двумя членами команды и не имеет открытых комментариев.
• Обновлена документация API и readme-файлы.
• Задеплоен в стейджинг-среду и проверен на соответствие нефункциональным требованиям.
• Изменения задокументированы в системе управления проектами (Jira/YouTrack) с указанием ссылок на коммиты и пулл-реквесты.
• Проведена проверка на наличие уязвимостей (запуск сканеров безопасности).

10.3. Сценарий реагирования на инцидент

1. Обнаружение: получение оповещения из системы мониторинга (Zabbix, Prometheus) или от службы поддержки.
2. Диагностика: анализ логов, метрик и дампов памяти для определения первопричины сбоя.
3. Восстановление: оперативное развертывание предыдущей стабильной версии (rollback) или применение хотфикса.
4. Коммуникация: уведомление заказчиков и руководства о статусе инцидента и планах по его устранению.
5. Исправление: разработка постоянного решения дефекта и его внедрение в штатном порядке.
6. Завершение: формирование отчета о причинах сбоя и мерах, принятых для предотвращения в будущем (RCA).

10.4. Процесс проведения код-ревью

• Разработчик создает пулл-реквест в Git-репозитории и назначает ревьюверов.
• Ревьюверы проверяют код на соответствие стандартам, читаемость, производительность и наличие тестов.
• Обсуждение замечаний происходит в рамках комментариев к пулл-реквесту или во время синхронизации в мессенджере.
• После внесения всех правок и получения необходимого количества аппрувов (минимум 2) пулл-реквест мержится в основную ветку.