Павел Шерер

JTBD → Job Story → Иерархия целей → 
Opportunity Landscape → Personas → 
Механика → User Story → Проверка результата

# Руководитель разработки/техлид

Ищем руководителя разработки/техлида в проект в сфере API программ лояльности.

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

Оплата - от 300.000 рублей в месяц.

## Чем предстоит заниматься

Проектировать и развивать архитектуру backend, API, интеграций, фронтов (админок), инфраструктурного контура и модели данных. В том числе включиться в развитие архитектуры БД и её производительности.

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

Нужно (хотя не факт, что придётся) писать код: роль предполагает техническое лидерство плюс hands-on при необходимости. Объем работы и задач большой, надо любить кодить и любить красивый код.

Так же нужно управлять devops-контуром продукта: Kubernetes, CI/CD, наблюдаемость, IAM, окружения. Требуется соответствующий опыт и компетенции.

## Что требуется

Уровень - senior/lead.

Опыт коммерческого проектирования веб-ПО, backend-архитектуры, API (OpenAPI и т.п.); практический опыт с Node.js и React (сейчас стек на них). Опыт с другими языками и фреймворками будет большим плюсом.

Уверенный опыт с SQL и Postgres, особенно в части производительности.

Опыт работы с Redis, Kafka или RabbitMQ, микросервисами и кешами. Большим плюсом будет опыт с Supabase.

Практический опыт и devops-практика на уровне понимания flux, CI/CD и k8s и умения их готовить.

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

## Формат работы

Полный рабочий день, ГПХ.

Полностью удалённая работа, география - вся Россия.

График гибкий, основная коммуникация и рабочие процессы ведутся преимущественно в часовом поясе Москвы.

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

## Как проходит отбор

Техническое интервью и тестовое задание.

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

Писать @xFFFFFE

Внимательно проанализируй содержимое репозитория на предмет:
- Наличия потенциальных уязвимостей и слабых мест в безопасности.
- Качества общей архитектуры и программных решений.
- Согласованности функций, компонентов, модулей, методов API и прочего.
- Наличия избыточной и дублирующей функциональности и логики, методов API и прочего.
- Идемпотентность операций (API, БД, кэш и прочее).
- Оптимизации и быстродействия.
- Cоответствие файлов окружения `.env.*`.

- Полноты и качества документирования проекта, соответствия документации текущей версии кода.
- Соответствия файлов ARCHITECTURE.md, README.md и AGENTS.md коду и архитектуре.
- Консистентности документации проекта, наличия дубликатов в файлах документации.

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

Внимательно изучи все страницы и объекты сайта с точки зрения UX и UI:
- Главная страница
- ...
- 404 страница
- Остальные страницы и разделы

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

После оценки составь план (в том числе, исходя из реальных интерфейсов в браузере), исправления всех недостатков, которые найдёшь. Задай все необходимые вопросы перед тем, как составлять финальный план.

# Задача

Создай (или обнови, если уже существует) файл `docs/ARCHITECTURE.md`.

# Вводные

`ARCHITECTURE.md` — это живой архитектурный документ, описывающий текущее фактическое состояние системы. Это не vision-документ и не roadmap. Он фиксирует реальную архитектуру, отражённую в коде и инфраструктуре.

# Требования к содержанию `ARCHITECTURE.md`

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

1. System Overview
– назначение системы
– ключевая бизнес-цель
– границы системы (что входит и что явно не входит)
– основные внешние акторы и интеграции

2. Architectural Context
– тип архитектуры (монолит, модульный монолит, микросервисы и т.д.)
– среда исполнения (runtime, инфраструктура, deployment-модель)
– основные технологические стеки

3. Subsystems and Responsibilities
Для каждой подсистемы:
– название
– ответственность
– публичные интерфейсы
– зависимости
– что она не должна делать

4. Interactions
– логическая схема взаимодействия подсистем
– направление зависимостей
– синхронные / асинхронные взаимодействия
– точки интеграции с внешними системами

Описание должно быть логическим и архитектурным, без BPMN и без избыточной детализации бизнес-процессов.

5. Data Architecture
– основные доменные сущности
– границы владения данными
– источники истины
– политика кэширования (если есть)

6. Key Technical Decisions
– принятые архитектурные решения
– их причины
– зафиксированные компромиссы
– допущения

7. Constraints
– технические ограничения
– инфраструктурные ограничения
– нормативные или внешние ограничения

8. Extension Points
– предусмотренные точки расширения
– места, где допустимо добавлять новые модули
– зоны, требующие осторожности

9. Architectural Invariants
Перечень принципов, которые запрещено нарушать.
Это должны быть чёткие, проверяемые правила.


# Правила описания

– Документ описывает текущее состояние кода, а не желаемое будущее.
– Если что-то не реализовано — не описывать это как существующее.
– Не использовать расплывчатые формулировки («гибкая», «масштабируемая» без пояснения).
– Не дублировать README.
– Не описывать бизнес-функциональность вне архитектурного контекста.
– Не фантазировать о механиках, которых нет в коде.

# Консистентность

Перед созданием/обновлением документа:
– проанализируй текущую структуру репозитория
– определи реальные модули и зависимости
– зафиксируй их как есть

Документ должен быть согласован с кодовой базой.

# Обновление AGENTS.md

Обнови файл `AGENTS.md`, добавив:

1. Правило, что `docs/ARCHITECTURE.md` является единственным источником истины по архитектуре системы.

2. Обязанность агента:
– при любом изменении, затрагивающем архитектуру (структура модулей, зависимости, интеграции, инфраструктура, доменные границы), обновлять `ARCHITECTURE.md` в том же коммите.

3. Запрет на архитектурные изменения без обновления документа.

4. Если архитектурное изменение невозможно корректно отразить в `ARCHITECTURE.md`, агент обязан:
– явно указать это в комментарии к изменению
– объяснить причину
– предложить способ корректного отражения

# Запрет дублирования

– Архитектурные описания запрещено дублировать в других документах.
– Все архитектурные разделы в других файлах должны ссылаться на `docs/ARCHITECTURE.md`.

# Дополнительно

Если файл уже существует:
– не переписывать его полностью без причины
– сохранить структуру, если она логична
– обновлять только несоответствующие или устаревшие разделы

# Результат

После выполнения:
– `docs/ARCHITECTURE.md` отражает реальную архитектуру
– `AGENTS.md` закрепляет дисциплину поддержки архитектурной документации