Frontend разработчик
Назад

Пример регламента · Frontend разработчик

Регламент работы Frontend-разработчика

Стандарт клиентской разработки организации: интерфейсы, состояния, доступность, производительность, интеграция с API и стабильность пользовательских сценариев.

Паспорт регламента

Код
EXAMPLE-REG-FRONTEND
Версия
2.0
Статус
Пример регламента для адаптации
Владелец
Frontend Lead
Утверждает
Уполномоченное лицо организации после внутреннего согласования
Юрисдикция
Республика Беларусь
Пересмотр
Не реже одного раза в год, а также после существенного изменения законодательства, процессов или технологий
Актуализирован
5 августа 2026 года

Цель регламента

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

Применение в Республике Беларусь

  • Работа выполняется в пределах трудовой функции, полномочий, локальных правовых актов и договоренностей конкретной организации. Обязательства перед клиентом принимает только уполномоченное лицо.
  • При обработке персональных данных применяются принципы Закона Республики Беларусь от 7 мая 2021 г. № 99-З: законная цель и основание, соразмерность состава данных, ограничение срока хранения, прозрачность и защита прав субъекта.
  • До привлечения внешнего сервиса или подрядчика определяется роль организации и контрагента как оператора либо уполномоченного лица, перечень данных, операции, меры защиты, возврат и удаление данных.
  • Трансграничная передача персональных данных и использование зарубежных SaaS согласуются с ответственным за внутренний контроль обработки персональных данных до загрузки реальных данных.
  • Юридически значимые решения, согласования и документы оформляются в форме, предусмотренной договором и законодательством. Сообщение в чате или отметка в трекере не приравниваются автоматически к электронному документу с ЭЦП.
  • Коммерческая тайна, сведения клиента, исходный код, учетные данные и внутренние документы передаются только лицам с рабочей необходимостью через одобренные компанией системы.
  • При дистанционной или комбинированной работе соблюдаются условия трудового договора, локальный порядок взаимодействия, режим рабочего времени и требования по безопасному использованию предоставленного оборудования.
  • Формы сбора персональных данных показывают понятную цель, обязательность полей и необходимую информацию субъекту до отправки; согласие не смешивается с другими подтверждениями, когда оно является основанием обработки.
  • Пользовательские сообщения, цены, условия и рекламные элементы не должны вводить в заблуждение или скрывать существенные условия действия.

Что проверить до начала работы

  • Названы заказчик результата, владелец решения, исполнители, согласующие лица и канал эскалации.
  • Зафиксированы цель, ожидаемый результат, границы задачи, срок, приоритет, зависимости и критерии приемки.
  • Определена классификация информации: публичная, внутренняя, конфиденциальная, коммерческая тайна или персональные данные.
  • Подтверждено, что специалист имеет необходимые доступы и полномочия, а лишние права не выдаются.
  • Понятно, где хранится актуальная версия результата и какие записи подтверждают выполненную работу.
  • Есть утвержденные тексты уведомлений, согласий, ошибок и обязательных сведений; разработчик не формулирует юридические тексты самостоятельно.
  • Определены требования к cookies/local storage, сторонним виджетам, аналитике, CAPTCHA, картам, видео и иным внешним ресурсам.

Зона ответственности

  • UI-компоненты, страницы, состояния, маршрутизация, формы, интеграция с API, адаптивность, доступность, производительность и сборка.
  • Frontend отвечает за пользовательский сценарий целиком: loading, empty, error, success, validation и edge cases.

Обязанности специалиста

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

Рабочий порядок

  1. Разобрать задачу: сценарий пользователя, макеты, API, права, состояния, ограничения устройств.
  2. Согласовать спорные состояния: пустой список, ошибка, загрузка, длинный текст, медленная сеть.
  3. Реализовать интерфейс на существующих компонентах и стилевых правилах проекта.
  4. Проверить адаптивность, интерактивность, формы, фокус, ошибки и интеграцию с API.
  5. Собрать production build и устранить визуальные/консольные ошибки.
  6. Передать QA список проверенных сценариев и известных ограничений.

Контрольные вопросы специалиста

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

  1. Какие данные запрашивает форма и действительно ли каждое поле необходимо?
  2. Понимает ли пользователь цель, обязательность, последствия и способ отозвать согласие, если оно используется?
  3. Не загружается ли внешний скрипт или cookie до необходимого выбора пользователя?
  4. Не попадают ли данные формы в URL, referrer, client logs, аналитику или сторонний SDK?
  5. Защищены ли маршруты и состояния от отображения данных другого пользователя?
  6. Проработаны ли loading, empty, error, offline, expired и permission denied без раскрытия лишних сведений?
  7. Доступен ли сценарий с клавиатуры, screen reader и при масштабировании?
  8. Не вводят ли интерфейс, цена, акция или default choice пользователя в заблуждение?
  9. Как очистить клиентский кеш и локальное хранилище при logout или удалении аккаунта?

Персональные данные и безопасность

  • Использовать корпоративные учетные записи, MFA, менеджер секретов и принцип минимально необходимых прав; не передавать пароли в чатах, документах и задачах.
  • Не копировать рабочие материалы в личную почту, личные облака, публичные AI-сервисы или неутвержденные инструменты без письменного разрешения владельца информации.
  • Не использовать реальные персональные данные в разработке, тестировании, демонстрациях и обучении, если цель может быть достигнута синтетическими или обезличенными данными.
  • В логах, снимках экрана, отчетах и bug report скрывать токены, пароли, номера документов, платежные данные и иные избыточные идентификаторы.
  • При ошибочной отправке, утрате доступа, подозрении на утечку или несанкционированную обработку немедленно прекратить распространение и уведомить руководителя и ответственного за персональные данные; внешние уведомления выполняют уполномоченные лица в установленные сроки.
  • Доступы пересматриваются при смене роли, завершении проекта и увольнении; данные и носители возвращаются или удаляются по подтвержденной процедуре.
  • Не хранить access token и чувствительные данные в доступном JavaScript хранилище без архитектурного обоснования; исключить секреты из frontend bundle.
  • Настроить CSP и ограничения внешних ресурсов там, где это предусмотрено архитектурой; проверять supply-chain риск зависимостей.

