Конспект

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

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

• Конспект служит шаблоном для ответов на вопросы о проекте, команде и процессах.
• Рассматривается пример: внутренняя CRM-система для школы английского языка.
• CRM — это система управления взаимоотношениями с клиентами, центральный элемент, объединяющий все бизнес-процессы компании.
• Ответы должны быть правдоподобными, основанными на стандартных практиках, но адаптированными под ваш опыт.

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

Контекст проекта: CRM для EdTech

• Продукт: Внутренняя CRM-система.
• Компания: Школа английского языка (EdTech).
• Назначение CRM: Управление учениками и преподавателями: звонки, назначение скидок, отслеживание посещений, автоматизация коммуникации.
• Роль в компании: CRM выступает "сердцем" компании, объединяя разрозненные сервисы (лендинги, личный кабинет, портал учителей, платежи) в единую экосистему. Без неё отделы работают неэффективно (через Excel, файлы).

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

• Миссия: Предоставление качественного и доступного обучения английскому с использованием современных технологий и индивидуального подхода.
• Услуги: Обучение английскому для разных уровней и возрастов, подготовка к экзаменам, индивидуальные и групповые занятия.
• Команда разработки: Пример: 2 фронтенд-разработчика, 2 бэкенд-разработчика, 1 QA, тимлид, продакт-менеджер. Отдельно — архитекторы и бизнес-аналитики.
• Развитие сотрудников: Внутренние митапы (например, еженедельные/раз в две недели для фронтенда), обсуждение технологий, бюджет на обучение, индивидуальные планы развития (IDP) с тимлидом.
• Ценности: Ориентированность на результат, постоянное развитие, командная работа, поощрение инициативы.
• Мотивация: Бонусы по итогам года, опросы 360°, обещание повышения.
• Оценка успехов: Успешное выполнение спринтов, качество код-ревью, предложение улучшений в команде.
• Технологический стек:
  • Фронтенд: React (или Next.js), React Router, TypeScript.
  • Бэкенд: Node.js + Express (или PHP), PostgreSQL/MySQL.
  • Инфраструктура: Docker, GitHub (Actions для CI/CD), Jira, Slack.
• Управление временем: Двухнедельные спринты, планирование с командой, ежедневные стендапы.

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

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

Документирование и управление требованиями

• Техническая документация: Как таковой отдельной техдокументации не было. Её роль выполнял код и описание бизнес-процессов в BPM-системе. Для общих знаний использовался Confluence.
• Требования (ТЗ): Бизнес-аналитик на основе эпиков от продакта писал описание задач прямо в Jira. Это и было основным ТЗ, которое уточнялось в процессе.
• Сбор требований: Продакт-менеджер собирал "хотелки" от других отделов компании, приоритизировал их и передавал команде на оценку.
• Документирование API: Описание endpoint'ов согласовывалось и фиксировалось в задачах. Мог использоваться OpenAPI/Swagger.
• Роль фронтенда в требованиях: Не участвовал напрямую в сборе пользовательских историй или проектировании БД. Работал с готовыми ТЗ от аналитиков.

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

• Появление проектов: Запросы от других отделов (продажи, поддержка) → обсуждение с продактом → оценка командой (тимлид, проект-менеджер, бизнес-аналитик) → взятие в работу.
• Планирование спринтов: Двухнедельные спринты. На планировании команда вместе с проект-менеджером выбирала задачи из бэклога на ~15-20 story points на фронтенд.
• Оценка задач: Story points (числа Фибоначчи: 1, 3, 5, 8...). Оценка проводилась на отдельной встрече (grooming) тех. специалистами.
• Распределение задач: Внутри фронтенд-пары задачи распределялись по сложности и опыту. Сеньор брал сложные, миддл — более простые, но мог просить сложные для роста.
• Нехватка времени/ресурсов: Основная тактика — гибкое сокращение (flex) функционала в первой версии с последующим докручиванием. Редко — работа в выходные.
• Технический долг: На него выделялось ~10% времени спринта. Задачи по техдолгу создавались в Jira и приоритизировались.
• Оценка рисков: Тимлид и проект-менеджер оценивали загрузку и сроки, при рисках сдвигали сроки или шли на переговоры с продактом об уменьшении объема.

