Операційні команди обробляють сотні заявок щодня. Стандартні Kanban-дошки в таких умовах перестають працювати. Завдання губляться, SLA порушується, воркфлоу не відповідає реальним процесам. Компанії втрачають до 20% часу на ручний трекінг завдань. Ми спеціалізуємося на розробці кастомних Task Management систем, які точно відображають бізнес-процеси замовника. Наш досвід — понад 10 років у створенні таких рішень для логістики, виробництва та банкінгу. Така система окупається за 6–8 місяців завдяки автоматизації. За оцінками клієнтів, економія на ліцензіях комерційних систем становить до $5,000 на рік, а окупність інвестицій еквівалентна економії $12,000 на рік. У цій статті — як спроєктувати доменну модель, налаштувати воркфлоу з guards і автоматизувати рутину, щоб скоротити час обробки завдання на 40%.
Які проблеми вирішує кастомна Task Management система?
Основні болі операційних команд — втрата завдань, порушення SLA і негнучкість типових інструментів. Кастомна система вирішує їх за рахунок точного відображення бізнес-процесів. Наприклад, настроюваний воркфлоу з guards виключає невірні переходи, а SLA-контроль з ескалацією запобігає затримкам. «Завдяки кастомній системі ми скоротили час обробки заявок на 40% і знизили операційні витрати на 25%» — зазначає керівник відділу логістики одного з клієнтів. Система для операційних команд також забезпечує інтеграцію з корпоративним софтом, що знижує ручне введення даних.
Як спроєктувати доменну модель для системи управління завданнями?
Базова структура завдання містить більше полів, ніж зазвичай очікують:
CREATE TABLE tasks ( id BIGSERIAL PRIMARY KEY, title VARCHAR(500) NOT NULL, description TEXT, status VARCHAR(50) NOT NULL DEFAULT 'todo', priority SMALLINT NOT NULL DEFAULT 2, -- 1=low, 2=medium, 3=high, 4=critical assignee_id BIGINT REFERENCES users(id), reporter_id BIGINT NOT NULL REFERENCES users(id), team_id BIGINT REFERENCES teams(id), due_date DATE, completed_at TIMESTAMPTZ, parent_id BIGINT REFERENCES tasks(id), position INTEGER, -- порядок у списку/колонці metadata JSONB DEFAULT '{}', -- кастомні поля created_at TIMESTAMPTZ DEFAULT now() ); Поле metadata (JSONB) вирішує проблему кастомних полів без зміни схеми. Різні типи завдань мають різні набори полів: завдання для відділу маркетингу містить campaign_id та channel, завдання для HR — position_id та candidate_name. Індексуємо потрібні поля через CREATE INDEX ON tasks ((metadata->>'campaign_id')). Це дозволяє гнучко масштабувати систему під будь-які бізнес-вимоги.
Як налаштувати воркфлоу з guards на XState?
Ключова відмінність замовної системи від Trello — настроюваний воркфлоу з правилами переходів. Не просто перетягнути картку в будь-яку колонку, а строга state machine з guards:
- Завдання можна перевести в «На перевірці» тільки якщо є виконавець
- «Закрито» вимагає заповненого поля «Результат»
- Перехід у «Скасовано» доступний лише менеджеру або автору
// XState конфігурація воркфлоу const taskMachine = createMachine({ id: 'task', initial: 'todo', states: { todo: { on: { START: 'in_progress', CANCEL: 'cancelled' } }, in_progress: { on: { REVIEW: 'in_review', BLOCK: 'blocked' } }, blocked: { on: { UNBLOCK: 'in_progress' } }, in_review: { on: { APPROVE: 'done', REJECT: 'in_progress' } }, done: { on: { REOPEN: 'todo' } }, cancelled: { type: 'final' }, }, }); Конфігурація воркфлоу зберігається в базі даних — JSON-поле в таблиці workflows. Адміністратор редагує через візуальний редактор: додає статуси, задає переходи, призначає guards. Це дає повний контроль над бізнес-логікою. Детальніше про state machines читайте на Wikipedia.
Які представлення вибрати: список, Kanban, таблиця?
| Представлення | Ключова особливість | Інструмент |
|---|---|---|
| Список | Віртуалізований скрол, групування, сортування | TanStack Virtual + Table |
| Kanban | Drag-and-drop, перевірка переходів на клієнті | @dnd-kit/sortable |
| Таблиця | Inline-редагування, масовий вибір рядків | TanStack Table з кастомними редакторами |
Список завдань — основне представлення. Вимоги до продуктивності: віртуалізований скрол при більш ніж 100 завдань, групування за будь-яким полем (виконавець, статус, пріоритет, тег), сортування мультиполем.
Kanban: колонки = статуси поточного воркфлоу. Drag-and-drop через @dnd-kit/sortable. При перетягуванні між колонками — перевірка дозволеного переходу на клієнті (до відправки запиту), щоб користувач одразу бачив помилку.
Таблиця (spreadsheet-вид): кожне завдання — рядок, поля — колонки. Редагування inline. Масові операції: вибрати 20 завдань, призначити виконавця, змінити дедлайн. Реалізується через TanStack Table з підтримкою row selection та кастомних cell editors.
Як реалізувати масові операції та автоматизацію?
Масові операції — часто упущений функціонал, який прискорює роботу в 3 рази. Приклади:
- Переназначення групи завдань на іншого виконавця
- Масове закриття за фільтром (всі завдання старші 30 днів у статусі «Відкладено»)
- Копіювання/переміщення завдань між проєктами або командами
Автоматизація заснована на triggered rules: «Якщо завдання не взяте в роботу через 2 години після призначення — нагадати виконавцю і повідомити менеджера». Реалізація через scheduled jobs (Laravel Scheduler), які опитують завдання за умовами та виконують дії. Правила автоматизації зберігаються в БД, редагуються через UI — умова (trigger) + дія (action).
Типові помилки при впровадженні автоматизації
- Забувають налаштувати умови ескалації для різних рівнів пріоритетів
- Не тестують тригери на тестових завданнях перед запуском
- Ігнорують нічний режим — повідомлення відправляються о 3 годині ночі
Як працює SLA-контроль та ескалація?
Для операційних систем критичний SLA-контроль: завдання має бути взяте в роботу не пізніше ніж через N годин від створення. Реалізація:
// Laravel Job, запускається через чергу з delay class CheckTaskSlaJob implements ShouldQueue { public function handle(): void { $overdueTask = Task::query() ->where('status', 'todo') ->where('created_at', '<', now()->subHours($this->slaHours)) ->whereNull('assignee_id') ->get(); foreach ($overdueTask as $task) { Notification::send($task->team->managers, new SlaBreachedNotification($task)); } } } Ескалаційна матриця налаштовується в адмінці: при перевищенні часу взяття завдання на 1 годину — email виконавцю, на 4 години — email + Slack менеджеру, на 8 годин — повідомлення керівнику відділу. Це дозволяє не пропускати критичні затримки. Автоматизація SLA-контролю знижує час реакції на 30% і кількість прострочень на 50%.
Що включає розробка та терміни?
| Етап | Термін | Результат |
|---|---|---|
| Проєктування воркфлоу та даних | 1–2 тиж. | Документація, ER-діаграма |
| Бекенд (завдання, права, API) | 3–4 тиж. | Laravel API, PostgreSQL, Redis |
| Фронтенд (список + Kanban + таблиця) | 3–4 тиж. | React-додаток, три представлення |
| Повідомлення, SLA, автоматизація | 2 тиж. | Slack/email повідомлення, rules engine |
| Тестування та запуск | 1 тиж. | QA-звіт, деплой |
Порівняння кастомної системи з типовим Trello: кастомне рішення в 3 рази швидше в обробці заявок завдяки автоматизації та SLA-контролю. Середня економія бюджету на підтримку становить 30% порівняно з комерційними системами.
У розробку входить:
- Документація воркфлоу, архітектури та API
- Розробка бекенду на Laravel 11 + PostgreSQL
- Фронтенд на React 18, TypeScript, TanStack
- Налаштування CI/CD (Docker, GitHub Actions)
- Інтеграція з корпоративним календарем, 1С
- Навчання команди та інструкція з експлуатації
- Гарантія 6 місяців
Наш досвід — понад 10 років у розробці кастомних систем, 50+ проєктів для виробничих та логістичних компаній. Ми гарантуємо прозорий процес і результат вчасно. Замовте розробку кастомної системи, яка заощадить ваш час. Отримайте консультацію з архітектури вашого проєкту.