Система проработки проектов

О клиенте

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

Проблемы клиента

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

Основные проблемы были следующими:

1. 
   
2. 1. Много ручной работы. Из-за отсутствия стандартизации и готовых шаблонов команде приходилось вручную создавать задачи и заполнять данные по проектам. Это увеличивало трудозатраты и создавало риск ошибок.
   
3. 
   
4. 2. Медленная подготовка коммерческих предложений. Менеджерам требовалось много времени на формирование проработок, из-за чего коммерческие предложения иногда отправлялись с задержкой. В результате возрастал риск, что потенциального клиента успеет привлечь компания-конкурент.
5. 
   
6. 3. Потеря накопленной экспертизы. Результаты предыдущих проработок не систематизировались в единой базе. ИТ-отделу было сложно сохранять детальную информацию о технологиях, этапах и трудозатратах по выполненным проектам. Вместо использования готового опыта инженерам приходилось заново разбираться с похожими задачами.
7. 
   
8. Если раньше работы в Google Документах было достаточно для небольших клиентских запросов, то с ростом бизнеса компании потребовался более гибкий инструмент, который позволил бы стандартизировать работу, ускорить подготовку проектов и сохранить экспертизу внутри компании.

Задачи проекта

Разработать единый сервис с простым веб-интерфейсом для проработки клиентских запросов любой сложности.

Система должна была позволить:

• Получать запрос от клиента на настройку инфраструктуры.

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

• Выгружать подготовленные проектные решения в Google Таблицы.
  

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

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

Требования к системе

• веб-интерфейс с авторизацией;

• авторизация на основе учётных данных в Redmine;

• разделение прав доступа на основе ролевой модели;

• создание и ведение внутри сервиса проектов, разделённых на этапы и задачи, представленных в табличном виде;

• возможность расширения списка полей для задач;

• страница управления настройками приложения;

• выгрузка проектных решений в Google Таблицы;

• агрегация статистики ведения проектов, собранной из Redmine;

• панель для отображения собранной статистики в виде графиков.
  

Наше решение

1. Разработали систему на базе микросервисной архитектуры. 

При такой архитектуре отдельные компоненты можно  независимо развивать и масштабировать по мере роста компании.

Для разработки пользовательского интерфейса использовали Vue. Серверная часть реализована в виде набора микросервисов на Go, каждый из которых отвечает за определённый набор задач. Всего было создано три микросервиса:

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

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

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

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

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

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

2. Ускорили разработку новых функций. 

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

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

3. Сохранили экспертизу и ускорили подготовку проектов 

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

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

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

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

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

4. Повысили контроль трудозатрат и рентабельности

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

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

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

Для визуализации статистики использовали Grafana.

Для промежуточного хранения данных из Redmine — Redis.

Все компоненты решения развёрнуты в Kubernetes облачного провайдера.

5. Автоматизировали выпуск изменений

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

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

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

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

Бюджет проекта

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

Время реализации

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

Результат

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

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

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