Заказная разработка

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

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

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

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

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

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

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

Интеграция — это явный контракт. Для API, вебхука, очереди или файлового обмена указываются направление, идентификация, версия, схема, проверка, авторизация, идемпотентность, ограничения, ожидаемая задержка, повторы, порядок, ошибки, наблюдаемость и владелец. OpenAPI описывает HTTP-интерфейс, но сам по себе не устанавливает деловой смысл и надёжность. Поведение поставщика и потребителя проверяется на границе, включая частичный сбой, повторную доставку, устаревшие данные и недоступную зависимость.

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

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

Сборка и выпуск отделяют код от конфигурации среды. Секреты не попадают в репозиторий; права, ротация и аварийный доступ определены. Зависимости выбираются осознанно, фиксируются или ограничиваются по ситуации, проверяются и обновляются управляемым способом. Различия между разработкой, тестированием, предпроизводственной и промышленной средой документируются. CI/CD уменьшает ручную вариативность только при ясных согласованиях, происхождении артефакта, защите среды и откате.

Изменения остаются достаточно небольшими для проверки и восстановления. Эволюция базы данных учитывает старую и новую версии приложения, заполнение данных, валидацию и пределы отката. Флаги, постепенное включение или параллельная работа применяются там, где снижают конкретный риск. Производительность оценивается по представительным сценариям и показателям сервиса, а не только по синтетическим баллам. Решения, исключения, известный технический долг и остаточный риск остаются видимыми при приёмке.

Требования безопасности выводятся из пользователей, данных, действий, границ доверия и правдоподобных злоупотреблений. Модель угроз охватывает идентификацию, авторизацию, ввод, бизнес-логику, хранение, связь, администрирование, зависимости и восстановление. Secure Software Development Framework NIST задаёт общую структуру для безопасных практик в разных жизненных циклах. Мы указываем применённые практики и свидетельства; ссылка на SSDF не означает независимой сертификации всех задач и результатов.

Для веб-приложения согласованные версия, уровень и объём OWASP ASVS превращают расплывчатое слово «безопасно» в проверяемые требования. Применимые пункты связываются с проектированием, реализацией и тестами; записываются проверенные области, устранённые существенные замечания, исключения и остаточный риск. Независимый пентест, сертификация, регуляторный анализ, постоянный мониторинг безопасности и реагирование на инциденты являются отдельным объёмом, если предложение прямо не включает их. Абсолютная безопасность не обещается.

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

Надёжность определяется через значимые для пользователя показатели. Доступность, задержка, успешная обработка, свежесть данных, возраст очереди или восстановление могут иметь разный вес в разных сценариях. SLI измеряет наблюдаемую характеристику, SLO задаёт внутреннюю цель, SLA закрепляет договорное обязательство и последствия. Эти понятия нельзя подменять друг другом. Режимы отказа, покрытие мониторинга, резервирование, восстановление, ёмкость и пределы зависимостей описываются рядом с целью.

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

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

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

Постоянная эксплуатация — отдельная письменная ответственность. Она может включать мониторинг, работу с инцидентами и проблемами, обновление зависимостей, реакцию на уязвимости, резервные копии, проверку восстановления, ёмкость, контроль затрат и согласованный объём изменений. Часы, каналы, ожидаемое время ответа, эскалация и исключения указываются явно. Заказ на разработку сам по себе не означает работу 24/7, фиксированную реакцию, SLA по доступности, неограниченные изменения или бессрочную поддержку.

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