Взаимодействие с пользователями

• Прямой контакт: Команда разработки напрямую с конечными пользователями (операторами CRM) не взаимодействовала.
• Обратная связь: Собиралась продакт-менеджером и бизнес-аналитиками через отделы-заказчики.
• Демо-презентации: Проводились в конце спринта для продакт-менеджера (заказчика), иногда силами разработчиков.
• Срочные запросы: Обрабатывались через процесс с дежурным разработчиком и Slack-каналом инцидентов.

Технические детали и архитектура

• Архитектурные решения: Модульная архитектура на фронтенде. Часто использовался Next.js в роли BFF (Backend For Frontend). Решения принимались до прихода в проект или сеньор-разработчиком.
• Масштабируемость: Достигалась за счет модульности, пагинации списков, lazy loading.
• Управление состоянием: Использовались React Context, Zustand, React Query (или аналоги) в зависимости от знаний.
• Оптимизация: Использование React.memo, useCallback, useMemo, код-сплиттинг, оптимизация рендеринга тяжелых списков (виртуализация).
• Типовые задачи: Разработка и расширение карточки ученика (добавление полей, аватарки), работа со списками (фильтры, пагинация), лог действий оператора.
• Интеграция: Все взаимодействие с внешними системами шло через единый бэкенд CRM. Фронтенд общался только с его API (REST, HTTP).

Внедрение новых технологий

• Процесс принятия решений: Инициатива исходила от разработчиков (чаще сеньоров), обсуждалась на митапах фронтенд-гильдии. Оценивались плюсы/минусы.
• Адаптация: На обновление библиотек и инструментов выделялось специальное время.
• Эксперименты: Новые технологии могли опробоваться на изолированном модуле перед широким внедрением.
• Обмен знаниями: Через митапы гильдии, внутренние чаты, обсуждение на ретро.

Тестирование и качество кода

• Участие фронтенда в тестировании: Писал unit-тесты (Jest, React Testing Library) если были в проекте. В основном полагались на ручное тестирование QA.
• Решение багов: Баги, найденные QA, документировались в задаче. Разработчик воспроизводил, фиксил и отдавал на повторное тестирование.
• Код-ревью: Критерии — решение задачи, соответствие код-стайлу, отсутствие грубых логических ошибок, поддерживаемость кода. Ревью проводили внутри пары фронтенд-разработчиков.

Продуктивность и организация работы

• Рабочий день: Гибкий график с обязательным стендапом в 10:00. Удалённая работа.
• Методология: Agile/Scrum (двухнедельные спринты, ретро, демо, планирование).
• Инструменты: Jira для задач, Slack для коммуникации, GitHub для кода.
• Баланс и перегрузки: Компания формально не поощряла работу в выходные. Чтобы избежать перегрузок, задачи гибко сокращались (flex), а не наращивались сроки.
• Приоритизация: Делали самое важное и срочное в первую очередь, не переключаясь на другие задачи параллельно.
• Обучение: За счёт личного времени (чтение Хабра, документации, пет-проекты).

Выводы

• Для успешных ответов важно построить непротиворечивую легенду проекта, основанную на реальном опыте и стандартных практиках разработки.
• Ключевые моменты: понимание роли CRM как центральной системы, описание рабочих процессов (спринты, код-ревью, планирование), знание своего Tech Stack.
• На вопросы о культуре и процессах можно давать общие, но правдоподобные ответы ("корпоративный булшит").
• Где не знаете деталей — честно говорите, что это была зона ответственности другой роли (тимлида, бэкендера, продакта).