Как создать учебную CRM для портфолио

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

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

В первой версии достаточно двух ролей: администратор и менеджер. Администратор управляет сотрудниками, воронкой и общими настройками. Менеджер видит назначенных ему клиентов и сделки, создаёт задачи, добавляет комментарии и меняет этап продажи. Проверка роли должна выполняться на сервере, а не только скрывать кнопки в интерфейсе.

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

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

Интерфейс можно разделить на обзорную панель, список клиентов, канбан-доску сделок, задачи, карточку клиента и раздел администрирования. Карточка клиента должна объединять контакты, сделки, комментарии и хронологию действий. Пользователь не должен переходить между множеством экранов, чтобы понять текущее состояние работы.

Для учебной архитектуры подойдёт модульный монолит. Клиентское приложение отвечает за интерфейс, сервер — за бизнес-логику и контроль доступа, PostgreSQL — за постоянные данные, а файловое хранилище — за документы. Отдельные микросервисы на этом этапе только усложнят проект и не дадут дополнительной пользы для портфолио.

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

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

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

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

Проект необходимо покрыть тестами. Модульные тесты проверяют расчёты и правила переходов, интеграционные — API и базу данных, а end-to-end тест проходит основной путь от создания заявки до успешного закрытия сделки. Отдельно нужно проверить попытки менеджера открыть чужие данные или выполнить действие администратора.

Финальная версия должна запускаться через Docker, иметь автоматическую проверку кода, миграции базы, демонстрационные данные и публичную тестовую среду. В репозитории нужны понятное описание задачи, схема архитектуры, инструкция запуска, документация API, тестовые учётные записи и изображения ключевых сценариев.

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