Created by AIImproved by people

Riqli · living documents · updated continuously

Where AI knowledge meets human practice.

Share with friends
Employee Business Process Map. Fullstack Developer. Document. (BPMN. IDEF0. EPC. Work Scenarios. Stage Checklists. Business Processes. SDLC. Agile. Scrum. Git flow. CI/CD. Technical Analysis. Development. Testing. Deployment.)
sections

1. Общие положения

contents

1.1. Назначение документа

Настоящая должностная инструкция определяет статус, функции, обязанности, права и ответственность Fullstack-разработчика организации «General». Документ является основой для оценки соответствия сотрудника занимаемой должности, а также регламентирует его участие в бизнес-процессах разработки и сопровождения программного обеспечения. Положения инструкции обязательны для исполнения всеми сотрудниками, взаимодействующими с разработчиком в рамках SDLC.

contents

1.2. Правовая основа деятельности

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

contents

1.3. Основные термины и определения

В настоящем документе используются следующие термины: «Бизнес-процесс» — совокупность взаимосвязанных мероприятий или работ, направленных на создание определенного продукта или услуги для потребителей. «SDLC» (Software Development Life Cycle) — жизненный цикл разработки программного обеспечения, включающий этапы планирования, анализа, проектирования, реализации, тестирования, внедрения и эксплуатации. «Agile» — подход к управлению проектами, основанный на итеративной разработке и тесном взаимодействии с заказчиком. «Git flow» — модель ветвления в системе контроля версий Git. «CI/CD» — практика непрерывной интеграции и непрерывной доставки изменений в кодовой базе.

sections

2. Цель и задачи должности

contents

2.1. Миссия роли

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

contents

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

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

sections

3. Подчиненность и взаимодействие

contents

3.1. Административная подчиненность

Fullstack-разработчик находится в прямом подчинении у Руководителя отдела разработки (Technical Manager). По вопросам содержания и приоритетов задач сотрудник может подчиняться Продукт-менеджеру и Team Lead в рамках матричной структуры управления проектами. Назначение на должность, перевод и увольнение осуществляются по приказу генерального директора на основании представления руководителя отдела.

contents

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

В рамках должностных обязанностей разработчик активно взаимодействует с командой тестирования (QA) для планирования и выполнения проверок качества. Осуществляется плотная коммуникация с системными аналитиками для уточнения требований и сценариев использования. Также сотрудник консультирует сотрудников отдела эксплуатации по вопросам настройки окружения, конфигурации и поддержания работоспособности систем в продуктивной среде.

sections

4. Должностные обязанности

contents

4.1. Участие в планировании и анализе требований

Разработчик участвует в процессе технического анализа требований, совместно с аналитиками и заказчиками формирует детализированные технические задания. Сотрудник оценивает сложность и трудозатраты на реализацию задач, аргументирует выбор архитектурных решений. Важной частью работы является выявление нефункциональных требований (производительность, безопасность, отказоустойчивость) и их учёт на ранних этапах SDLC.

contents

4.2. Проектирование архитектуры и написание кода

Сотрудник разрабатывает клиентскую и серверную части приложений, используя современные языки программирования и фреймворки. На основе BPMN-диаграмм и EPC-схем проектирует структуру данных, логику обработки запросов и интерфейсы взаимодействия между компонентами. Обязательным является написание чистого, документированного и производительного кода с соблюдением стандартов кодирования и шаблонов проектирования.

contents

4.3. Обеспечение качества и автоматическое тестирование

Fullstack-разработчик несет ответственность за качество разработанного кода, включая написание модульных и интеграционных тестов. Сотрудник активно участвует в настройке CI/CD пайплайнов, обеспечивая автоматическую проверку кода при каждом коммите. Внедряются практики Test-Driven Development (TDD) и Behaviour-Driven Development (BDD) для повышения надежности и предсказуемости разрабатываемых систем.

contents

4.4. Внедрение, деплой и сопровождение

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

contents

4.5. Документирование и трансфер знаний

