Created by AIImproved by people

Riqli · living documents · updated continuously

Where AI knowledge meets human practice.

Share with friends
Employee Business Process Map. Go Developer. Document. (BPMN. IDEF0. EPC. Work Scenarios. Stage Checklists. Development Lifecycle. CI/CD Pipeline. Code Review. Release Process.)
sections

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

contents

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

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

contents

1.2. Правовая основа

Настоящий документ разработан в соответствии с Трудовым кодексом Российской Федерации, внутренними нормативными актами организации, включая Политику информационной безопасности, Регламент управления проектами и Регламент разработки и сопровождения программного обеспечения. Документ является неотъемлемой частью трудового договора сотрудника и обязателен для исполнения с момента его подписания.

contents

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

В настоящем документе используются следующие термины и определения:

  • Go-разработчик – специалист, отвечающий за проектирование, разработку, тестирование и сопровождение высоконагруженных и распределенных систем на языке программирования Go.
  • Жизненный цикл разработки (SDLC) – последовательность этапов, которые проходит программный продукт от концепции до вывода из эксплуатации.
  • CI/CD пайплайн – набор автоматизированных процессов непрерывной интеграции и доставки, обеспечивающих сборку, тестирование и развертывание кода.
  • Код-ревью – процесс проверки исходного кода другими членами команды с целью обнаружения ошибок, улучшения качества и обмена знаниями.
  • Релизный процесс – регламентированная процедура подготовки, утверждения и развертывания новой версии программного продукта в продуктивной среде.
  • BPMN (Business Process Model and Notation) – стандарт графической нотации для моделирования бизнес-процессов.
  • IDEF0 – методология функционального моделирования, используемая для описания и анализа бизнес-процессов.
  • EPC (Event-driven Process Chain) – нотация для моделирования бизнес-процессов, основанная на цепочках событий и функций.
sections

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

contents

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

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

contents

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

Основными ожидаемыми результатами работы являются:

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

3. Подчинение и линии отчетности

contents

3.1. Иерархическая структура подчинения

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

contents

3.2. Матрица ответственности

В рамках матричной структуры управления сотрудник функционально подчиняется Team Lead по техническим вопросам и методологии разработки, а административно – руководителю отдела разработки. Для выполнения задач в рамках проектов сотрудник также может получать указания от Менеджера проекта касательно сроков и приоритетов. Все решения, связанные с изменением архитектуры, релизной стратегией и принципиальными техническими вопросами, согласовываются с системным архитектором.

sections

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

contents

4.1. Разработка и проектирование

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

  • Проектировать и разрабатывать эффективные, масштабируемые и надежные программные компоненты на языке программирования Go, используя лучшие практики жизненного цикла разработки.
  • Разрабатывать и поддерживать микросервисы, RESTful и gRPC API, а также асинхронные обработчики событий.
  • Применять принципы чистой архитектуры и Domain-Driven Design (DDD) для создания легко поддерживаемого и тестируемого кода.
  • Создавать и документировать схемы баз данных, оптимизировать SQL-запросы и работать с различными базами данных (PostgreSQL, Redis, ClickHouse, etc.).
  • Участвовать в оценке трудозатрат (estimates) на реализацию пользовательских историй и задач в рамках спринта.
contents

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

Для обеспечения качества разрабатываемого кода Go-разработчик обязан:

  • Писать модульные тесты с использованием стандартного пакета testing и библиотек, таких как testify, для обеспечения функциональной корректности.
  • Разрабатывать интеграционные тесты для проверки взаимодействия компонентов системы.
  • Участвовать в написании и поддержке API-тестов и сквозных (E2E) тестов.
  • Обеспечивать минимальное покрытие кода тестами на уровне, установленном командой (например, 80% для критичных модулей).
  • Соблюдать требования код-ревью, проверяя код коллег и активно работая над улучшением покрытия тестами.
contents

4.3. Работа с CI/CD и инфраструктурой

Go-разработчик участвует в поддержании и развитии инфраструктуры разработки и развертывания:

  • Настраивать и поддерживать CI/CD пайплайны (например, с использованием GitLab CI, GitHub Actions или Jenkins) для автоматической сборки, тестирования и доставки приложений.
  • Писать и поддерживать Dockerfile и docker-compose файлы для контейнеризации приложений.
  • Взаимодействовать с инженерами DevOps для создания и управления средами разработки, тестирования и продуктивной средой (Kubernetes, облачные провайдеры).
  • Автоматизировать рутинные задачи разработки, используя скрипты и инструменты командной строки для повышения эффективности.
contents

4.4. Код-ревью и наставничество

Активное участие в улучшении качества кода всей команды является критической обязанностью:

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

4.5. Релизный процесс и мониторинг

