Разработка программного обеспечения

Код нужен не каждой задаче

Собственное программное обеспечение имеет смысл, когда готовая система не закрывает критичный бизнес-процесс, несколько решений необходимо связать в единый контур или компании нужен цифровой продукт со своей логикой.

Поэтому мы начинаем не с выбора языка программирования, а с бизнес-задачи: кто будет пользоваться системой, что должно измениться в процессе, где находятся данные, какие решения уже работают и какой результат должен быть измеримым.

Если задачу рациональнее решить готовым продуктом, интеграцией или настройкой существующей системы, разработка с нуля не должна становиться самоцелью.

SoftTech Development — специализированная компания группы по разработке ПО и собственным программным продуктам. Подробнее о команде и услугах — на stdev.by.

Когда стоит разрабатывать своё решение

Заказная разработка особенно уместна, когда:

• процесс критичен для бизнеса и заметно отличается от типовых решений;
• готовая система требует большого количества ручных обходов;
• необходимо связать несколько внутренних и внешних платформ;
• нужен личный кабинет, портал или специализированное рабочее место;
• создаётся цифровой сервис для клиентов или партнёров;
• существующая система ограничивает развитие бизнеса;
• требуется проверить новую идею через пилот или MVP;
• компании важно владеть собственной прикладной логикой и управлять её развитием.

На первом этапе важно определить не только желаемые функции, но и ограничения: безопасность, инфраструктуру, интеграции, доступность исходных данных, сроки и критерии приёмки.

Исследование задачи до оценки

До основной реализации мы уменьшаем неопределённость и фиксируем:

• цель проекта и участников процесса;
• пользователей и роли;
• текущий и целевой сценарий работы;
• источники данных;
• бизнес-правила и исключения;
• необходимые интеграции;
• требования к безопасности;
• эксплуатационные ограничения;
• критерии приёмки;
• наиболее рискованные гипотезы.

Результат этого этапа — достаточная основа для архитектуры, плана работ и реалистичной оценки, а не документ ради документа.

Архитектура и данные

Корпоративное приложение редко существует изолированно. Оно может взаимодействовать с ERP, CRM, WMS, POS, eCommerce, платёжными сервисами, внутренними справочниками, внешними API, устройствами и инфраструктурой объекта.

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

Архитектура также должна учитывать:

• роли и права доступа;
• объёмы и жизненный цикл данных;
• требования к производительности;
• резервирование и восстановление;
• журналирование и мониторинг;
• будущие изменения и масштабирование.

Порталы и личные кабинеты

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

• B2B-порталы и личные кабинеты — для клиентов, дилеров и партнёров: внешняя авторизация, организации и роли, заказы, документы, статусы и интеграции с внутренними системами.
• Корпоративный портал для сотрудников — для внутреннего доступа: сотрудники и подразделения, заявки, согласования, знания, внутренние коммуникации и жизненный цикл доступа.

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

Интеграции и API

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

Для сложных интеграционных проектов мы отдельно прорабатываем:

• источники и получателей данных;
• синхронный и асинхронный обмен;
• API, очереди сообщений и файловый обмен там, где это оправдано;
• идемпотентность и повторную обработку;
• права доступа;
• наблюдаемость интеграции;
• тестовый контур;
• документацию и порядок сопровождения.

Подробнее: Интеграции и API →

MVP и пилоты

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

Через пилот можно проверить:

• пользовательский сценарий;
• интеграцию с существующей системой;
• архитектурный подход;
• работу программного обеспечения вместе с устройствами;
• операционный эффект;
• новую модель обслуживания.

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

Что входит в первую версию

Для обсуждения MVP подготовьте один основной сценарий: кто выполняет действие, какие данные нужны на входе и какой результат пользователь должен получить. Отдельно перечислите функции, без которых этот сценарий невозможен, и пожелания, которые можно отложить.

До начала пилота необходимо согласовать:

• проверяемую гипотезу и способ измерения результата;
• состав участников и ограничения тестовой площадки;
• необходимые интеграции и доступность тестовых данных;
• требования к доступу, хранению данных и восстановлению;
• срок наблюдения и условия завершения проверки;
• решение, которое будет принято по результатам: развитие, изменение подхода или остановка.

Прототип интерфейса помогает проверить понятность сценария, но сам по себе не проверяет работу интеграций и поведение системы под нагрузкой. Пилот на одной площадке также не означает готовности к запуску во всей компании: перед расширением нужно пересмотреть нагрузку, поддержку, безопасность и эксплуатационные ограничения.

От чего зависят стоимость и сроки MVP

Количество экранов не даёт полной оценки разработки. На объём работ влияют бизнес-правила, интеграции, качество исходных данных, требования к доступности и способ проверки результата. Если неизвестно, допускает ли внешняя система нужный обмен, сначала требуется проверить эту возможность, а затем оценивать реализацию.

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

Обсудить гипотезу и границы первой версии →

Итерационная разработка

Для сложных систем работу разумно разделять на управляемые этапы:

исследование задачи → архитектура → прототип или MVP → итерации → тестирование → подготовка к запуску → запуск → сопровождение → развитие.

Заказчик регулярно получает работающий результат и может проверять ключевые решения до финальной приёмки, а не узнаёт о фактическом поведении системы в последний день проекта.

