Конспект

Как отвечать на вопросы о проекте (CRM для школы английского)

Ключевые тезисы

• Конспект — это гайд по ответам на вопросы о работе в проекте (компания, процессы, технологии).
• Основной пример — разработка внутренней CRM-системы для школы английского языка.
• CRM (Customer Relationship Management) — это система для управления всеми отношениями с клиентами (учениками, учителями, операторами).
• Ответы должны быть правдоподобными, но не обязательно детальными. Можно использовать общие формулировки («корпоративный булшит»).
• Важно говорить только о том, в чём уверен, чтобы не «закопаться» на дополнительных вопросах.

Основное содержание

Что такое CRM в контексте школы

CRM-система — это «сердце» компании, которое объединяет все разрозненные сервисы (сайт, личный кабинет, портал учителей, лендинги) в единую экосистему. Она автоматизирует бизнес-процессы:

• Управление учениками и преподавателями.
• Назначение скидок, отслеживание посещений.
• Отправка уведомлений.
• Логирование всей истории взаимодействия с клиентом.

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

Вопросы о компании и культуре

• Миссия: Предоставление качественного и доступного обучения английскому с использованием современных технологий и индивидуального подхода.
• Услуги: Обучение для разных уровней, подготовка к экзаменам, индивидуальные и групповые занятия.
• Структура команды разработки: Пример: 2 фронтенд-разработчика, 2 бэкенд-разработчика, 1 QA, проджект-менеджер, тимлид.
• Развитие сотрудников: Внутренние митапы (например, еженедельные для фронтенда), бюджет на обучение, индивидуальные планы развития (например, «улучшить знания в React Query»).
• Ценности: Ориентированность на результат, постоянное развитие, работа в команде, инициативность.
• Мотивация: Бонусы по итогам года, опросы 360°, обещание повышения.
• Оценка успехов: Успешное выполнение спринтов, качество код-ревью, предложение улучшений в команде.
• Технологический стек: На фронтенде — React/Next.js, на бэкенде — Node.js/Express или PHP. Также: Docker, GitHub Actions, TypeScript.

Вопросы о процессах и интеграциях

• Код-ревью: Проводилось на каждую задачу. Требовалось 1-2 апрува. Сложные задачи обсуждались всей командой.
• CI/CD: Использовались GitHub Actions. Деплой на прод выполнял тимлид после демо и одобрения заказчиком (часто ночью).
• Тестирование: В основном ручное тестирование QA по тест-кейсам. Автотесты могли быть на бэкенде, но не на фронтенде.
• Работа с багами: Существовал отдельный канал в Slack для инцидентов. Дежурный разработчик (ротация раз в неделю) разбирался и привлекал нужных специалистов.
• Кроссбраузерность: Не была критичным требованием, так как продукт внутренний. Поддерживались последние версии основных браузеров.
• Feature flags: Использовались, чтобы скрыть незаконченный функционал до следующего релиза.
• Взаимодействие с тестировщиками: Через задачи в Jira (статус «In Testing»). При необходимости — созвоны для уточнения.
• Взаимодействие с менеджерами: Продакт-менеджер собирал требования от отделов (продаж, поддержки), формировал проекты. Проджект-менеджер и тимлид декомпозировали их на задачи для команды.
• Взаимодействие с бэкендом: Согласование API на этапе планирования. Фронтенд работал с mock-данными, пока бэкенд реализовывал фичу.
• Работа с дизайнерами: Был общий дизайнер/дизайн-система (например, Material-UI). Макеты предоставлялись в Figma.
• Решение технических конфликтов: Обсуждались на командных митапах. Часто решение принимал более опытный разработчик.

Управление проектами и задачи

• Планирование: Квартальное или ежемесячное — на уровне проектов. Двухнедельные спринты — на уровне задач.
• Оценка задач: В стори-поинтах по последовательности Фибоначчи (1, 3, 5, 8, 13). Оценка проводилась командой на грейминге.
• Распределение задач: Более сложные задачи брал senior-разработчик, более простые — middle. Помощь и обсуждение приветствовались.
• Нехватка времени/ресурсов: Главная стратегия — гибко резать функционал (флексить), чтобы выкатить самое важное в срок. Реже — продление сроков.
• Технический долг: На него выделялось ~10% времени спринта. Задачи приоритизировались по важности и влиянию.
• Ретроспективы: Проводились после каждого спринта для обсуждения проблем и улучшения процессов.

Вопросы о технологиях и архитектуре

• Архитектурные решения: Часто говорят, что пришли на готовый проект, поэтому ключевые решения (модульная архитектура, BFF) были приняты до них.
• Масштабируемость: Достигалась за счёт модульности и постраничной загрузки данных (пагинации).
• Управление состоянием: Использовались стандартные для стека инструменты (React Context, Redux, React Query и т.д.).
• Оптимизация производительности: Использование React.memo, useCallback, ленивая загрузка компонентов, оптимизация рендеринга тяжелых списков.
• Типичные задачи фронтенда: Разработка и расширение карточки ученика, страницы списка пользователей, лента действий оператора, различные формы и фильтры.

Рабочий процесс и продуктивность

• Распорядок дня: Гибкое начало, но daily-митинг в 10:00. Спринты длительностью 2 недели. Регулярные демо, ретро и планировочные митинги.
• Удалённая работа: Полностью удалённый формат. Главное — быть на связи в рабочие часы и присутствовать на ключевых встречах.
• Приоритизация: Фокус на самых важных задачах в начале спринта. Избегание многозадачности.
• Обучение: За счёт личного времени (чтение Хабра, документации). Компания могла предоставлять бюджет на курсы.

Выводы

Для успешных ответов о проекте важно:

1. Построить правдоподобную легенду (продукт, компания, ваша роль).
2. Понимать общие принципы современных процессов разработки (Agile, CI/CD, код-ревью).
3. Говорить конкретно о своём стеке и зоне ответственности (фронтенд).
4. Использовать общие формулировки для вопросов о культуре и ценностях.
5. Не бояться говорить «я не участвовал в этом» или «это решалось на уровне архитектора/тимлида», если это соответствует действительности в вашей легенде.