Обязательные артефакты

  • Компонент или страница в коде.
  • Список состояний интерфейса.
  • Скриншоты desktop/mobile при необходимости.
  • Описание API-зависимостей.
  • UI acceptance checklist.
  • Краткие release notes для пользовательских изменений.

Критерии качества

  • Интерфейс не считается готовым без проверки mobile, desktop, длинного контента и ошибок API.
  • Нельзя оставлять кликабельные элементы без понятного состояния hover/focus/disabled/loading.
  • Нельзя ломать существующие компоненты ради частной страницы без согласования изменения паттерна.

Контрольные точки

  • До разработки понятны пользовательский сценарий, состояния интерфейса, реальные данные, права доступа и API-контракт.
  • Перед merge проверены desktop/mobile, длинный контент, пустые состояния, ошибки API, фокус, клавиатура и disabled/loading состояния.
  • Перед релизом собран production build, проверены console errors, bundle size, Core Web Vitals и критичные маршруты.
  • После релиза проверены ошибки JS, пользовательский сценарий, аналитические события и визуальные регрессии.

Антипаттерны

  • Верстать только идеальный макет без реальных данных, ошибок, загрузки и пустых состояний.
  • Добавлять новую библиотеку без оценки веса, поддержки и влияния на bundle.
  • Скрывать проблемы адаптива горизонтальной прокруткой или случайным уменьшением текста.
  • Делать интерактивные элементы без понятного focus, hover, active, disabled и loading поведения.

Рабочий ритм и периодический контроль

  • По рабочим дням: обновить статус задач, зафиксировать блокеры и решения, требующие участия других ролей.
  • Еженедельно: сверить приоритеты, риски, качество артефактов, просрочки и необходимость эскалации.
  • Перед релизом или передачей результата: провести проверку по критериям приемки, безопасности, персональным данным и эксплуатационным рискам.
  • После релиза: проверить фактический результат и зарегистрировать дефекты, отклонения, уроки и последующие действия.
  • Ежеквартально: пересмотреть доступы, устаревшие документы, ручные операции, технический долг и соответствие регламенту.
  • На UI review проверять реальные тексты и данные, consent/privacy states, accessibility, mobile и работу при отказе внешних сервисов.

Метрики контроля

Core Web VitalsОшибки JSBundle sizeВремя загрузки сценарияДефекты UI после релизаДоступность ключевых сценариев

Коммуникации и эскалация

  • Неясности в макете или API фиксируются до реализации, а не маскируются временными решениями.
  • Frontend заранее сообщает backend и QA о контрактных изменениях и новых состояниях.
  • Перед релизом разработчик передает QA короткий список затронутых экранов и сценариев.

Матрица обязательной эскалации

  • Немедленно: утечка или подозрение на утечку данных, компрометация учетной записи, критическая уязвимость, недоступность ключевого сервиса или риск необратимой потери данных.
  • В течение рабочего дня: нарушение договорного срока, блокирующее противоречие требований, несанкционированное изменение production, юридический или репутационный риск.
  • До продолжения работы: отсутствует владелец решения, правовое основание обработки данных, согласованный критерий приемки либо полномочие на действие.
  • Эскалация содержит факты, влияние, затронутые системы и данные, уже выполненные безопасные действия, варианты решения и время следующего обновления.
  • Немедленно сообщать о данных в URL/логах, обходе frontend-ограничений, раскрытии чужих данных, загрузке неутвержденного трекера или вводящем в заблуждение интерфейсе.

Когда работа считается завершенной

  • Результат проверен по всем критериям приемки, а непроверенные области и остаточные риски перечислены явно.
  • Артефакты, решения, версии, ссылки и доказательства проверки сохранены в согласованном корпоративном источнике.
  • Заинтересованные роли уведомлены об изменении, ограничениях, действиях после релиза и владельце дальнейшего сопровождения.
  • Временные доступы, файлы, тестовые данные, feature flags и обходные решения удалены либо имеют владельца и срок закрытия.
  • Результат принят владельцем решения или имеется письменное решение о принятии остаточного риска уполномоченным лицом.
  • Готовность подтверждается production build, тестом целевых браузеров и экранов, accessibility-проверкой, отсутствием секретов и console errors, а также post-release smoke test.

Документирование и хранение записей

  • Рабочие решения и согласования фиксируются в трекере, базе знаний, репозитории или системе электронного документооборота, принятой в компании.
  • Срок хранения определяется номенклатурой дел, договором, целью обработки и требованиями законодательства; персональные данные не хранятся “на всякий случай”.
  • Удаление или архивирование должно быть контролируемым: сохраняются необходимые версии, авторство, дата решения и связь с проектом или релизом.
  • Экспорт данных и локальные копии допускаются только на срок рабочей необходимости и удаляются после подтвержденной загрузки результата в корпоративную систему.
  • Хранить UI specification, матрицу состояний, реестр внешних скриптов, результаты accessibility/design QA и changelog компонентов.

Нормативная основа и официальные материалы

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