Участие в релизном процессе и обеспечение стабильности продуктивных систем включает:

  • Следовать утвержденному релизному процессу при подготовке новых версий продукта, включая создание релизных кандидатов и их развертывание на стейджинг-среде.
  • Участвовать в планировании и выполнении релизов, следуя календарному графику и управляя рисками.
  • Внедрять и использовать инструменты мониторинга и логирования (например, Prometheus, Grafana, ELK Stack) для отслеживания состояния приложений и быстрого реагирования на инциденты.
  • Анализировать логи и метрики после релизов для выявления потенциальных проблем и регрессий.
contents

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

Go-разработчик обязан создавать и поддерживать техническую документацию:

  • Документировать разработанные API в формате OpenAPI (Swagger) и другую архитектурную информацию.
  • Создавать и поддерживать в актуальном состоянии сценарии работ и чек-листы этапов для повторяющихся операций.
  • Участвовать в создании и ведении моделей бизнес-процессов в нотациях BPMN или IDEF0, описывающих ключевые рабочие потоки.
  • Предоставлять отчеты по статусу выполнения задач и прогрессу разработки в рамках регулярных мероприятий (ежедневные стендапы, обзоры спринтов).
sections

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

contents

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

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

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

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

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

  • Технической документации, коду и архитектурным схемам системы.
  • Инструментам разработки, тестирования и развертывания.
  • Информации о требованиях к задачам и бизнес-целях.
contents

5.3. Право на запрос ресурсов

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

sections

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

contents

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

Go-разработчик несет ответственность за:

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

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

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

contents

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

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

sections

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

contents

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

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

contents

7.2. Опыт работы и стаж

Требуемый опыт работы в разработке программного обеспечения на языке Go должен составлять не менее 2 лет. Опыт разработки высоконагруженных распределенных систем и работы с микросервисной архитектурой является обязательным. Приветствуется опыт работы в продуктовых компаниях или крупных проектах с использованием CI/CD пайплайнов и облачных технологий.

contents

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

Сотрудник должен обладать следующими профессиональными навыками и знаниями:

  • Глубокое знание языка программирования Go, его модели параллелизма (горутины, каналы) и стандартной библиотеки.
  • Опыт разработки RESTful и gRPC API, включая работу с Protocol Buffers.
  • Опыт работы с реляционными и NoSQL базами данных (PostgreSQL, ClickHouse, Redis).
  • Знание современных подходов к тестированию, включая написание модульных и интеграционных тестов.
  • Опыт работы с системами контроля версий, в частности с Git, и инструментами CI/CD.
  • Знание принципов и практик жизненного цикла разработки, релизного процесса и код-ревью.
contents

7.4. Сертификации

Наличие сертификаций не является строгим требованием, но приветствуется и учитывается при рассмотрении кандидатов. Предпочтительны сертификации в области облачных технологий (например, Certified Kubernetes Administrator (CKA), AWS/Azure/Google Cloud Solutions Architect) или курсы по повышению квалификации в области архитектуры ПО и алгоритмов.

sections

8. Условия труда

contents

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

Режим работы сотрудника определяется Правилами внутреннего трудового распорядка организации и составляет 40 часов в неделю. Для сотрудников допускается гибкий график работы с соблюдением временных рамок для участия в командных мероприятиях (ежедневные стендапы, встречи по планированию, ретроспективы).

contents

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

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

contents

8.3. Командировки и обучение

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

sections

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

contents

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

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

  • Качество кода: Количество критических и мажорных багов, обнаруженных в процессе тестирования и в продуктивной среде, на один спринт.
  • Покрытие тестами: Процент покрытия кода модульными тестами в критически важных модулях (целевое значение ≥ 80%).
  • Время выполнения задач (Cycle Time): Среднее время, затрачиваемое на выполнение пользовательской истории от начала разработки до успешного развертывания на продуктивной среде.
  • Соблюдение сроков: Процент задач, выполненных в соответствии с запланированными сроками и графиком релизов.
  • Соответствие SLA: Время реакции и время восстановления сервиса при возникновении инцидентов.
contents

9.2. Участие в командных процессах

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

  • Активность в код-ревью: Количество проведенных и полученных ревью, качество комментариев.
  • Соблюдение процесса: Следование регламенту релизного процесса, код-ревью и другим установленным процедурам.
  • Обмен знаниями: Проведение презентаций, демонстраций или написание статей по лучшим практикам разработки.
contents

9.3. Профессиональный рост

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

sections

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

contents

10.1. Жизненный цикл разработки (SDLC) в нотации EPC