Разработчик обязан создавать и поддерживать в актуальном состоянии техническую документацию на разработанные компоненты и API. Проведение code review и парного программирования входит в число обязанностей для повышения общего уровня команды. Регулярно проводятся демонстрации готового функционала заинтересованным сторонам в рамках Sprint Review.

contents

4.6. Соблюдение процессов и регламентов

Сотрудник строго следует утвержденным в организации бизнес-процессам и регламентам, включая модели Agile и Scrum. Регулярно обновляет статусы задач в системах управления проектами (Jira, YouTrack), соблюдает правила работы с Git и модели ветвления Git Flow. Все изменения в продуктивной среде выполняются только после прохождения полного цикла тестирования и согласования с руководителем.

sections

5. Права сотрудника

contents

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

Fullstack-разработчик имеет право запрашивать у руководителей и коллег необходимую для работы информацию, техническую документацию, макеты интерфейсов и доступ к базам знаний. Сотруднику предоставляется доступ к репозиториям кода, системам управления задачами, инструментам CI/CD и стендам тестирования в объеме, необходимом для выполнения должностных обязанностей.

contents

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

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

contents

5.3. Право на инициативу и обучение

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

sections

6. Ответственность и подотчетность

contents

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

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

contents

6.2. Качество и сроки выполнения работ

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

sections

7. Квалификационные требования и компетенции

contents

7.1. Требования к образованию и опыту

Для занятия должности Fullstack-разработчика необходимо высшее профессиональное образование в области информационных технологий, математики или смежных дисциплин. Требуется стаж работы по специальности от 3 лет, с опытом разработки коммерческих проектов на современных языках программирования. Обязательным является наличие успешно реализованных проектов с использованием клиент-серверной архитектуры и систем управления базами данных.

contents

7.2. Технические навыки (Hard Skills)

Сотрудник должен владеть языками программирования JavaScript/TypeScript и Python или Java на уровне продвинутого пользователя. Требуется глубокое знание фреймворков для фронтенд (React, Vue.js) и бэкенд (Node.js, Spring Boot) разработки. Обязательны навыки работы с системами контроля версий (Git), базами данных (PostgreSQL, MongoDB), контейнеризацией (Docker) и облачными технологиями.

contents

7.3. Профессиональные и личные качества

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

sections

8. Условия труда и организационные аспекты

contents

8.1. Режим рабочего времени

Режим рабочего времени Fullstack-разработчика определяется правилами внутреннего трудового распорядка и коллективным договором. Возможен гибкий график работы с обязательным присутствием на ключевых совещаниях (ежедневный Daily Stand-up, Planning, Review и Retrospective). Время начала и окончания рабочего дня может быть согласовано с непосредственным руководителем в зависимости от текущих проектных задач.

contents

8.2. Рабочее место и техническое оснащение

Сотруднику предоставляется рабочее место, оснащенное персональным компьютером с необходимым набором программного обеспечения (IDE, системы управления версиями, инструменты отладки). Организация обеспечивает доступ к корпоративной сети, интернету, системам управления проектами и репозиториям. При необходимости выделяются дополнительные лицензионные продукты и услуги облачной инфраструктуры.

sections

9. Показатели эффективности и KPI

contents

9.1. Ключевые показатели производительности разработки

Оценка эффективности включает выполнение плана по Sprint Backlog с точностью выполнения взятых обязательств не менее 90%. Отслеживается количество инцидентов, выявленных в продуктивной среде (не более 2 критических дефектов за релиз). Важным KPI является скорость команды (Velocity) и стабильность ее роста, а также среднее время реагирования на операционные запросы MTTRMTTR.

contents

9.2. Качество кода и технические метрики

Оценивается процент покрытия кода тестами (не менее 80% для критически важных модулей). Учитывается количество предупреждений (warnings) и ошибок в статическом анализе кода (снижение более чем на 15% за квартал). Периодически оценивается сложность кода (Cyclomatic Complexity) и соблюдение стандартов «чистой архитектуры».

contents

9.3. Процессные и поведенческие KPI

