Разработка сервиса для проработки клиентских запросов

Как возникла задача

Компания предоставляет ИТ-услуги, а также разрабатывает и регулярно обновляет собственные инструменты. Последние два года бизнес активно развивается: растёт штат специалистов, увеличивается поток клиентов и вместе с ним — сложность и объём проектов.

Раньше все проработки велись в Google Документах. По мере роста компании такой подход перестал справляться с увеличившимся объёмом задач: ручные операции занимали всё больше времени, а накопленный опыт было сложно использовать повторно.

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

Много времени занимала и подготовка коммерческих предложений. Менеджерам требовалось много времени на формирование проработок, из-за чего коммерческие предложения иногда отправлялись с задержкой. В результате возрастал риск, что потенциального клиента успеет привлечь компания-конкурент.

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

Если раньше работы в Google Документах было достаточно для небольших клиентских запросов, то с ростом бизнеса компании потребовался более гибкий инструмент, который позволил бы стандартизировать работу, ускорить подготовку проектов и сохранить экспертизу внутри компании.

Единый сервис для проработки клиентских запросов

• основной микросервис — реализует ключевой функционал сервиса, с которым непосредственно взаимодействует пользовательский интерфейс;

• сервис авторизации — обеспечивает кэширование необходимых для авторизации данных из Redmine;

• сервис статистики — собирает и обрабатывает данные о работе над проектами.
  

Такое разделение сделало разработку более организованной: каждая команда может отвечать за конкретный функциональный блок и развивать его независимо. Это особенно важно для компании, которая активно растёт и регулярно расширяет собственные продукты.

Кроме того, разработчики стали работать с меньшим объёмом кода. Процесс создания новых функций ускорился в среднем на 15–20%.

Часть микросервисов имеет проработанный программный интерфейс приложения (API), через который осуществляется взаимодействие между элементами системы.

Для расширения функциональности сервиса, добавления новых полей к проектным задачам и хранения статистики работы инженеров использовали СУБД MongoDB.

По сравнению с привычными реляционными базами данных выбор нереляционной БД позволил увеличить скорость разработки новых функций, требующих структурных изменений в сервисе и взаимодействия с базой данных, в среднем на 30%.

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

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

В результате время составления проработки проекта сократилось с 2 часов до 10 минут.

Это позволяет менеджерам быстрее готовить коммерческие предложения и сокращает время от получения запроса до предложения клиенту — что особенно важно в условиях высокой конкуренции за потенциальных заказчиков.

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

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

Для визуализации статистики использовали Grafana. Для промежуточного хранения данных из Redmine — Redis. Все компоненты решения развёрнуты в Kubernetes облачного провайдера.

Уже на начальном этапе проекта мы внедрили процессы непрерывной интеграции и доставки (CI/CD). Они обеспечивают автоматическую сборку, тестирование и доставку всех компонентов проекта в производственную среду.

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

CI/CD также позволил значительно сократить время, необходимое разработчику для каждого релиза: с примерно 10 минут до одной минуты.

При частоте 2–3 релиза в день инженер теперь экономит до 30 рабочих минут ежедневно. Для бизнеса это означает меньше операционных затрат на рутинные процессы и больше времени команды на разработку новых функций.

Что изменилось после внедрения

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

Время подготовки проработки сократилось с 2 часов до 10 минут, новые функции создаются в среднем на 15–20% быстрее, а время одного релиза уменьшилось с 10 до 1 минуты.

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

Реализация продукта заняла 1,5 календарных месяца с учётом всех согласований, тестирования и приёмки.

Бюджет проекта составил:

• работа с пользовательским интерфейсом — 120 000 р;

• разработка серверной части — 460 000 р.