NewSmartPro OS — наша внутренняя система управления проектами и финансами. В ней мы связываем продажи, документы, исполнение, платежи и занятость команды. Раньше приложение работало на Supabase. Мы перенесли его на Agnostic, сохранили существующий интерфейс и продолжаем развивать систему под свои процессы. Ниже покажем реальные экраны с закрытыми рабочими данными и разберём, что осталось в прикладном коде, а что взяла на себя платформа.
Почему у проекта четыре независимых состояния
У проекта есть несколько разных обязательств. С заказчиком нужно договориться о работе, подготовить документы, выполнить согласованный объём и получить оплату. Эти части редко движутся синхронно. По одному слову «в работе» трудно понять, что именно уже происходит и где требуется решение.
Возьмём проект, по которому команда начала согласованный этап. Договор ещё проходит подписание, а платёж ожидается позже. Это условная ситуация, которая объясняет нашу модель: состояние исполнения нужно видеть отдельно от документов и денег. Поэтому у каждого проекта в NewSmartPro OS четыре направления со своими статусами.
| Направление | Что отслеживаем |
|---|---|
| Sales | Обсуждение, подготовку предложения, согласование и сделку |
| Legal | Проверку контрагента, подготовку и подписание документов |
| Finance | Финансовую стадию проекта, выставление счёта и оплату |
| Execution | Подготовку, выполнение, поддержку и приёмку работ |
В разделе проектов можно переключаться между этими направлениями и смотреть канбан или таблицу. Тип проекта, бизнес-направление, приоритет и фокус помогают выбрать нужную часть общего списка. Коммерческие работы, внутренние задачи компании и собственные продукты остаются в одной системе, но их можно рассматривать по отдельности.
Такой разбор даёт более конкретный следующий шаг. По одному проекту нужно вернуться к договору, по другому уточнить оплату, по третьему проверить готовность работ. Один общий статус не передаёт эти различия. Завершение исполнения тоже само по себе ещё не закрывает документы и финансовые обязательства.
Дашборд показывает проекты, которые требуют внимания
Главный экран мы используем как отправную точку рабочего разбора. На нём собраны фокус-проекты, высокий приоритет, активное исполнение и ожидание оплаты. Ниже расположены точки внимания, сроки и распределение проектов по направлениям. Из общего обзора можно перейти к конкретному проекту.
Для нас этот экран связывает общий обзор с предметным разговором. Сначала выбираем проект, которому уделим внимание, затем смотрим его продажи, документы, финансы и исполнение. Поля приоритета и фокуса помогают задать порядок обсуждения. Качество такого обзора зависит от того, насколько актуальны внесённые статусы и сроки.
Отдельно на дашборде есть нагрузка руководителей проектов. Здесь она выражена количеством проектов. Для распределения времени команды у нас другой инструмент: ресурсный календарь, где работа планируется уже по часам.
Как связаны проект, плановый платёж и факт оплаты
Статус Finance показывает финансовую стадию проекта, а отдельный раздел «Финансы» нужен для денежных записей. В нём существуют план и факт поступлений и расходов. У записи есть дата, сумма, валюта, направление движения денег, контрагент и связанные проекты. Фактический платёж можно связать с плановым обязательством.
Если в условном плане ожидается 100 тысяч рублей, а к нему внесён факт на 40 тысяч, незакрытая часть составляет 60 тысяч. Это пример расчёта, а не показатель нашей компании. В интерфейсе есть состояния ожидания, частичной оплаты, оплаты и просрочки; для регулярных обязательств предусмотрены повторяющиеся планы.
Записи можно смотреть в таблице, канбане и календаре. Календарь помогает разобрать плановые даты, а фильтры по проекту и контрагенту — перейти к нужному обязательству. Мы получаем ответы на вопросы, что ожидаем получить или заплатить, какие факты уже внесены и какая часть плана ещё не закрыта.
Эта модель описывает платежи. Прибыль проекта требует отдельного расчёта расходов и результата: её нельзя приравнивать к бюджету, поступлению денег или статусу «Оплачено». В этом кейсе мы показываем именно работу с плановыми и фактическими денежными операциями.
Как планируем загрузку команды и свободное время
В ресурсном календаре мы работаем с интервалами занятости. Интервал связывает человека, начальную и конечную даты и плановое время в день. Назначение относится к проекту, внутренней работе или отсутствию; его также можно связать с конкретной задачей. Так у проекта появляется связь с доступным временем исполнителей.
Текущая модель считает ёмкость по будням с базовым восьмичасовым днём и учитывает отсутствия. Из доступного времени вычитается плановая работа, после чего видно свободное время и перегрузку. Производственный календарь и индивидуальные графики в этот расчёт не входят. Это нужно учитывать, когда интерпретируете результат.
Например, если на день запланированы четыре часа проектной работы и два часа внутренних задач, при базовой ёмкости восемь часов остаются два. Перед новым назначением можно посмотреть, чем уже занят человек. Сам план ещё не говорит, сколько часов он фактически отработал: учёт факта времени — отдельный процесс.
Для просмотра доступны календарь, расписание, неделя, месяц, поток и Гантт. Мы можем выбирать представление под вопрос: разобрать день, посмотреть период или проверить интервалы по проекту. При этом исходные назначения остаются теми же записями.
Задачи, контрагенты и документы сохраняют контекст работы
Проект связан с людьми и обязательствами, поэтому мы добавили к нему остальные рабочие сущности. У задачи есть исполнители, приоритет, сроки и связи с проектами и контрагентами. На доске она проходит этапы «Позже», «К выполнению», «В работе», «Проверка» и «Готово». Рядом доступна таблица.
Контрагенты и контакты находятся в отдельном разделе. Организация может иметь несколько ролей, например быть клиентом и партнёром. Представления Bizdev, Legal, Finance и Roles помогают разбирать разные стороны отношений, сохраняя связь с одной организацией.
Документы организованы по папкам. В приложении предусмотрены текстовые материалы, холсты и таблицы; для содержимого хранятся ревизии. Это место для планов, описаний и других материалов рядом с остальными разделами системы. Входящие обращения, в свою очередь, собраны в разделе заявок со стадиями обработки.
В интерфейс также встроен AI-чат с историей диалогов. Его интеграция идёт через отдельный агентный сервис, а история хранится в Agnostic Data. Доступ к данным и возможность выполнять действия зависят от серверных проверок и конфигурации. Само наличие окна чата ещё не описывает, какие операции разрешены в конкретном окружении.
Как переехали с Supabase на Agnostic
До переезда NewSmartPro OS работал на Supabase: у приложения уже были React-интерфейс, представления проектов и собственная модель данных. При переходе на Agnostic мы сохранили эти рабочие представления, а доступ к данным организовали через прикладной API.
Конкретный пример этого решения — адаптер проектов. Он получает записи из нового API и преобразует их в модель, которую понимают существующие компоненты. В ней остаются название проекта, клиент, ответственные, бюджет и четыре состояния. Такой слой позволил использовать привычный интерфейс проектов с новым источником данных.
При переносе важно сохранить смысл связей. Недостаточно загрузить названия проектов, если ответственные и контрагенты после этого превратятся в несвязанные строки. Адаптер сопоставляет идентификаторы и связанные записи. Это помогает перейти от отдельных экранов к приложению, в котором один и тот же проект связывает несколько рабочих процессов.
После переезда с Supabase мы начали экономить на эксплуатации системы. Для нашей нагрузки выгоднее оказалась модель Usage в Agnostic: платим за фактически использованные ресурсы и операции, включая время работы активных сервисов.
Что делает наш код и что даёт платформа
В NewSmartPro OS разделены веб-приложение и серверный сервис. Браузерная часть написана на React и TypeScript, собирается Vite и загружает крупные разделы отдельно. Собственный Node.js API обращается к Agnostic через Runtime SDK. Браузер работает с этим прикладным API; платформенные credentials остаются на сервере.
| Слой | За что отвечает |
|---|---|
| Интерфейс NewSmartPro OS | Дашборд, канбаны, таблицы, карточки и ресурсный календарь |
| Прикладной Node.js API | Рабочие сценарии, проверки доступа и обращение к предметным сущностям |
| Agnostic App Auth | Вход пользователей и проверка сессий через Runtime SDK |
| Agnostic Data | Хранение и получение связанных записей приложения |
Например, при загрузке проектов API проверяет сессию, статус доступа пользователя и его роль. Затем получает записи из Agnostic Data и возвращает данные для интерфейса. Клиентские возможности разделов дополняют эти проверки, но сервер продолжает проверять доступ самостоятельно.
В Data находятся проекты, контрагенты, команда, задачи, интервалы занятости, финансовые планы и факты, документы и история диалогов. При этом правила работы с ними описаны в нашем приложении: какие состояния есть у проекта, как связать платёж с планом и как считать доступное время.
Так мы можем развивать интерфейс и процессы отдельно от механизмов входа и хранения записей. В этом кейсе Agnostic дал платформенный слой, а NewSmartPro OS сохранил предметную модель нашей компании. Обновления такой системы всё равно требуют проверки связей, прав и исходных пользовательских сценариев.
С чего начать собственную систему управления проектами
Начните с одного проекта и перечислите обязательства вокруг него. Что нужно согласовать с заказчиком? Какие документы подготовить? Когда ожидаются деньги? Кто выполняет работу и сколько времени на неё выделено? Если состояния этих частей различаются, сохраните различия в модели.
Затем выберите небольшой сценарий для первого приложения в Agnostic. Например, проект связывает ответственного, срок и плановый платёж. Проверьте создание этих записей, переход между ними и доступ другого участника. После этого можно добавлять задачи, документы и загрузку команды, сохраняя общие связи.
Если у вас уже есть рабочий интерфейс, сначала проверьте, какие его компоненты можно сохранить. Для переноса подготовьте соответствие старых и новых идентификаторов, правила доступа и сценарии проверки. В NewSmartPro OS именно связь существующей модели с новым API помогла продолжить работу над знакомыми представлениями проектов.
Частые вопросы
Можно ли подключиться к NewSmartPro OS как к готовому сервису?
NewSmartPro OS — наша внутренняя система под процессы своей компании. Здесь мы показываем её устройство как пример приложения на Agnostic. Для своей команды можно построить отдельное решение с подходящими сущностями, состояниями и правами.
Финансовый раздел заменяет бухгалтерский учёт?
В показанной модели мы ведём плановые и фактические поступления и расходы, связываем платежи с проектами и видим остаток обязательства. Из этих возможностей не следует наличие полного бухгалтерского учёта, расчёта налогов или прибыли проекта.
Ресурсный календарь учитывает фактически отработанные часы?
В кейсе показано планирование интервалов занятости. Базовая ёмкость — восемь часов с понедельника по пятницу с учётом отсутствий. Это не табель фактически отработанного времени и не производственный календарь.
Нужно ли при переносе полностью менять интерфейс?
В нашем случае существующие компоненты проектов удалось сохранить через адаптер между Agnostic records и прежней моделью интерфейса. Для другого приложения возможность такого переноса зависит от его модели данных и связей.
