Программный продукт и разовое внутреннее приложение часто начинают одинаково: есть пользователи, есть процесс, нужен интерфейс. Дальше пути расходятся. Продукт рассчитан на повторные релизы, несколько контуров внедрения и жизнь после первой приёмки.
Основная постановка разработки остаётся на странице разработки программного обеспечения. Этот материал помогает не спутать продуктовый цикл с разовой системой, готовой линейкой SoftTech и короткой проверкой гипотезы.
Продукт живёт дольше одного внедрения
Разовая система обычно закрывает процесс конкретной организации. Её успех — принятый сценарий у этих ролей, на этих данных, в этом контуре.
Продукт рассчитан на то, что:
- одной и той же логикой будут пользоваться разные организации или площадки;
- требования будут приходить пакетами, а не одним списком «навсегда»;
- придётся сохранять совместимость, пока часть клиентов ещё на предыдущей версии;
- сопровождение и развитие нельзя отложить «на потом после запуска».
Речь о инженерной модели: продукт должен переживать изменение требований, не превращая каждого клиента в отдельную ветку кода.
Если нужна проверка одной гипотезы на ограниченном контуре, сначала смотрите MVP и пилотные проекты. Если нужен внутренний инструмент под один процесс — заказная разработка или ориентир по корпоративным системам.
Дорожная карта, релизы и дисциплина изменений
У продукта появляется очередь изменений, которой нет у разовой поставки.
Дорожная карта отвечает, какие сценарии войдут в ближайшие выпуски, а какие сознательно ждут. Без этого каждый заказчик тянет продукт в свою сторону, и общая версия быстро распадается.
Релизная дисциплина включает:
- понятный состав выпуска;
- проверку не только новой функции, но и уже принятых сценариев;
- канал, которым пользователи узнают об изменении;
- возможность отката, если выпуск ломает рабочий контур;
- разделение срочного исправления и планового развития.
Сопровождение продукта после запуска описано на странице поддержки программного обеспечения. Там же проходит граница с IT-аутсорсингом инфраструктуры.
Архитектура, которую можно менять
Для продукта недостаточно «чтобы сейчас открывалось». Нужно заранее решить, что будет меняться чаще: правила, роли, интеграции, отчёты, каналы доступа.
В постановке обычно учитывают:
- расширение данных без поломки уже сохранённых записей;
- подключение новой интеграции, не переписывая ядро сценария;
- наблюдаемость: где смотреть сбой, задержку обмена, ошибку прав;
- разделение клиентских особенностей и общей логики продукта;
- поддержку предыдущих версий на оговорённый период, если это нужно бизнесу.
Наблюдаемость и сопровождение не появляются сами после красивого интерфейса. Если их нет в модели, каждый второй релиз будет расследованием вслепую.
Первая версия продукта может быть узкой. Это нормально, если узкость сознательная. Рост «когда появится спрос» без модели данных, выпусков и поддержки — уже не продукт, а набор срочных доработок.
Готовые продукты CTRL и заказная продуктовая работа
У SoftTech уже есть линейка собственных B2B-продуктов CTRL. Она закрывает подтверждённые сценарии: двор и транспорт, парковка, маркировка, учёт активов и другие направления, описанные на продуктовых страницах.
Если задача совпадает с готовым CTRL-продуктом, заказная продуктовая разработка не должна повторять его «ещё раз под другим названием». Сначала проверяют, закрывает ли существующий продукт процесс, интеграции и ограничения внедрения.
Заказная продуктовая работа уместна, когда:
- нужен программный продукт со своей логикой, которой нет в CTRL;
- компания развивает собственный сервис и ей нужна инженерная модель релизов, а не разовый внутренний инструмент;
- пилот подтвердил гипотезу, и дальше требуется дисциплина версий, а не набор доработок под каждого пользователя.
Связка с устройствами и объектами может идти через ST Point, если сценарий должен работать на терминале. Продуктовая логика при этом всё равно остаётся прикладной: устройство не заменяет дорожную карту и сопровождение.
Оценка зависит от процесса, данных, интеграций и того, кто принимает решения по приоритетам. Срок вывода, ожидаемая нагрузка и состав платформы согласуются по конкретной задаче.
Чтобы поставить задачу, опишите, чем продукт должен отличаться от разового внедрения, кто будет пользоваться разными версиями и какие изменения точно появятся после первого запуска. Дальше задача возвращается в контур разработки программного обеспечения.
Специализированная команда — на stdev.by.