Заказная разработка нужна не потому, что «своё всегда лучше готового». Она нужна, когда готовый продукт, настройка существующей системы или обмен между уже работающими приложениями не закрывают критичный процесс без чрезмерных обходов.
На уровне группы задача сначала рассматривается на странице разработки программного обеспечения. Здесь — как создаётся отдельное приложение: кто им пользуется, какие данные оно ведёт, с чем связывается, как его принимают и кто развивает после запуска.
Состав работ специализированной команды — на stdev.by.
Когда своё приложение оправдано
Своё решение обычно обсуждают, если:
- процесс заметно отличается от типовых сценариев готовых продуктов;
- сотрудники постоянно обходят систему таблицами, письмами и ручным переносом данных;
- несколько ролей работают с одними объектами, но в разных системах видят разное состояние;
- компании важно самой владеть прикладной логикой и управлять её изменениями;
- готовый продукт закрывает часть задачи, но вокруг него всё равно нужен отдельный рабочий контур.
Заказная разработка не заменяет автоматически:
- готовый продукт SoftTech, если он уже закрывает сценарий, — смотрите семейство CTRL;
- обмен между существующими системами без нового приложения — это интеграции и API;
- формализацию повторяемого процесса со статусами и правилами — автоматизация бизнес-процессов;
- настройку или доработку уже работающей системы — развитие существующих систем.
Если задача ещё не сформулирована дальше «нам нужна программа», разумнее начать с исследования, а не с выбора языка и платформы.
Сначала пользователи и сценарии
До оценки фиксируют не список экранов, а рабочую ситуацию.
Нужно понять:
- кто будет пользоваться приложением и какие у этих людей полномочия;
- что человек делает сегодня и что должно измениться после запуска;
- какой результат считается приемлемым, а какой — ошибкой;
- какие исключения встречаются чаще штатного сценария;
- какие данные нужны на входе и что система должна сохранить;
- какие соседние системы уже есть и нельзя ли обойтись обменом без нового контура;
- где проходит граница между первой версией и последующим развитием.
Результат этого этапа — согласованные границы, роли, сценарии и критерии приёмки. Этого достаточно, чтобы обсуждать архитектуру и объём работ. Отдельный объёмный документ сам по себе ценность не создаёт.
Что обычно остаётся за рамками первой версии
В первую поставку не стоит включать всё, что «когда-нибудь пригодится». Откладывают отчёты второго уровня, редкие роли, дополнительные каналы доступа и интеграции, без которых основной сценарий всё равно можно проверить.
Если цель — только проверить гипотезу на ограниченном контуре, это ближе к MVP и пилотным проектам, чем к полноценному приложению «сразу на всю компанию».
Данные, интеграции и ответственность
Корпоративное приложение редко живёт отдельно. Оно может читать и записывать данные учётной системы, справочники, статусы заявок, файлы, события оборудования или внешние сервисы.
До разработки определяют:
- какая система хранит эталонные данные о клиенте, заказе, товаре, сотруднике или другом объекте;
- кто создаёт запись и кто может её изменять;
- что происходит при конфликте двух систем;
- как обрабатывается удаление, архивирование и повторная отправка;
- какие сведения нельзя показывать части ролей.
Если эталон нигде не зафиксирован, новое приложение быстро становится ещё одним местом, где «правильная» версия данных не совпадает с соседней системой.
Интеграционный слой при этом не обязан быть самим приложением. Когда основная задача — связать уже существующие системы, каноническое описание лежит на странице интеграций и API.
Архитектура и требования к работе системы
Архитектура нужна не как витрина технологий, а как ответ на ограничения бизнеса.
В постановке учитывают:
- роли и права доступа;
- объём и срок хранения данных;
- доступность в рабочие окна компании;
- журналирование действий и возможность разобрать сбой;
- резервное копирование и восстановление;
- тестовый контур отдельно от рабочей среды;
- то, как система будет меняться после первого запуска.
Конкретный набор требований зависит от роли приложения. Внутренний инструмент на десятки пользователей и сервис, с которым работают клиенты или партнёры, задают разные ожидания к доступу, нагрузке и сопровождению. Ориентир по типу системы — на странице корпоративных систем.
Стек, облако, число серверов и требования к производительности определяются сценарием, данными и ограничениями заказчика.
Как выглядит путь от постановки до передачи
После исследования работа обычно идёт так:
согласованные границы → архитектура и модель данных → интерфейс ключевых сценариев → разработка и проверки → подготовка к запуску → приёмка → передача → сопровождение.
Заказчик должен видеть не только макеты. Важно проверять реальные сценарии: создание записи, ошибку данных, отказ внешней системы, права доступа и восстановление после сбоя.
Интерфейс
Интерфейс проектируют вокруг ролей и действий, а не вокруг «набора страниц». Сначала основной сценарий, затем исключения. Красивый прототип без данных и интеграций не доказывает, что система заработает в операционном контуре.
Разработка, проверка и выпуск
В зависимости от критичности проверяют функциональные сценарии, права, обмен с внешними системами, обработку ошибок, восстановление и возможность отката выпуска. Состав проверок согласуется до начала основной реализации, а не в день запуска.
Сборка, тестовая среда и выпуск входят в работу, если без них нельзя безопасно передать систему. Конкретная платформа и регламент выпуска определяются проектом.
Приёмка и передача
Приёмка опирается на заранее описанные критерии, а не на ощущение, что «в целом работает». К передаче относят исходный код и права на него в согласованном объёме, инструкцию по сборке и выпуску, описание интеграций, ролей, известных ограничений и порядка сопровождения.
После передачи развитие не смешивают с авариями инфраструктуры. Сопровождение приложения описано отдельно: поддержка программного обеспечения. Рабочие места, серверы и сети — это IT-аутсорсинг.
Что нужно для первой оценки
Для разговора достаточно описать процесс, а не выбирать язык программирования.
Полезно передать:
- какую работу система должна изменить;
- кто будет пользоваться и с какими правами;
- какие системы уже есть и какие данные нельзя потерять;
- основной сценарий и два-три типичных исключения;
- что должно войти в первую версию, а что точно нет;
- есть ли тестовые данные и контур для проверки обмена;
- кто со стороны заказчика принимает решения по процессу и по IT.
После этого можно понять, нужна ли заказная разработка, интеграция, готовый продукт, пилот или развитие уже существующего решения. Сроки, бюджет, состав команды и конкретные технологии определяются по задаче.
Обсудить задачу заказной разработки →
SoftTech Group и SoftTech Development
SoftTech Group помогает поставить задачу в контексте соседних контуров: инфраструктуры, оборудования, готовых продуктов и эксплуатации. SoftTech Development выполняет специализированную разработку приложения, интеграций и программных продуктов.
Эти роли не подменяют друг друга. Группа не превращает любую IT-задачу в написание кода, а команда разработки не подменяет системную интеграцию и обслуживание инфраструктуры.
В проектах Burger King Belarus и MOSTRA-GROUP SoftTech выполнял интеграционные задачи и специализированную разработку программных инструментов. Детали клиентской логики закрыты NDA.
Для прямой работы со специализированной командой используйте stdev.by.