Nixys > Журнал > Кейс: разработка системы проработки проектов

Кейс: разработка системы проработки проектов

  • 28 января 2025
  • #

Если коротко:

Разработали автоматизированную систему с удобным web-интерфейсом, которая помогла инженерам сократить время составления проработки с 2 часов до 10 минут. 

Клиент

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

Проблема

Раньше все проработки велись в Google Docs, и эта система управления проектами перестала быть удобной.

 К примеру: 

  1. из-за отсутствия стандартизации и готовых шаблонов команде приходится вручную вести множество задач и вносить данные по проектам. Это отнимает много времени и иногда приводит к ошибкам;  
  2. менеджеры долго формируют и поздно отправляют коммерческое предложение. Перехват лида компанией-конкурентом — уже не редкость; 
  3. опыт предыдущих проработок не сохраняется. У IT-отдела нет возможности детально документировать технологии и этапы работы над проектами. Вместо того чтобы тратить время и вспоминать, как они выполняли похожие задачи в прошлом, инженеры могут сосредоточиться на решении аналогичных задач.

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

Задача

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

Как он должен работать? 

  1. От клиента поступает запрос на настройку инфраструктуры. 
  2. Под каждый запрос в сервисе создаётся отдельный проект, в рамках которого команда определяет и поэтапно описывает состав работ в виде задач. Каждая задача содержит детальную информацию: название, перечень действий, необходимых для её решения, оценку времени и календарные сроки. 
  3. Инженеры выгружают подготовленные проектные решения в Google Spreadsheets.

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

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

  • Наличие web-интерфейса с авторизацией;
  • Авторизация на основе учётных данных в Redmine;
  • Разделение прав доступа на основе ролевой модели;
  • Создание и ведение внутри сервиса проектов, разделённых на этапы и задачи, представленных в табличном виде;
  • Наличие возможность расширения списка полей для задач;
  • Наличие страницы управления настройками приложения;
  • Выгрузка проектных решений в Google Spreadsheets;
  • Агрегация статистики ведения проектов, собранной из системы задач (Redmine);
  • Наличие дашборда для отображения собранной статистики в виде графиков.

Наше решение

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

В качестве Frontend был использован Vue. Backend был выполнен в виде набора разработанных на Go микросервисов, каждый из которых выполнял свой набор задач. Всего было создано 3 микросервиса со следующими ролями:

  • Первый: реализует основной функционал сервиса, с которым непосредственно работает frontend. 
  • Второй: обеспечивает кэширование из Redmine данных, необходимых для авторизации. 
  • Третий: собирает и обрабатывает статистику. 

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

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

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

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

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

Чтобы инженеры заказчика могли использовать опыт, полученный в ходе ранее выполненных работ, мы разработали специальные шаблоны. Они представляют собой задачи с уже заполненными полями, такими как название сервиса, критерии его приемки, оценка времени выполнения и другие. Благодаря новой системе с шаблонами время составления проработки проектов сократилось с 2 часов до 10 минут

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

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

Для визуализации статистики был использован распространенный инструмент Grafana.

Для промежуточного кэширования данных из Redmine был использован Redis.

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

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

Кроме того, хорошо организованные процессы CI/CD позволили сократить время, необходимое разработчику для каждого релиза. Если раньше этот процесс занимал около 10 минут, то сейчас — не более минуты. На этапе разработки в день выпускалось около 2-3 релизов. Таким образом, теперь инженер экономит до 30 рабочих минут в день.

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

Frontend — 120 000 ₽ 

Backend — 460 000 ₽ 

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

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

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


Обсудить проект

Обязательно заполните одно из полей: «E-mail»/«Телефон».
Контакт «Telegram» - дополнительный.

 

и/или

Соглашаюсь на обработку персональных данных

См. Политику обработки персональных данных