Оценивается активность участия в Agile-церемониях, качество проведения code review и вклад в развитие компетенций команды. Учитывается соблюдение сроков обновления статусов задач, полнота документации и обратная связь от коллег. Регулярно проводится оценка уровня владения технологиями по итогам проведенных Tech Talks и внутренних хакатонов.

sections

10. Бизнес-процессы, чек-листы и сценарии работ

contents

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. Релиз и деплой в продуктивную среду: Сопровождение процесса деплоя и мониторинг работы системы первые часы после релиза.
contents

10.2. Сценарий работы: «Исправление критического дефекта (Hotfix)»

Описание процесса: Экстренный процесс для устранения проблем в продуктивной среде.

  • 1. Диагностика и локализация: Анализ ошибок в системах логирования (ELK, Datadog). Выявление корневой причины в коде и данных.
  • 2. Создание хотфикса: Работа в специальной ветке hotfix/..., избегая влияния на текущие разработки. Минимизация изменений для быстрого релиза.
  • 3. Проверка и тестирование: Проведение быстрого, но полного тестирования сценария, который приводил к ошибке. Запуск необходимых автотестов.
  • 4. Экстренный деплой: Развертывание исправления в продуктивной среде через экстренный CI/CD пайплайн. Уведомление заинтересованных сторон.
  • 5. Пост-анализ (Post-Mortem): Документирование причины инцидента и принятых мер. Корректировка чек-листов и тестов для предотвращения повторения.
contents

10.3. Сценарий работы: «Плановый релиз и деплой»

Описание процесса: Выполняется в конце каждого спринта для доставки накопленных изменений пользователям.

  • 1. Подготовка релизного кандидата: Создание ветки release/vX.Y.Z. Обновление версий в файлах конфигурации.
  • 2. Финальное тестирование и стабилизация: Проведение регрессионного тестирования и тестирования производительности.
  • 3. Сборка артефактов и обновление документации: Сборка Docker-образов и загрузка их в реестр. Обновление README и документации к API.
  • 4. Деплой на продуктивную среду (Production): Выполнение миграций баз данных. Обновление контейнеров на кластере (например, Kubernetes).
  • 5. Мониторинг и приемка: Проверка ключевых метрик (CPU, Memory, Latency, Error Rate). Оповещение заказчика об успешном релизе.
contents

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 или важные изменения в системе знаний.
    • Подготовить материал для ретроспективы, если были сложности или обходные пути.
contents

10.5. Участие в Agile-церемониях (Scrum)

Fullstack-разработчик является активным участником всех ключевых событий в рамках Scrum-цикла.

  • Планирование спринта (Sprint Planning): Отбор задач из Product Backlog для выполнения. Оценка трудоемкости в Story Points. Принятие обязательств по объему работы.
  • Ежедневный митинг (Daily Scrum): Краткий отчет о прогрессе, планах на день и блокерах. Актуализация доски задач.
  • Обзор спринта (Sprint Review): Демонстрация завершенных User Stories заказчику. Сбор обратной связи для формирования нового Product Backlog.
  • Ретроспектива спринта (Sprint Retrospective): Анализ прошедшего спринта (что прошло хорошо, что можно улучшить). Определение действий по улучшению бизнес-процессов и командного взаимодействия.
contents

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.

contents

10.7. Взаимодействие с системой управления проектами (Jira)

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

  • Создание/Уточнение задачи: Обеспечивает наличие четкого описания, критериев приемки (Acceptance Criteria) и приоритета (Priority).
  • Выполнение (In Progress): Своевременно переводит задачу в статус «В работе», регулярно обновляет время, затраченное на задачу (Log Work).
  • Ревью (In Review): Переводит задачу в этот статус после создания Pull Request и уведомляет коллег.
  • Тестирование (Testing): Передает задачу в QA с указанием инструкции по тестированию.
  • Готово (Done): Закрывает задачу только после успешного прохождения всех этапов и подтверждения заказчиком.
contents

10.8. Процесс Continuous Integration и Continuous Delivery

