DS Kanban: система управления проектами и ресурсами вместо Jira

Главное о кейсе

DIGITAL SECTOR выпустил крупное обновление DS Kanban — собственной системы управления проектами для заказной веб-разработки. Обновление затронуло основные рабочие сценарии проектных команд и стало одним из наиболее значимых этапов развития системы.

DS Kanban создавался как альтернатива Jira, которая не учитывала внутреннюю логику компании. Система объединяет задачи, сроки, загрузку команд, учёт трудозатрат и отчётность. В ней также рассчитывается рентабельность проектов. Ежедневно DS Kanban пользуются более 100 сотрудников.

По оценке команды, настройка нового проекта больше не требует вручную собирать рабочий процесс. Количество пересечений при распределении специалистов сократилось на 75–80%, а ошибочных действий на доске — примерно на 80%.

Как проект изменил жизнь пользователей

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

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

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

Бизнес-задача и ее решение

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

DS Kanban связал рабочее время с конкретными проектами и задачами. Руководители видят трудозатраты, загрузку и доступность специалистов и учитывают эти данные при распределении работ.

На этапе оценки рентабельность рассчитывается по предполагаемому объёму работ. В ходе проекта фактические трудозатраты, состав команды, поступления и расходы могут отличаться от плана. DS Kanban связывает проект со сделкой в Битрикс24, сметой и движением денежных средств, а для расчёта использует фактические трудозатраты из задач.

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

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

Крафт (мастерство), реализация, технические детали

1. Фреймворк как основа

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

Мы выбрали Laravel, потому что у команды глубокая экспертиза в этом фреймворке, а сам он хорошо подходит под проект и его архитектурные принципы. Laravel — популярный и стабильный php-фреймворк с большим сообществом и развитой экосистемой.

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

DS Kanban изначально проектировали как быструю систему без избыточной архитектурной сложности. Вместо многоуровневой архитектуры и сложных паттернов команда придерживалась принципа KISS: backend построен на стандартной архитектуре php и Laravel, а дополнительные решения использовались только там, где возможностей фреймворка было недостаточно.

Отдельное внимание уделили работе с данными. Команда спроектировала структуру базы, настроила запросы и индексы. После этого проверили основные запросы и дополнительно оптимизировали те, которые можно было ускорить. В результате большинство запросов backend обрабатывает менее чем за 100 мс.

После появления Laravel Octane команда подключила его в связке со Swoole, что позволило дополнительно ускорить backend. Frontend построен на React.js и Next.js без SSR и получает данные через запросы к backend. Сценарии спроектированы так, чтобы для отображения страницы требовалось небольшое количество запросов.

В результате доска проекта с 1000 задачами загружается примерно за 300 мс, отдельная карточка — за 200–300 мс. При этом система минимально использует кеширование: данные в DS Kanban часто меняются, поэтому высокая скорость достигается за счёт простой архитектуры, правильно спроектированной базы данных и оптимизации запросов.

3. Фокус на нормализации данных

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

4. Максимальная гибкость там, где она нужна

Основа работы доски проекта — флоу (workflow). Это описанный в коде набор правил и особенностей работы для конкретного типа проекта.

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

5. Интеграции с корпоративными системами

DS Kanban синхронизирован с Битрикс24: данные об отпусках, удалённой работе и других отсутствиях автоматически учитываются при планировании загрузки. REST API и вебхуки позволяют обмениваться данными с другими корпоративными сервисами и BI-системами.

6. Расчёт рентабельности в отдельном backend-сервисе
Расчёт объединяет данные о сделке из Битрикс24, смете, фактических поступлениях и расходах, а также трудозатраты из DS Kanban. В нём учитываются затраты на команду, налоги и накладные расходы.

Отдельный backend-сервис получает исходные данные, выполняет вычисления и передаёт в DS Kanban готовые показатели. Это снижает нагрузку на DS Kanban и Битрикс24, а конфиденциальные исходные значения не передаются на frontend.

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

Как технические решения влияют на работу системы

В основе DS Kanban — принцип не усложнять систему там, где этого не требует бизнес-задача. Простая архитектура, оптимизированная работа с базой данных и небольшое количество запросов позволяют сохранять высокую скорость даже при больших объёмах проектных данных. Единая модель данных и интеграции связывают задачи, ресурсное планирование, отчётность и финансовые показатели проекта. Отдельный сервис-калькулятор выполняет ресурсоёмкие вычисления, не нагружая основные системы, и передаёт в интерфейс готовые результаты. Архитектура позволяет развивать DS Kanban без остановки ежедневной работы команд.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Инициатива проекта исходила от сотрудников DIGITAL SECTOR. Команда пользовалась облачной Jira, но ей не хватало скорости и гибкости: при большом объёме данных задачи могли открываться с задержкой, а внутренние процессы приходилось подстраивать под ограничения сервиса. Поэтому собственную систему начали разрабатывать ещё до ухода Jira из России.

Когда Jira прекратила работу с российскими пользователями, DS Kanban уже находился на стадии альфа-версии. Команда перенесла проекты без остановки работы: в один рабочий день сотрудники завершили работу в Jira, а на следующий продолжили её в DS Kanban.

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

При развитии системы команда увидела, что расчёт на этапе подготовки сметы не показывает, остаётся ли проект рентабельным во время выполнения. Фактические трудозатраты могут превысить оценку, состав команды — измениться, а поступления и расходы — отличаться от плана. Так появилась гипотеза: если автоматически связать задачи и трудозатраты со сметой и финансовыми данными, руководитель сможет увидеть отклонение до завершения проекта. На этой основе в DS Kanban появился расчёт рентабельности.

Предложения и сообщения об ошибках можно отправлять прямо из DS Kanban. Обратная связь сотрудников остаётся основой развития системы, а крупное обновление стало продолжением этого подхода.

Прочая информация о кейсе

DS Kanban — внутренний продукт DIGITAL SECTOR, поэтому компания одновременно выступает разработчиком, заказчиком и основным пользователем системы. Показатели эффективности основаны на результатах ежедневной эксплуатации решения более чем 100 сотрудниками.

Скриншоты

Комментарий заказчика

Самое важное в DS Kanban — не то, что мы заменили один инструмент другим. Проект изменил сам подход к внутренним системам: теперь, если процесс компании требует нового сценария, нам не нужно искать обходной путь или ждать, когда такая возможность появится в чужом продукте. Мы можем сами определять, как должна работать система, и менять её вместе с бизнесом