Разработка ПО и приложений

Запросы «разработка ПО» и «разработка приложений» в поиске часто ведут к одним и тем же ожиданиям: «сделайте нам систему». На практике это два слоя. Программное обеспечение — правила, данные, интеграции, отчёты. Приложение — способ, которым человек эти правила выполняет руками: на складе, в машине, в очереди, дома на диване. Если заказать только красивый клиент без ядра, бизнес-логика расползётся по экранам. Если заказать только ядро без клиента, сотрудники останутся в Excel и мессенджере.

Статья о том, когда нужны оба контура, как спроектировать границу и как заказывать работы, не дублируя страницы услуг. Коммерческие описания направлений остаются на разработке ПО и разработке приложений. Здесь — логика решения.

Когда достаточно одного слоя

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

Оба слоя нужны, когда одно и то же правило должно выполняться в поле и в офисе: резерв товара, статус заявки, права «кто видит чьи сделки», офлайн-очередь, пуш клиенту и отчёт директору. Тогда мобильный экран — не отдельный продукт, а витрина того же ядра.

Как связать ПО и приложение, чтобы не заплатить дважды

Источник правды один. Заказ, клиент, остаток, статус — сущности сервера, не копии в каждом клиенте. Клиенты (web, iOS, Android, админка) ходят в один API. Если каждое приложение хранит «свою» логику скидок, вы получите четыре версии прайса и скандал на сверке.

Контракт API версионируйте. Мобильный клиент обновляется медленнее сайта: люди не ставят релиз сразу. Ядро должно переживать старую версию клиента или честно требовать обновление. Без этого «мы поменяли поле на сервере» ломает стор на неделю.

Что обычно входит в ядро

• Учётные сущности и статусы.
• Роли, аудит действий.
• Очереди, уведомления, задания.
• Интеграции с 1С, оплатой, телефонией, почтой.
• Отчёты и выгрузки.

Что обычно входит в приложение

• Сценарий «здесь и сейчас» для одной роли.
• Пуши, камера, гео, офлайн-кэш — по необходимости.
• Публикация, если нужен стор.

Организация работ и команды

Один владелец продукта на оба слоя. Иначе мобильная команда обещает клиенту слот, а учётка не умеет его резервировать. Демо смотрите сквозным сценарием, не «отдельно сервер, отдельно кнопка». Тесты контракта API обязательны, если клиентов больше одного.

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

Типичные ошибки связки

Две базы: «в приложении своё, в 1С своё, свернём по пятницам». Дублирование валидации только на клиенте: злоумышленник или старая сборка обойдёт правила. Слишком толстый мобильный клиент с бизнес-логикой, которую нельзя переиспользовать в админке. Забыть, что админка — тоже клиент ядра, её нужно закладывать в бюджет.

Ещё ошибка — начинать с дизайна всех мобильных экранов до модели данных. Красивые макеты не сходятся со складскими исключениями. Сначала исключения процесса, потом UI. Проектирование ядра — проектирование и разработка ПО, процесс клиента — процесс разработки приложений.

Безопасность на стыке слоёв

Права считаются на сервере. Мобильное приложение можно потерять, прошить, подменить. Сессии, срок жизни токенов, отзыв доступа уволенного сотрудника — зона ядра. Журнал действий нужен, когда спор «кто подтвердил отгрузку». Подробнее — безопасная разработка ПО.

Когда не заказывать оба слоя сразу

Не сразу, если гипотеза не проверена: начните с веба или даже с ручного контура. Не сразу, если нет владельца данных. Не сразу, если «приложение» на самом деле лендинг с кнопкой звонка. Сужайте: зачем нужен MVP, нужно ли приложение.

Следующий шаг

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

Разбор контура — Grevin, grevin.info@mail.ru, контакты.

Контракт API как совместный документ

Когда заказывают разработку ПО и приложений вместе, самый дорогой артефакт — не макет и не выбор базы, а контракт: какие поля обязательны, какие ошибки бывают, как выглядит идемпотентность, как версионировать. Документ короткий и живой: его меняют осознанно, с датой, с пометкой, какая версия клиента ещё жива в сторе.

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

Админка, отчёты и «невидимый» третий клиент

Почти всегда есть третий клиент — веб-админка. Её забывают в бюджете «приложения» и в бюджете «ПО». Менеджер меняет слот, видит оплату, банит пользователя, выгружает реестр. Без этого слоя полевой клиент становится перепиской с разработчиком. Заложите админку в ядро с первого пилота хотя бы в узком виде: список объектов, смена статуса, поиск.