Жизненный цикл разработки для Go-разработчика описывается в нотации EPC как последовательность событий и функций:

  • Событие 1: Поступила задача (User Story / Task).
  • Функция: Анализ требований и оценка задачи.
  • Событие 2: Задача оценена и готова к разработке.
  • Функция: Создание ветки (feature branch) и разработка.
  • Событие 3: Код готов к локальному тестированию.
  • Функция: Написание и прогон модульных тестов.
  • Событие 4: Все локальные тесты пройдены.
  • Функция: Создание пул-реквеста и инициация код-ревью.
  • Событие 5: Код-ревью пройдено и одобрено.
  • Функция: Слияние (merge) ветки в основную ветку (develop).
  • Событие 6: Изменения интегрированы в основную ветку.
  • Функция: Запуск CI/CD пайплайна (сборка, тестирование, деплой на стейджинг).
  • Событие 7: CI/CD пайплайн выполнен успешно. Релизный кандидат готов.
  • Функция: Утверждение релиза и проведение релизного процесса.
  • Событие 8: Релиз развернут в продуктивной среде. Задача закрыта.
contents

10.2. Модель бизнес-процесса в нотации IDEF0

Бизнес-процесс разработки, тестирования и релиза может быть описан в нотации IDEF0 как функциональный блок "Разработать и поставить ПО" с входами (требования, код), управлениями (стандарты, регламенты), механизмами (средства разработки, знания) и выходами (работающее ПО). Декомпозиция этого процесса включает этапы: Анализ, Проектирование, Кодирование, Тестирование и Деплой, где каждый подпроцесс имеет четкие входы и выходы.

contents

10.3. Модель бизнес-процесса в нотации BPMN

В нотации BPMN процесс разработки представляет собой набор пулов (разработчик, QA-инженер, DevOps) и дорожек. Основной процесс включает пул-реквест, ревью, интеграционные тесты и релиз. В BPMN ключевыми элементами являются события, шлюзы (ветвления/слияния) и задачи, которые детально описывают сценарии успешного завершения и обработку ошибок (например, возврат задачи на доработку, если код-ревью провалено).

contents

10.4. Сценарии работ (Use Cases)

Сценарии работ определяют последовательность действий для выполнения стандартных задач:

  • Сценарий 1: Внедрение нового микросервиса. Включает создание проекта (Go module), проектирование API (gRPC/Protobuf), написание кода и тестов, настройку CI/CD, проведение код-ревью и релиз.
  • Сценарий 2: Исправление критического бага в продуктивной среде. Включает создание хотфикса (hotfix branch), написание теста для воспроизведения бага, исправление, прохождение ускоренного ревью и внеплановый релиз.
  • Сценарий 3: Обновление зависимостей. Включает анализ изменений в сторонних библиотеках, обновление go.mod, прогон всех тестов, обновление кода при необходимости и интеграция в основную ветку.
contents

10.5. Чек-лист перед созданием пул-реквеста

Перед созданием пул-реквеста на код-ревью Go-разработчик обязан проверить:

  • ✅ Все ли модульные и интеграционные тесты были локально запущены и прошли успешно?
  • ✅ Обеспечено ли покрытие кода тестами для новых и измененных функций?
  • ✅ Проведен ли само-ревью кода? Устранены ли явные ошибки, дублирования и "технический долг"?
  • ✅ Проверена ли документация (godoc, комментарии) на предмет актуальности?
  • ✅ Соответствует ли код установленным стандартам и стилю кодирования (gofmt, golint)?
  • ✅ Проверены ли изменения на предмет проблем с безопасностью и производительностью?
  • ✅ Пул-реквест содержит ли понятное описание изменений и ссылку на задачу в системе трекинга?
contents

10.6. Чек-лист этапов релизного процесса

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

  • ✅ Создан ли релизный кандидат (release branch) на основе ветки develop?
  • ✅ Запущен ли полный цикл тестирования (включая нагрузочные тесты) на стейджинг-среде?
  • ✅ Проведена ли проверка и обновление всей необходимой документации (Release Notes)?
  • ✅ Получены ли необходимые согласования от Team Lead, QA и Product Owner?
  • ✅ Процесс развертывания задокументирован и выполнен в строгом соответствии с планом релиза?
  • ✅ После деплоя проведен ли мониторинг ключевых метрик приложения для обнаружения аномалий?
  • ✅ Создан ли тег в репозитории для версии релиза?
contents

10.7. Рекомендации по использованию инструментов

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

  • Использовать GoLand или Visual Studio Code с плагином Go для повышения продуктивности.
  • Применять инструменты статического анализа, такие как golangci-lint, в процессе разработки и на этапе код-ревью.
  • Использовать Docker и docker-compose для локализации окружения разработки и тестирования.
  • Активно использовать возможности CI/CD пайплайна для автоматизации рутинных задач, таких как проверка форматирования, тестирование и сборка артефактов.
  • Интегрировать Prometheus для сбора метрик и Grafana для визуализации для мониторинга состояния сервисов в продуктивной среде.