Разработка мобильного приложения для контроля выполнения задач (Task Management)
В Jira есть всё что нужно — кроме того, что мобильное приложение Jira неудобно для полевых сотрудников: монтажников, выездных инженеров, строителей. Они не будут открывать задачу в браузере посреди объекта. Нужно простое приложение: получил задачу → сделал → подтвердил с фото.
Push-уведомления как основа рабочего процесса
Задача назначена → исполнитель получает push с деталями. Дедлайн через 2 часа → напоминание. Задача просрочена → уведомление руководителю. Задача выполнена → уведомление заказчику или постановщику.
Это базовый event-driven workflow, реализуется через FCM с priority: high для назначений и просрочек. Напоминания о дедлайнах — серверный планировщик Bull Queue.
Важный момент для B2B-приложений: у сотрудника может быть заблокирован app store или он использует корпоративный Android (AOSP без Google Services). Тогда FCM не работает. Решение — поддержка Huawei Push Kit (hms_push_kit) и fallback на WebSocket при открытом приложении, SMS для критичных уведомлений.
Модель данных и иерархия задач
Структура задач зависит от домена. Типичная для строительства или сервиса:
- Проект → Этап → Задача → Подзадачи
- Задача имеет: исполнителя, наблюдателей, приоритет, дедлайн, чеклист, вложения, комментарии, геолокацию объекта
Статусная машина задачи: new → in_progress → review → done | rejected. Переходы между статусами — через действия в приложении. Каждый переход генерирует событие → push подписчикам задачи.
На бэкенде — event sourcing для задач: храним не только текущее состояние, но и историю всех изменений. Это даёт аудит-лог и возможность «откатить» ошибочное изменение.
Подтверждение выполнения с медиа
Исполнитель выполнил задачу → нужно приложить фото как доказательство. Это критичная функция для строительства, уборки, технического обслуживания.
Загрузка фото прямо с камеры: ImagePicker на Flutter, сжатие через flutter_image_compress до 1–2 MB (полный размер не нужен для подтверждения), multipart upload на S3.
Геометка обязательна — сотрудник должен физически находиться на объекте. Проверка на сервере: distanceBetween(taskLocation, photoLocation) < 500m. Если расстояние больше — предупреждение, но не блокируем (бывают объективные причины).
Видео до 60 секунд — для технически сложных задач. Загрузка через resumable upload (AWS S3 Multipart Upload) — на мобильном сети могут прерываться.
Offline-режим
Полевые сотрудники часто работают в зонах с плохим интернетом: стройка, промышленные объекты, подвалы. Приложение должно работать offline.
Стратегия: Hive (Flutter) или Room (Android native) для локального хранения задач. При потере сети — все действия (смена статуса, комментарии, фото) пишутся в local queue. При восстановлении соединения — синхронизация через фоновый воркер (WorkManager на Android, BGProcessingTask на iOS).
Конфликты при синхронизации: если руководитель изменил задачу пока исполнитель был offline — LWW (Last Write Wins) по timestamp. Для критичных полей (статус) — серверный merge с уведомлением обеих сторон.
Аналитика и отчётность
Руководитель видит дашборд: задачи по статусам, процент просрочек, нагрузка на исполнителей, среднее время выполнения задач по типам. На Flutter — fl_chart для графиков.
Экспорт отчётов в Excel/PDF — генерация на сервере (библиотека exceljs или puppeteer для PDF), ссылка приходит push-уведомлением: «Отчёт за апрель готов, скачать».
Сроки разработки
| Масштаб | Функциональность | Срок |
|---|---|---|
| MVP | Задачи, статусы, push-уведомления | 6–8 недель |
| Стандарт | + Медиа-подтверждения, offline, аналитика | 12–16 недель |
| Enterprise | + Интеграция с 1С, корпоративный SSO, MDM | 20–26 недель |
Стоимость рассчитывается индивидуально после детализации требований.