Проверка перед запуском

Готовность системы — это больше, чем отсутствие очевидной ошибки в интерфейсе.

В зависимости от критичности проекта проверяются:

• функциональные сценарии;
• права доступа;
• интеграции;
• обработка ошибок;
• производительность;
• резервирование;
• мониторинг и журналирование;
• резервное копирование и восстановление;
• миграция данных;
• план отката;
• документация;
• границы эксплуатационной ответственности.

Конкретный состав проверок определяется архитектурой и ролью системы в бизнесе.

После запуска

Программная система продолжает изменяться после первого релиза. Появляются новые функции, изменения бизнес-процессов, обновления интеграций, требования безопасности и инфраструктурные ограничения.

Поэтому развитие системы требует понятного процесса:

• регистрации дефектов и запросов на изменение;
• приоритизации задач;
• разделения тестового и рабочего окружения;
• контроля релизов;
• мониторинга;
• актуализации документации;
• управления зависимостями.

Сопровождение приложения при этом не следует смешивать с обслуживанием рабочих мест, серверов и сетей. Эксплуатация IT-инфраструктуры относится к направлению IT-аутсорсинга.

Какие задачи относятся к сопровождению

В обращении важно различать сбой, ошибку данных и запрос на новую функцию. Это помогает определить ответственного и не смешивать восстановление работы с плановой разработкой.

Что согласовать до начала поддержки

В состав сопровождения необходимо явно включить приложения, интеграции и окружения, за которые отвечает команда. Отдельно фиксируются часы работы, каналы обращений, категории критичности, порядок эскалации и взаимодействие с владельцами внешних систем.

Время реакции на обращение и срок восстановления — разные условия. Их нельзя подменять одной общей формулировкой о быстром обслуживании. Мониторинг также не означает автоматически круглосуточное выполнение любых доработок: состав и режим работ определяются соглашением.

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

Как отделить поддержку от развития

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

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

Обсудить сопровождение приложения →

Развитие существующего ПО

Не каждую устаревшую систему нужно немедленно переписывать с нуля. Сначала стоит определить, какие компоненты действительно мешают развитию, где накоплен технический долг, какие данные и интеграции критичны и можно ли заменять части системы постепенно.

Такой подход позволяет модернизировать приложение поэтапно и уменьшает риск остановки бизнес-процесса во время перехода.

Конкретная модель модернизации зависит от исходной системы, доступности её кода и документации, архитектуры, интеграций и требований к непрерывности работы.

Собственные продукты как инженерная практика

SoftTech Development развивает собственную линейку программных продуктов CTRL.

Семейство CTRL →

Работа над собственными B2B-продуктами включает тот же полный жизненный цикл: требования, архитектуру, интеграции, пилоты, сопровождение и развитие после запуска.

Это даёт команде практический опыт не только проектной разработки, но и долгосрочной эксплуатации программных продуктов.

Связь с ST Point

Если программный сценарий должен работать на интерактивном терминале, приложение можно связать с аппаратной платформой ST Point.

ST Point отвечает за устройство и необходимую периферию, а команда разработки — за прикладную логику и интеграции в рамках конкретного проекта.

Связь с системной интеграцией

Корпоративное ПО зависит от инфраструктуры: сетей, серверов, идентификации пользователей, мониторинга, резервного копирования, устройств и внешних каналов связи.

В комплексном проекте команды разработки и системной интеграции могут работать совместно, при этом границы ответственности между программным и инфраструктурным контурами фиксируются заранее.

Системная интеграция →

Подтверждённый публичный опыт

Burger King Belarus

В кейсе подтверждены интеграционные задачи и создание специализированных программных инструментов. Детали внутренней архитектуры и бизнес-логики не раскрываются из-за NDA.

Кейс Burger King Belarus →

MOSTRA-GROUP

В публичном кейсе подтверждены интеграционные работы и специализированная разработка для отдельных задач клиента без раскрытия внутренней бизнес-логики.

Кейс MOSTRA-GROUP →

В этих кейсах указаны только те работы, которые входят в опубликованное описание проекта.

Где смотреть подробности о разработке

На stdev.by размещается более глубокая информация о специализированной команде разработки, подходах к работе и текущем предложении SoftTech Development.

Эти ресурсы дополняют друг друга: один помогает рассмотреть задачу в контексте комплексного IT-проекта, второй — перейти непосредственно к разработке программного решения.

Границы компетенции

Опыт интеграции со специализированной системой не означает, что SoftTech автоматически является поставщиком всех решений этой категории.

Без отдельной подтверждённой компетенции не предлагаем как универсальные направления:

• MES;
• SCADA;
• АСУ ТП;
• универсальные ERP и WMS;
• банковские core-системы;
• медицинские информационные системы;
• PMS;
• любую AI/ML-компетенцию только на основании отдельного пилота или маркетингового упоминания.

Такие проекты рассматриваются по фактическому составу задачи и подтверждённой экспертизе.

Обсудить задачу разработки

Для первичного разговора достаточно описать процесс, пользователей, существующие системы и главное ограничение.

Мы определим, что рациональнее: заказная разработка, интеграция, готовый CTRL-продукт, ST Point или развитие существующего решения.

Обсудить программный проект →

Для прямой работы со специализированной командой разработки используйте stdev.by.