Created by AIImproved by people

Riqli · living documents · updated continuously

Where AI knowledge meets human practice.

Share with friends
Employee Business Process Map. Software Developer (Fullstack, Backend, Java, Go, .Net, 1C). Document. (BPMN. IDEF0. EPC. Work Scenarios. Checklists of Stages. Business Processes. Requirements Analysis. Architecture Design. Development. Testing. Release. Maintenance.)
sections

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

contents

1.1. Назначение и область применения документа

Настоящий документ описывает бизнес-процессы сотрудника на позиции разработчика ПО (Fullstack, Backend, Java, Go, .Net, 1С) в организации «General». Документ устанавливает единые требования к выполнению должностных обязанностей, взаимодействию со смежными подразделениями, а также определяет перечень и последовательность действий при реализации проектов по разработке, сопровождению и модернизации программного обеспечения. Положения документа обязательны для исполнения всеми сотрудниками, занимающими должности, связанные с разработкой и поддержкой ПО, и вступают в силу с момента утверждения руководителем организации.

contents

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

Деятельность разработчика ПО регламентируется следующими нормативными и организационно-распорядительными документами: Трудовой кодекс РФ, локальные нормативные акты организации «General», включая правила внутреннего трудового распорядка, политику информационной безопасности, регламент управления конфигурацией и изменениями, а также настоящей должностной инструкцией. Кроме того, сотрудник руководствуется технической документацией на разрабатываемые программные продукты, стандартами предприятия по оформлению кода и документации, а также распоряжениями и указаниями непосредственного руководителя и вышестоящего руководства.

contents

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

В настоящем документе используются следующие термины и их определения: Бизнес-процесс — совокупность взаимосвязанных мероприятий или задач, направленных на создание определенного продукта или услуги для потребителей. Разработка ПО — деятельность, включающая анализ требований, проектирование, кодирование, тестирование и сопровождение программного обеспечения. Релиз — процесс выпуска готовой версии программного продукта в эксплуатационную среду. Сопровождение — деятельность по поддержанию работоспособности и модернизации ПО после его ввода в эксплуатацию. BPMN (Business Process Model and Notation) — стандарт графической нотации для моделирования бизнес-процессов. IDEF0 — методология функционального моделирования, используемая для описания и анализа бизнес-процессов. EPC (Event-driven Process Chain) — нотация для описания процессов, управляемых событиями.

sections

2. Цель работы и сфера ответственности

contents

2.1. Миссия должности

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

contents

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

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

sections

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

contents

3.1. Административное и функциональное подчинение

Разработчик ПО непосредственно подчиняется руководителю группы разработки (Team Lead) или руководителю проектного офиса. В рамках реализации конкретных проектов может назначаться руководитель проекта (Project Manager), которому сотрудник подчиняется по вопросам сроков, приоритетов и содержания задач. По вопросам архитектурных решений и методологии разработки сотрудник взаимодействует с архитектором ПО (Solution Architect) и руководством департамента разработки.

contents

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

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

  • отделом бизнес-анализа и заказчиками — для уточнения и формализации требований к ПО;
  • отделом тестирования (QA) — для организации и проведения тестирования, анализа дефектов и проверки исправлений;
  • отделом эксплуатации и DevOps — для развертывания, настройки сред и обеспечения непрерывной доставки;
  • отделом информационной безопасности — для соблюдения требований защиты информации;
  • службой поддержки (HelpDesk) — для передачи инцидентов и консультаций по использованию ПО.

sections

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

contents

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

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

contents

4.2. Проектирование архитектуры и технологических решений

Разработчик проектирует архитектуру программных модулей и компонентов в соответствии с утвержденными архитектурными принципами и стандартами организации. Разрабатывает диаграммы потоков данных, схемы баз данных, спецификации API, а также модели бизнес-процессов в нотациях BPMN, IDEF0, EPC для наглядного представления логики работы системы. Выбирает оптимальные технологии, библиотеки и фреймворки для решения поставленных задач, обосновывает технические решения на архитектурных комитетах. Обеспечивает соответствие проектируемых решений нефункциональным требованиям — производительности, масштабируемости, безопасности и надежности.

contents

4.3. Разработка и кодирование

Разработчик пишет программный код на языках Java, Go, .Net, 1С (в зависимости от стека проектов) с использованием сред разработки (IntelliJ IDEA, VS Code, Eclipse и др.), систем управления версиями (Git, SVN) и инструментов сборки (Maven, Gradle, Go Modules, MSBuild). Соблюдает стандарты кодирования (Code Conventions), принципы «Чистого кода» (Clean Code), паттерны проектирования и best practices для каждого языка и платформы. Реализует полный цикл разработки: от создания структур данных и сервисов до реализации пользовательского интерфейса (для Fullstack). Обеспечивает автоматическое тестирование разработанного кода на уровне юнит-тестов и интеграционных тестов с использованием фреймворков JUnit, TestNG, pytest, xUnit и др.

