Created by AIImproved by people
Riqli · living documents · updated continuously
Where AI knowledge meets human practice.
Share with friends
1. Общие положения
1.1. Назначение документа
Настоящая должностная инструкция определяет статус, функции, обязанности, права и ответственность Fullstack-разработчика организации «General». Документ является основой для оценки соответствия сотрудника занимаемой должности, а также регламентирует его участие в бизнес-процессах разработки и сопровождения программного обеспечения. Положения инструкции обязательны для исполнения всеми сотрудниками, взаимодействующими с разработчиком в рамках SDLC.
1.2. Правовая основа деятельности
В своей деятельности Fullstack-разработчик руководствуется законодательством о труде, охране интеллектуальной собственности, коммерческой тайне и персональных данных. Сотрудник также обязан соблюдать внутренние нормативные акты: политику информационной безопасности, регламенты использования корпоративных систем, стандарты кодирования и правила работы с конфиденциальной информацией. Все трудовые отношения регулируются действующим Трудовым кодексом и локальными нормативными актами работодателя.
1.3. Основные термины и определения
В настоящем документе используются следующие термины: «Бизнес-процесс» — совокупность взаимосвязанных мероприятий или работ, направленных на создание определенного продукта или услуги для потребителей. «SDLC» (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения, включающий этапы планирования, анализа, проектирования, реализации, тестирования, внедрения и эксплуатации. «Agile» — подход к управлению проектами, основанный на итеративной разработке и тесном взаимодействии с заказчиком. «Git flow» — модель ветвления в системе контроля версий Git. «CI/CD» — практика непрерывной интеграции и непрерывной доставки изменений в кодовой базе.
2. Цель и задачи должности
2.1. Миссия роли
Миссия Fullstack-разработчика заключается в обеспечении технологического лидерства организации через создание и поддержку высококачественных, производительных и безопасных веб-приложений. Сотрудник реализует полный цикл разработки — от анализа требований до эксплуатации продукта в промышленной среде. Роль направлена на трансформацию бизнес-потребностей в эффективные программные решения, используя современный стек технологий и передовые практики инженерии.
2.2. Ожидаемые результаты деятельности
Ключевые результаты работы включают стабильно работающий и масштабируемый код, соответствующий требованиям бизнеса и стандартам качества. Разработчик отвечает за снижение технического долга, повышение автоматизации тестирования и ускорение вывода новых функций на рынок. Ожидается, что деятельность сотрудника будет напрямую влиять на увеличение скорости работы команд и улучшение ключевых показателей производительности приложений.
3. Подчиненность и взаимодействие
3.1. Административная подчиненность
Fullstack-разработчик находится в прямом подчинении у Руководителя отдела разработки (Technical Manager). По вопросам содержания и приоритетов задач сотрудник может подчиняться Продукт-менеджеру и Team Lead в рамках матричной структуры управления проектами. Назначение на должность, перевод и увольнение осуществляются по приказу генерального директора на основании представления руководителя отдела.
3.2. Взаимодействие с подразделениями
В рамках должностных обязанностей разработчик активно взаимодействует с командой тестирования (QA) для планирования и выполнения проверок качества. Осуществляется плотная коммуникация с системными аналитиками для уточнения требований и сценариев использования. Также сотрудник консультирует сотрудников отдела эксплуатации по вопросам настройки окружения, конфигурации и поддержания работоспособности систем в продуктивной среде.
4. Должностные обязанности
4.1. Участие в планировании и анализе требований
Разработчик участвует в процессе технического анализа требований, совместно с аналитиками и заказчиками формирует детализированные технические задания. Сотрудник оценивает сложность и трудозатраты на реализацию задач, аргументирует выбор архитектурных решений. Важной частью работы является выявление нефункциональных требований (производительность, безопасность, отказоустойчивость) и их учёт на ранних этапах SDLC.
4.2. Проектирование архитектуры и написание кода
Сотрудник разрабатывает клиентскую и серверную части приложений, используя современные языки программирования и фреймворки. На основе BPMN-диаграмм и EPC-схем проектирует структуру данных, логику обработки запросов и интерфейсы взаимодействия между компонентами. Обязательным является написание чистого, документированного и производительного кода с соблюдением стандартов кодирования и шаблонов проектирования.
4.3. Обеспечение качества и автоматическое тестирование
Fullstack-разработчик несет ответственность за качество разработанного кода, включая написание модульных и интеграционных тестов. Сотрудник активно участвует в настройке CI/CD пайплайнов, обеспечивая автоматическую проверку кода при каждом коммите. Внедряются практики Test-Driven Development (TDD) и Behaviour-Driven Development (BDD) для повышения надежности и предсказуемости разрабатываемых систем.
4.4. Внедрение, деплой и сопровождение
В рамках процесса деплоя сотрудник осуществляет развертывание приложений на стендах тестирования и в продуктивной среде. Разработчик участвует в инцидент-менеджменте, осуществляя диагностику и исправление ошибок в эксплуатационной фазе SDLC. Ведется постоянный мониторинг производительности и стабильности работы сервисов с использованием систем логирования и алертинга.
4.5. Документирование и трансфер знаний
Разработчик обязан создавать и поддерживать в актуальном состоянии техническую документацию на разработанные компоненты и API. Проведение code review и парного программирования входит в число обязанностей для повышения общего уровня команды. Регулярно проводятся демонстрации готового функционала заинтересованным сторонам в рамках Sprint Review.
4.6. Соблюдение процессов и регламентов
Сотрудник строго следует утвержденным в организации бизнес-процессам и регламентам, включая модели Agile и Scrum. Регулярно обновляет статусы задач в системах управления проектами (Jira, YouTrack), соблюдает правила работы с Git и модели ветвления Git Flow. Все изменения в продуктивной среде выполняются только после прохождения полного цикла тестирования и согласования с руководителем.
5. Права сотрудника
5.1. Право на информацию и доступ
Fullstack-разработчик имеет право запрашивать у руководителей и коллег необходимую для работы информацию, техническую документацию, макеты интерфейсов и доступ к базам знаний. Сотруднику предоставляется доступ к репозиториям кода, системам управления задачами, инструментам CI/CD и стендам тестирования в объеме, необходимом для выполнения должностных обязанностей.
5.2. Право на принятие решений
В рамках своих компетенций разработчик имеет право самостоятельно выбирать инструменты и алгоритмы реализации задач, если это не противоречит архитектурным стандартам и требованиям безопасности. Сотрудник вправе предлагать изменения в технологический стек и процессы разработки для повышения эффективности. Участвует в принятии архитектурных решений и выборе сторонних библиотек и сервисов.
5.3. Право на инициативу и обучение
Разработчик имеет право вносить предложения по улучшению пользовательского опыта и функциональности разрабатываемых продуктов. Сотруднику предоставляется право на прохождение дополнительного обучения, сертификации и участие в профессиональных конференциях за счет организации. Поощряется инициатива по оптимизации внутренних бизнес-процессов разработки и тестирования.
6. Ответственность и подотчетность
6.1. Дисциплинарная и материальная ответственность
Разработчик несет дисциплинарную ответственность за неисполнение или ненадлежащее исполнение своих должностных обязанностей, нарушение правил внутреннего распорядка и требований по охране труда. За причинение материального ущерба организации сотрудник отвечает в пределах, установленных трудовым законодательством. Ответственность возникает за разглашение коммерческой тайны и конфиденциальных данных, доступ к которым был получен в ходе работы.
6.2. Качество и сроки выполнения работ
Сотрудник ответственен за соблюдение стандартов качества кода, архитектурных решений и сроков, указанных в Sprint Backlog и дорожных картах проектов. Любое отставание от графика или снижение показателей качества должно быть немедленно доведено до сведения руководителя с предложением плана корректирующих действий. Персональная ответственность устанавливается за стабильность работы закрепленных за разработчиком сервисов в продуктивной среде.
7. Квалификационные требования и компетенции
7.1. Требования к образованию и опыту
Для занятия должности Fullstack-разработчика необходимо высшее профессиональное образование в области информационных технологий, математики или смежных дисциплин. Требуется стаж работы по специальности от 3 лет, с опытом разработки коммерческих проектов на современных языках программирования. Обязательным является наличие успешно реализованных проектов с использованием клиент-серверной архитектуры и систем управления базами данных.
7.2. Технические навыки (Hard Skills)
Сотрудник должен владеть языками программирования JavaScript/TypeScript и Python или Java на уровне продвинутого пользователя. Требуется глубокое знание фреймворков для фронтенд (React, Vue.js) и бэкенд (Node.js, Spring Boot) разработки. Обязательны навыки работы с системами контроля версий (Git), базами данных (PostgreSQL, MongoDB), контейнеризацией (Docker) и облачными технологиями.
7.3. Профессиональные и личные качества
Важными компетенциями являются аналитическое мышление, способность к системному анализу и декомпозиции сложных задач. Необходимы развитые коммуникативные навыки для работы в команде, умение аргументировать технические решения и обучать коллег. Сотрудник должен быть ориентирован на результат, обладать высокой самоорганизацией и способностью работать в условиях многозадачности и жестких дедлайнов.
8. Условия труда и организационные аспекты
8.1. Режим рабочего времени
Режим рабочего времени Fullstack-разработчика определяется правилами внутреннего трудового распорядка и коллективным договором. Возможен гибкий график работы с обязательным присутствием на ключевых совещаниях (ежедневный Daily Stand-up, Planning, Review и Retrospective). Время начала и окончания рабочего дня может быть согласовано с непосредственным руководителем в зависимости от текущих проектных задач.
8.2. Рабочее место и техническое оснащение
Сотруднику предоставляется рабочее место, оснащенное персональным компьютером с необходимым набором программного обеспечения (IDE, системы управления версиями, инструменты отладки). Организация обеспечивает доступ к корпоративной сети, интернету, системам управления проектами и репозиториям. При необходимости выделяются дополнительные лицензионные продукты и услуги облачной инфраструктуры.
9. Показатели эффективности и KPI
9.1. Ключевые показатели производительности разработки
Оценка эффективности включает выполнение плана по Sprint Backlog с точностью выполнения взятых обязательств не менее 90%. Отслеживается количество инцидентов, выявленных в продуктивной среде (не более 2 критических дефектов за релиз). Важным KPI является скорость команды (Velocity) и стабильность ее роста, а также среднее время реагирования на операционные запросы .
9.2. Качество кода и технические метрики
Оценивается процент покрытия кода тестами (не менее 80% для критически важных модулей). Учитывается количество предупреждений (warnings) и ошибок в статическом анализе кода (снижение более чем на 15% за квартал). Периодически оценивается сложность кода (Cyclomatic Complexity) и соблюдение стандартов «чистой архитектуры».
9.3. Процессные и поведенческие KPI
Оценивается активность участия в Agile-церемониях, качество проведения code review и вклад в развитие компетенций команды. Учитывается соблюдение сроков обновления статусов задач, полнота документации и обратная связь от коллег. Регулярно проводится оценка уровня владения технологиями по итогам проведенных Tech Talks и внутренних хакатонов.
10. Бизнес-процессы, чек-листы и сценарии работ
10.1. Сценарий работы: «Разработка новой функциональности»
Описание процесса: Fullstack-разработчик участвует в полном цикле создания фичи, начиная с анализа требований и заканчивая передачей в эксплуатацию.
- 1. Анализ и уточнение требований: Изучение User Story и Acceptance Criteria. Участие в Sprint Planning для оценки трудозатрат. Формирование вопросов к заказчику и аналитику.
- 2. Проектирование и дизайн: Создание EPC-диаграммы или BPMN-модели для понимания логики процесса. Проектирование API и структуры БД.
- 3. Разработка (Implementation): Написание кода фронтенд и бэкенд частей с использованием Git Flow. Создание ветки
feature/..., регулярные коммиты с понятными сообщениями. - 4. Тестирование: Написание модульных тестов и интеграционных тестов. Проведение локального тестирования функциональности.
- 5. Code Review и интеграция: Создание Pull Request (Merge Request) для code review коллегами. Внесение правок и успешный проход всех CI/CD пайплайнов (линтеры, тесты, сборка).
- 6. Деплой на тестовый стенд: Развертывание изменений для QA и демонстрация функционала на Sprint Review.
- 7. Релиз и деплой в продуктивную среду: Сопровождение процесса деплоя и мониторинг работы системы первые часы после релиза.
10.2. Сценарий работы: «Исправление критического дефекта (Hotfix)»
Описание процесса: Экстренный процесс для устранения проблем в продуктивной среде.
- 1. Диагностика и локализация: Анализ ошибок в системах логирования (
ELK,Datadog). Выявление корневой причины в коде и данных. - 2. Создание хотфикса: Работа в специальной ветке
hotfix/..., избегая влияния на текущие разработки. Минимизация изменений для быстрого релиза. - 3. Проверка и тестирование: Проведение быстрого, но полного тестирования сценария, который приводил к ошибке. Запуск необходимых автотестов.
- 4. Экстренный деплой: Развертывание исправления в продуктивной среде через экстренный CI/CD пайплайн. Уведомление заинтересованных сторон.
- 5. Пост-анализ (Post-Mortem): Документирование причины инцидента и принятых мер. Корректировка чек-листов и тестов для предотвращения повторения.
10.3. Сценарий работы: «Плановый релиз и деплой»
Описание процесса: Выполняется в конце каждого спринта для доставки накопленных изменений пользователям.
- 1. Подготовка релизного кандидата: Создание ветки
release/vX.Y.Z. Обновление версий в файлах конфигурации. - 2. Финальное тестирование и стабилизация: Проведение регрессионного тестирования и тестирования производительности.
- 3. Сборка артефактов и обновление документации: Сборка Docker-образов и загрузка их в реестр. Обновление README и документации к API.
- 4. Деплой на продуктивную среду (Production): Выполнение миграций баз данных. Обновление контейнеров на кластере (например,
Kubernetes). - 5. Мониторинг и приемка: Проверка ключевых метрик (CPU, Memory, Latency, Error Rate). Оповещение заказчика об успешном релизе.
10.4. Чек-лист этапов для стандартной задачи (User Story)
Полный перечень действий, которые Fullstack-разработчик должен выполнить для успешного закрытия задачи.
1. Этап «Планирование и анализ»:
- Изучить требования и выделить подзадачи.
- Оценить время выполнения (в часах) и согласовать с руководителем.
- Создать или обновить BPMN-диаграмму, если задача затрагивает бизнес-логику.
2. Этап «Разработка»:
- Создать ветку в репозитории от актуальной
develop. - Реализовать логику и написать код, следуя стандартам кодирования.
- Написать модульные и интеграционные тесты.
- Проверить код на соответствие производительности и требованиям безопасности.
- Закоммитить и запушить изменения.
- Создать ветку в репозитории от актуальной
3. Этап «Качество и интеграция»:
- Создать Merge Request (Pull Request).
- Пройти процесс code review и устранить все замечания.
- Убедиться, что все CI/CD пайплайны проходят успешно (линтер, сборка, тесты).
- Залить изменения в ветку
develop(merge).
4. Этап «Тестирование и демонстрация»:
- Развернуть актуальный билд на тестовом стенде.
- Провести смоук-тестирование и передать задачу в QA.
- Принять участие в Sprint Review и показать результат заказчику.
5. Этап «Закрытие и документация»:
- Обновить статус задачи в Jira на «Done».
- Задокументировать новые API или важные изменения в системе знаний.
- Подготовить материал для ретроспективы, если были сложности или обходные пути.
10.5. Участие в Agile-церемониях (Scrum)
Fullstack-разработчик является активным участником всех ключевых событий в рамках Scrum-цикла.
- Планирование спринта (Sprint Planning): Отбор задач из Product Backlog для выполнения. Оценка трудоемкости в Story Points. Принятие обязательств по объему работы.
- Ежедневный митинг (Daily Scrum): Краткий отчет о прогрессе, планах на день и блокерах. Актуализация доски задач.
- Обзор спринта (Sprint Review): Демонстрация завершенных User Stories заказчику. Сбор обратной связи для формирования нового Product Backlog.
- Ретроспектива спринта (Sprint Retrospective): Анализ прошедшего спринта (что прошло хорошо, что можно улучшить). Определение действий по улучшению бизнес-процессов и командного взаимодействия.
10.6. Работа с Git и моделью ветвления
Git Flow является стандартной моделью ветвления в организации. Сотрудник строго соблюдает следующие правила.
Основные ветки:
master/main— всегда содержит код, готовый к релизу в продуктивную среду.develop— основная ветка для интеграции изменений перед релизом.
Вспомогательные ветки:
feature/— создаются отdevelopдля разработки новых функций.release/— создаются отdevelopдля подготовки релизного кандидата.hotfix/— создаются отmasterдля экстренного исправления критических ошибок.
Правила коммитов: Сообщения коммитов должны быть информативными и следовать соглашению (например, Conventional Commits). Запрещается коммитить большие, не связанные между собой изменения в одном коммите.
Интеграция (Merge): Вливание в
developиmasterпроисходит только через Pull Request после прохождения code review и успешной сборки в CI/CD.
10.7. Взаимодействие с системой управления проектами (Jira)
Все задачи и дефекты фиксируются в системе Jira или аналогичной, используемой в организации. Разработчик соблюдает жизненный цикл задач.
- Создание/Уточнение задачи: Обеспечивает наличие четкого описания, критериев приемки (Acceptance Criteria) и приоритета (Priority).
- Выполнение (In Progress): Своевременно переводит задачу в статус «В работе», регулярно обновляет время, затраченное на задачу (Log Work).
- Ревью (In Review): Переводит задачу в этот статус после создания Pull Request и уведомляет коллег.
- Тестирование (Testing): Передает задачу в QA с указанием инструкции по тестированию.
- Готово (Done): Закрывает задачу только после успешного прохождения всех этапов и подтверждения заказчиком.
10.8. Процесс Continuous Integration и Continuous Delivery
CI/CD пайплайны автоматизируют процесс сборки, тестирования и деплоя. Сотрудник отвечает за их поддержание в актуальном состоянии.
- Непрерывная интеграция (CI): При каждом push в репозиторий автоматически запускаются линтеры (проверка стиля кода), модульные тесты и сборка проекта. Если пайплайн падает, ответственность за исправление лежит на последнем коммитере.
- Непрерывная доставка (CD): Автоматический деплой успешно собранного артефакта на тестовый стенд (Staging). Для продакшена используется полуавтоматический процесс с подтверждением (manual approval).
- Инструменты: Используются такие инструменты, как
Jenkins,GitLab CIилиGitHub Actions. Сотрудник должен уметь настраивать пайплайны и читать логи ошибок сборки.
10.9. Управление техническим долгом
Разработчик активно участвует в выявлении и сокращении технического долга.
- Идентификация: Выявляет участки кода, требующие рефакторинга, устаревшие зависимости или неоптимальные алгоритмы. Заводит отдельные задачи (Tech Debt Stories) в Product Backlog.
- Приоритизация: Совместно с архитектором и руководителем оценивает критичность долга и его влияние на бизнес-процессы.
- Сокращение: В рамках спринта выделяется время (обычно 10-20%) на рефакторинг и улучшение архитектуры. Внедряются практики Boy Scout Rule («оставляй код лучше, чем он был»).
10.10. Безопасность разработки (Security in SDLC)
Вопросы безопасности интегрированы во все этапы SDLC. Fullstack-разработчик обязан:
- Соблюдать стандарты безопасности при написании кода (избегать SQL-инъекций, XSS-уязвимостей, использовать подготовленные запросы).
- Использовать инструменты статического анализа безопасности (SAST) и анализа зависимостей на наличие уязвимостей.
- Участвовать в моделировании угроз (Threat Modeling) для новых фич.
- Обеспечивать безопасное хранение секретов (переменные окружения, секретные менеджеры вроде
Vault). - Проходить обучение по основам кибербезопасности и следовать политике информационной безопасности.
10.11. Документирование архитектуры и API
Качество документации напрямую влияет на скорость введения новых разработчиков в проект и коммуникацию со смежными командами.
- Диаграммы: Создание и актуализация BPMN для бизнес-логики, диаграмм последовательности для сложных взаимодействий и ER-диаграмм для структуры данных.
- Документация API: Ведение спецификации API в формате
OpenAPI (Swagger)для RESTful сервисов, илиAsyncAPIдля событийных систем. - README и руководства: Каждый репозиторий должен содержать актуальный
README.mdс инструкцией по локальному запуску, настройке окружения и деплою.
10.12. Моделирование бизнес-процессов с использованием BPMN и EPC
Fullstack-разработчик использует нотации для визуализации и анализа процессов.
- BPMN (Business Process Model and Notation): Применяется для описания взаимодействия пользователя с системой, потоков данных и логики принятия решений. Разработчик участвует в создании BPMN-диаграмм на этапе проектирования.
- EPC (Event-driven Process Chain): Используется для описания последовательности функций, событий и логических операторов (AND, OR, XOR), связывающих бизнес-процессы с информационными системами.
- Инструменты: Для моделирования используются инструменты вроде
Camunda Modeler,Draw.ioили модули внутриJiraдля связки с задачами.
10.13. Управление конфигурацией и окружениями
Разработчик обеспечивает единообразие окружений разработки, тестирования и продуктивной среды.
- Конфигурация: Используются файлы конфигурации (
.env,application.yml), разделенные по окружениям. Секреты передаются через защищенные каналы, а не через репозитории. - Контейнеризация: Разработка ведется с использованием
DockerиDocker Composeдля локальной разработки, что гарантирует предсказуемость поведения приложения в разных средах. - Оркестрация: В продуктивной среде используется
Kubernetesили аналогичный оркестратор. Сотрудник должен знать основы работы с кластерами и манифестами.
10.14. Метрики производительности (Performance Metrics)
Разработчик обязан следить за производительностью приложений и принимать меры по ее оптимизации.
Основные метрики на стороне клиента:
- Time to Interactive (TTI) — время интерактивности.
- Largest Contentful Paint (LCP) — время отрисовки основного контента.
- Cumulative Layout Shift (CLS) — стабильность визуального отображения.
Метрики на стороне сервера:
- Request Latency — время обработки запроса, включая 95-й и 99-й перцентили.
- Throughput — количество обрабатываемых запросов в секунду ().
- Error Rate — процент ошибок запросов (целевой уровень < 0.5%).
Инструменты: Для сбора метрик используются
Prometheus,Grafana,New Relic,Datadog.