CI/CD пайплайны автоматизируют процесс сборки, тестирования и деплоя. Сотрудник отвечает за их поддержание в актуальном состоянии.

  • Непрерывная интеграция (CI): При каждом push в репозиторий автоматически запускаются линтеры (проверка стиля кода), модульные тесты и сборка проекта. Если пайплайн падает, ответственность за исправление лежит на последнем коммитере.
  • Непрерывная доставка (CD): Автоматический деплой успешно собранного артефакта на тестовый стенд (Staging). Для продакшена используется полуавтоматический процесс с подтверждением (manual approval).
  • Инструменты: Используются такие инструменты, как Jenkins, GitLab CI или GitHub Actions. Сотрудник должен уметь настраивать пайплайны и читать логи ошибок сборки.
contents

10.9. Управление техническим долгом

Разработчик активно участвует в выявлении и сокращении технического долга.

  • Идентификация: Выявляет участки кода, требующие рефакторинга, устаревшие зависимости или неоптимальные алгоритмы. Заводит отдельные задачи (Tech Debt Stories) в Product Backlog.
  • Приоритизация: Совместно с архитектором и руководителем оценивает критичность долга и его влияние на бизнес-процессы.
  • Сокращение: В рамках спринта выделяется время (обычно 10-20%) на рефакторинг и улучшение архитектуры. Внедряются практики Boy Scout Rule («оставляй код лучше, чем он был»).
contents

10.10. Безопасность разработки (Security in SDLC)

Вопросы безопасности интегрированы во все этапы SDLC. Fullstack-разработчик обязан:

  • Соблюдать стандарты безопасности при написании кода (избегать SQL-инъекций, XSS-уязвимостей, использовать подготовленные запросы).
  • Использовать инструменты статического анализа безопасности (SAST) и анализа зависимостей на наличие уязвимостей.
  • Участвовать в моделировании угроз (Threat Modeling) для новых фич.
  • Обеспечивать безопасное хранение секретов (переменные окружения, секретные менеджеры вроде Vault).
  • Проходить обучение по основам кибербезопасности и следовать политике информационной безопасности.
contents

10.11. Документирование архитектуры и API

Качество документации напрямую влияет на скорость введения новых разработчиков в проект и коммуникацию со смежными командами.

  • Диаграммы: Создание и актуализация BPMN для бизнес-логики, диаграмм последовательности для сложных взаимодействий и ER-диаграмм для структуры данных.
  • Документация API: Ведение спецификации API в формате OpenAPI (Swagger) для RESTful сервисов, или AsyncAPI для событийных систем.
  • README и руководства: Каждый репозиторий должен содержать актуальный README.md с инструкцией по локальному запуску, настройке окружения и деплою.
contents

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 для связки с задачами.
contents

10.13. Управление конфигурацией и окружениями

Разработчик обеспечивает единообразие окружений разработки, тестирования и продуктивной среды.

  • Конфигурация: Используются файлы конфигурации (.env, application.yml), разделенные по окружениям. Секреты передаются через защищенные каналы, а не через репозитории.
  • Контейнеризация: Разработка ведется с использованием Docker и Docker Compose для локальной разработки, что гарантирует предсказуемость поведения приложения в разных средах.
  • Оркестрация: В продуктивной среде используется Kubernetes или аналогичный оркестратор. Сотрудник должен знать основы работы с кластерами и манифестами.
contents

10.14. Метрики производительности (Performance Metrics)

Разработчик обязан следить за производительностью приложений и принимать меры по ее оптимизации.

  • Основные метрики на стороне клиента:

    • Time to Interactive (TTI) — время интерактивности.
    • Largest Contentful Paint (LCP) — время отрисовки основного контента.
    • Cumulative Layout Shift (CLS) — стабильность визуального отображения.
  • Метрики на стороне сервера:

    • Request Latency — время обработки запроса, включая 95-й и 99-й перцентили.
    • Throughput — количество обрабатываемых запросов в секунду (RPSRPS).
    • Error Rate — процент ошибок запросов (целевой уровень < 0.5%).
  • Инструменты: Для сбора метрик используются Prometheus, Grafana, New Relic, Datadog.