contents

4.4. Ведение технической документации

Сотрудник составляет и поддерживает в актуальном состоянии техническую документацию на разрабатываемое ПО: описание архитектуры, руководство разработчика, спецификации API, инструкции по сборке и развертыванию, комментарии в коде. Оформляет документацию в соответствии со стандартами организации, включая использование wiki-систем (Confluence, Notion) и систем управления документацией. Обеспечивает документирование всех этапов бизнес-процессов, связанных с разработкой и сопровождением ПО, включая сценарии работ и чек-листы этапов для воспроизводимости и контроля качества.

contents

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

Разработчик участвует в организации и проведении различных видов тестирования: модульное, интеграционное, системное, регрессионное и приемочное. Разрабатывает и поддерживает автоматизированные тесты, включая тесты API, UI-тесты и нагрузочные тесты с использованием инструментов Selenium, JMeter, Gatling, Postman. Проводит ревью кода коллег, выявляет потенциальные проблемы и дает рекомендации по улучшению кода. Совместно с отделом тестирования участвует в планировании тестовых сценариев, анализе дефектов, их локализации и исправлении. Отвечает за качество и стабильность кода перед передачей в релиз.

contents

4.6. Релиз и развертывание

В рамках релизного процесса разработчик подготавливает сборку и дистрибутивы ПО, участвует в настройке параметров для различных сред (разработки, тестирования, предпродакшн, продакшн). Создает и поддерживает сценарии автоматизации развертывания с использованием инструментов CI/CD (Jenkins, GitLab CI/CD, GitHub Actions, TeamCity). Участвует в проведении релизных собраний, согласовании сроков и объемов релизов, а также в процедурах приемки релиза заказчиком. Выполняет чек-листы этапов релиза для минимизации рисков и обеспечения контролируемого вывода ПО в эксплуатацию.

contents

4.7. Сопровождение и поддержка пользователей

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

sections

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

contents

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

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

contents

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

Сотрудник имеет право запрашивать и получать от руководителя и смежных подразделений всю необходимую информацию для выполнения должностных обязанностей, включая техническое задание, спецификации, документацию, а также доступ к системам управления проектами (Jira, Trello, Azure DevOps), репозиториям кода, средам разработки и тестирования, и другим ресурсам, предоставляемым организацией для работы. В рамках своих должностных обязанностей разработчик получает доступ к базам данных, API, серверам и инструментам мониторинга в соответствии с политикой информационной безопасности.

contents

5.3. Право на повышение квалификации

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

sections

6. Ответственность

contents

6.1. Ответственность за качество и сроки

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

contents

6.2. Соблюдение информационной безопасности

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

contents

6.3. Соблюдение методологии и регламентов

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

sections

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

contents

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

На должность разработчика ПО назначается лицо, имеющее высшее профессиональное образование по специальности «Программная инженерия», «Информатика и вычислительная техника», «Прикладная математика» или смежным направлениям. Требуется опыт работы в области разработки ПО не менее 2 лет для уровня Junior и не менее 4-6 лет для уровней Middle и Senior. Опыт работы с соответствующим стеком технологий (Java/Go/.Net/1С) подтверждается рекомендациями или примерами завершенных проектов.

contents

7.2. Профессиональные знания и навыки

Разработчик должен обладать глубокими знаниями в следующих областях:

  • Языки программирования: Java (Spring Framework, Hibernate), Go (Gin, Echo, GORM), .NET (ASP.NET Core, Entity Framework), 1С (встроенный язык, управляемые формы, расширения, интеграция);
  • Базы данных: реляционные (PostgreSQL, MySQL, Oracle, Microsoft SQL Server) и NoSQL (MongoDB, Redis, Cassandra);
  • Инструменты разработки: Git, Maven/Gradle, Docker, Kubernetes, Jenkins, Jira, Confluence;
  • Архитектура: микросервисная архитектура, REST API, SOAP, Event-Driven Architecture, message brokers (RabbitMQ, Apache Kafka);
  • Методологии: Agile (Scrum, Kanban), DevOps, CI/CD, принципы SOLID, паттерны проектирования;
  • Тестирование: TDD, BDD, автоматизированное тестирование, нагрузочное и профилирование.

contents

7.3. Сертификация и непрерывное обучение

Приветствуется наличие сертификаций: Oracle Certified Professional (OCP) для Java, Microsoft Certified: Azure Developer Associate для .Net, специализированные сертификации по 1С (1С:Специалист, 1С:Эксперт). Сотрудник должен проявлять активность в профессиональном развитии, участвовать в митапах, читать техническую литературу и проходить курсы повышения квалификации.