Отчёты строите из тех же событий, что пишет ядро. Отдельная «аналитическая база по пятницам» снова разъедется. Если нужен тяжёлый отчёт, вынесите его в витрину, но источник факта оставьте один. Иначе директор и кладовщик будут спорить цифрами, а не процессом.

Нагрузка, очереди и пуши

Пуш «заказ собран» кажется функцией приложения, а рождается в ядре: событие, очередь, провайдер, токен устройства, повтор при сбое. Если очередь только в мобильном коде, при убитом процессе событие умрёт. Если только на сервере без учёта отзыва разрешения — вы шлёте в пустоту и считаете, что «уведомления не работают». Проектируйте канал как сквозной сценарий.

Нагрузка пилота и нагрузка «все точки сети» отличаются. Не стройте микросервисы ради статьи. Стройте наблюдаемость: медленный запрос, очередь, которая растёт, ошибка интеграции. Это дешевле, чем архитектура «как у маркетплейса» на старте. Услуги слоёв: ПО, приложения.

Договор на два слоя без двойной оплаты сюрпризов

В договоре явно напишите, какие клиенты входят, какой API считается сданным, кто чинит, если сервер изменил поле и старый клиент упал. Иначе мобильная команда скажет «это backend», backend — «это клиент». Хозяин контракта один. Приёмка — сквозной сценарий на устройствах и в админке, не два акта «сервер отдельно, apk отдельно» без связи.

Бюджет сопровождения тоже сквозной: новая iOS и новая версия платёжного шлюза прилетают в один месяц. См. сопровождение ПО и стоимость создания приложения.

Синхронизация релизов ядра и клиентов

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

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

Данные в поле: кэш, конфликты, «чья правда»

Офлайн-приложение без правил конфликта превращает склад в споры. Кто побеждает: последняя запись с планшета или правка оператора в офисе? Время сервера или время устройства? Проектируйте явно: запрет редактировать закрытый документ офлайн, очередь неотправленных, индикатор «не синхронизировано». Пользователь должен видеть долг синхронизации, иначе он думает, что «сохранилось».

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

Команда и демо сквозного сценария

На демо всегда один сценарий от поля до отчёта. Не два слайда. Если курьер создал событие, оператор его видит, отчёт его считает — инкремент ценен. Если «мы сделали красивый список» без записи в ядре — это ещё не связка слоёв. Заказчик имеет право требовать такой формат демо в договоре как критерий прозрачности.

Оценка работ тоже сквозная: вырезали интеграцию — сказали, что сломается в клиенте. Добавили роль — сказали, какие экраны и какие API. Иначе слои живут в разных сметах и сходятся только на скандале. Контакты для такой оценки — страница контактов.

Чек-лист перед договором на оба слоя

Источник правды назван. Контракт API с версией. Админка в бюджете. Пилотная роль в поле определена. Стратегия старых клиентов в сторе ясна. Хозяин сквозного сценария один. Секреты и репозиторий у заказчика. Сопровождение оценено отдельно. Если пункта нет — это не «мелочь», это риск двойной оплаты. Прочитайте ещё проектирование ПО и процесс приложений, затем собирайте оценку. Grevin: grevin.info@mail.ru, контакты.

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

Пример сквозного сценария, который сшивает слои

Курьер отмечает прибытие. Ядро пишет событие, проверяет права, ставит статус, кладёт задачу оператору, планирует пуш клиенту. Админка показывает точку на карте. Отчёт вечером считает опоздания. Если хоть одно звено живёт в Excel, это ещё не разработка ПО и приложений, а два проекта рядом. На демо прогоняйте именно такую цепочку. На оценке делитесь по звеньям, но принимайте целиком. Так заказчик видит ценность, а не набор экранов.

Исключения цепочки тоже проектируйте: нет сети, нет GPS, клиент отозвал пуш, оператор уже сменил статус. Без исключений красивый happy path развалится в первый рабочий день. Это дольше описать, чем нарисовать макет, и дешевле, чем чинить в проде. Безопасность токена курьера и журнала статусов заложите сразу: безопасная разработка ПО.

Не делать два продукта с двумя правдами

Финальная проверка перед стартом: если оператор меняет статус в админке, поле это видит без звонка. Если не видит — у вас два продукта. Соедините их контрактом до кода. Тогда разработка ПО и приложений станет одним контуром с двумя витринами, а не двумя счетами за одну боль. Этого правила достаточно, чтобы отсечь половину провальных тендеров «сделайте и то и другое как-нибудь».

Частые вопросы