sections

8. Условия работы

contents

8.1. Режим работы и график

Режим работы разработчика определяется правилами внутреннего трудового распорядка организации «General» и может предусматривать гибкий график при выполнении плановых задач и соблюдении часов присутствия в рабочее время. При необходимости сотрудник может привлекаться к работе в выходные и праздничные дни с оплатой согласно ТК РФ и локальным актам. Удаленная работа допускается при наличии технической возможности и утверждения со стороны руководителя в соответствии с политикой организации.

contents

8.2. Обеспечение рабочего места и инструментами

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

contents

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

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

sections

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

contents

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

Для оценки эффективности разработчика устанавливаются следующие KPI: процент выполнения плана по задачам в спринте (Velocity); количество и серьезность дефектов, обнаруженных на этапе тестирования и в эксплуатации (Defect Density); соблюдение сроков релизов (SLA on Time Delivery); качество и полнота технической документации; соответствие кода стандартам и результатам ревью; частота и успешность автоматических сборок и деплоев (CI/CD success rate); среднее время восстановления после инцидентов (Mean Time To Recovery — MTTR). Допустимые целевые значения KPI ежегодно утверждаются руководителем департамента и доводятся до сотрудников в начале отчетного периода.

contents

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

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

contents

9.3. Обратная связь и развитие

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

sections

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

contents

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

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

  • Инициация и анализ: поступление запроса от заказчика или владельца продукта, уточнение требований, формирование пользовательской истории, оценка трудоемкости на основе декомпозиции;
  • Проектирование: создание архитектурного черновика, моделирование бизнес-процессов в нотации BPMN/EPC для выбранной функциональности, разработка схемы данных и API-спецификаций (Swagger/OpenAPI), согласование с архитектором;
  • Разработка: создание отдельной ветки (feature branch) от актуальной версии кода, написание кода с соблюдением стандартов и тестов, локальное тестирование;
  • Ревью и интеграция: создание Pull Request (Merge Request), обязательное ревью кода как минимум двумя разработчиками, интеграция кода в основную ветку при положительном ревью;
  • Тестирование в среде разработки: развертывание на тестовом стенде, проведение интеграционных тестов и исследовательского тестирования, фиксация дефектов;
  • Релиз: подготовка релизной сборки, проведение приемочного тестирования в среде, приближенной к промышленной, согласование вывода в эксплуатацию;
  • Сопровождение: мониторинг работы новой функциональности в промышленной среде, оперативное реагирование на инциденты, сбор обратной связи.

contents

10.2. Бизнес-процесс «Исправление инцидентов и ошибок» (IDEF0/EPC)

Процесс исправления ошибок и обработки инцидентов в продукте реализуется по следующей схеме:

  • Обнаружение: инцидент поступает через систему HelpDesk, мониторинг (Zabbix, Grafana) или сообщается пользователями;
  • Классификация: оценка критичности (P1 — критический, P2 — высокий, P3 — средний, P4 — низкий), определение влияния на бизнес-процессы и пользователей;
  • Локализация: воспроизведение ошибки в тестовой среде, анализ логов (ELK Stack) и кода для определения причины;
  • Исправление и тестирование: внесение изменений в коде, создание юнит-тестов для воспроизведения и устранения ошибки, проведение регрессионного тестирования;
  • Релиз с исправлением: внеплановая сборка и развертывание (hotfix) для критических ошибок или включение в ближайший плановый релиз для некритических;
  • Закрытие инцидента: уведомление службы поддержки и пользователей о решении проблемы, обновление документации и базы знаний;
  • Ретроспектива: анализ причины ошибки, предложение мер для предотвращения подобных проблем в будущем (улучшение тестов, рефакторинг, обновление инструментов).

contents

10.3. Чек-лист этапов для релиза ПО

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

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

contents

10.4. Сценарии работ для типовых операций

Для повышения эффективности и унификации труда разработчика разрабатываются и поддерживаются типовые сценарии работ (рабочие инструкции) по следующим направлениям:

  • Настройка локальной среды разработки — установка необходимых инструментов, клонирование репозиториев, настройка конфигураций и переменных окружения;
  • Работа с системой управления версиями — ветвление, коммиты, разрешение конфликтов, создание и ревью Pull Request'ов;
  • Взаимодействие с CI/CD — запуск сборок и деплоев, анализ отчетов о сборках, устранение ошибок сборки;
  • Работа с системами мониторинга и логирования — анализ логов, настройка дашбордов, формирование запросов к системам;
  • Взаимодействие со службой поддержки — прием и обработка инцидентов, консультирование, передача решений в базу знаний.
Данные сценарии доводятся до сотрудников на этапе адаптации и обновляются при изменении процессов или инструментов.