Собственное ПО: владение, эксплуатация и ответственность после релиза
Автор: Инженер-программист
Практическое руководство по снижению TCO и управлению рисками
Главный страх бизнеса: что будет через год после релиза
Реальный диалог с CIO крупного ритейлера:
— Мы потратили 40 млн на систему управления складом. Через год подрядчик ушёл. Теперь каждое изменение — 2 млн и 3 месяца ожидания. Мы в заложниках.
Корень проблемы:
Система работает, но:
- Документация — формальная (никто не понимает)
- Архитектура — в головах ушедших разработчиков
- Зависимости — захардкожены
- Изменения — только через подрядчика
Цена вопроса (реальные цифры):
| Сценарий | Год 1 (разработка) | Год 2–5 (поддержка) | Итого за 5 лет |
|---|---|---|---|
| Плохая архитектура | 30 млн | 15 млн/год | 90 млн |
| Хорошая архитектура + low-code | 35 млн | 8 млн/год | 67 млн |
| Экономия | -5 млн | +7 млн/год | 23 млн (25%) |
Как low-code снижает TCO: конкретные сценарии
Сценарий 1: Изменение бизнес-формы
Задача: Добавить в форму заявки 3 новых поля и изменить правила валидации.
Без low-code (классический подход):
1. Задача в backlog: 1 неделя ожидания
2. Разработка: 2 дня (фронт + бэк + тесты)
3. Тестирование: 1 день
4. Деплой: согласование релиза, 1 неделя
Итого: 2–3 недели, стоимость: 150–250 тыс. руб.С low-code (Retool/Appsmith):
1. Бизнес-аналитик открывает конструктор
2. Добавляет поля (drag-and-drop)
3. Настраивает валидацию (визуально)
4. Публикует изменения
Итого: 2 часа, стоимость: 5–10 тыс. руб.Экономия на 10 таких задачах в год: 1.5–2.5 млн руб.
Сценарий 2: Новый отчёт для руководства
Задача: Ежемесячный отчёт по продажам с 15 показателями и 5 срезами.
Без low-code:
- Аналитика требований: 2 дня
- SQL-запросы и оптимизация: 3 дня
- Фронтенд-разработка: 2 дня
- Интеграция в систему: 1 день
Итого: 8 дней, стоимость: 300–400 тыс. руб.С BI/low-code инструментом (Metabase, Superset):
- Аналитик подключает источник данных
- Настраивает визуализации
- Сохраняет в дашборд
Итого: 4 часа, стоимость: 15–20 тыс. руб.Экономия на 20 отчётах в год: 5–7 млн руб.
Сценарий 3: Изменение workflow согласования
Задача: Добавить новый этап согласования для контрактов > 5 млн руб.
Без BPM:
java
// Код, который боятся трогать
if (contract.getAmount() > 1_000_000) {
if (contract.getCategory().equals("IT")) {
addApprover(cto);
if (contract.hasRisks()) {
addApprover(cfo);
}
}
}
// + ещё 200 строк if-else
```
Изменение: 2 недели (разработка + регрессионное тестирование), стоимость: 400–600 тыс. руб.
**С BPM (Camunda):**
- Открыть BPMN-диаграмму
- Добавить новый шлюз и задачу
- Настроить условие: `amount > 5000000`
- Опубликовать версию процесса
Изменение: 1 час, стоимость: 5 тыс. руб.
**Экономия на 12 изменениях процессов в год:** 4–6 млн руб.
---
## Зоны ответственности: что должно остаться под контролем
### Модель разделения
```
┌─────────────────────────────────────┐
│ Бизнес самостоятельно (low-code) │
│ • Формы и UI │
│ • Отчёты и дашборды │
│ • Простые workflow │
│ • Справочники │
├─────────────────────────────────────┤
│ Бизнес + ИТ (согласование) │
│ • Сложные процессы │
│ • Интеграционные сценарии │
│ • Изменения модели данных │
├─────────────────────────────────────┤
│ Только ИТ (архитектурный контроль)│
│ • Ядро системы │
│ • Безопасность │
│ • Производительность │
│ • Инфраструктура │
└─────────────────────────────────────┘Чек-лист передачи ответственности бизнесу
Можно передать бизнесу, если:
- Логика не влияет на другие системы
- Ошибка не приведёт к финансовым потерям > 100 тыс. руб.
- Есть откат на предыдущую версию одной кнопкой
- Изменения автоматически логируются
- Есть тестовая среда для проверки
Пример правила:
Бизнес может менять порядок полей в форме, но не может менять API-интеграции с банком.
Эксплуатация: минимальный набор для контроля
1. Мониторинг (что измерять)
Для кода:
- Время ответа API (p95, p99)
- Количество ошибок (rate, типы)
- Потребление ресурсов (CPU, память)
Для low-code:
- Количество активных пользователей
- Среднее время выполнения процессов BPM
- Количество зависших workflow
Инструменты: Prometheus + Grafana (open source), стоимость внедрения: 500 тыс.–1 млн руб.
2. Логирование (что фиксировать)
Обязательные события:
- Кто и когда изменил бизнес-правило в low-code
- Ошибки интеграций
- Изменения критичных данных (суммы, статусы)
Хранение: 30 дней online, 1 год в архиве.
Инструменты: ELK Stack, Loki, стоимость: 300–700 тыс. руб./год.
3. Регламенты изменений
Шаблон регламента:
markdown
# Регламент изменений в low-code платформе
## Кто может вносить изменения
- Формы/UI: бизнес-аналитики
- Процессы: бизнес-аналитики + согласование ИТ
- Интеграции: только ИТ
## Процесс изменения
1. Изменение в тестовой среде
2. Проверка (чек-лист)
3. Согласование (если требуется)
4. Публикация в прод
5. Мониторинг 24 часа
## Откат
При критичной ошибке: откат на предыдущую версию за 5 минут
```
### 4. Документация (что должно быть)
**Минимальный набор:**
- Схема архитектуры (C4 model: контекст, контейнеры, компоненты)
- Описание bounded contexts
- ADR (Architecture Decision Records) — почему выбрали это решение
- Runbook для инцидентов (что делать при падении)
**Формат:** Markdown в Git, автогенерация диаграмм (PlantUML, Mermaid).
---
## L3/L4 поддержка: как сделать передаваемой
### Проблема vendor lock-in
**Типичная ситуация:**
```
Система работает → подрядчик ушёл →
новая команда не понимает код →
каждое изменение — риск →
бизнес боится что-то менятьРешение: архитектурная прозрачность
Принципы передаваемой системы:
- Модульность: Каждый модуль можно понять за 1 день
- Стандартизация: Используются популярные технологии (Spring Boot, PostgreSQL, React)
- Low-code на периферии: Изменения не требуют знания всей системы
- Тесты: 70%+ покрытие критичной логики
Чек-лист передачи команде:
- Провели 3 сессии knowledge transfer (по 4 часа)
- Новая команда самостоятельно внесла 2 изменения под контролем
- Документация актуальна (проверили по чек-листу)
- Доступы и окружения переданы
- Runbook проверен на учебном инциденте
Срок передачи: 2–4 недели для команды из 3–5 человек.
Экономика: почему хорошая архитектура дешевле
Расчёт TCO на 5 лет (система для 500 пользователей)
Сценарий A: Плохая архитектура, монолитный код
| Год | Разработка | Изменения (50/год) | Поддержка L2/L3 | Итого |
|---|---|---|---|---|
| 1 | 25 млн | 5 млн | 2 млн | 32 млн |
| 2–5 | — | 8 млн/год | 4 млн/год | 48 млн |
| Всего | 80 млн |
Сценарий B: Модульная архитектура + low-code
| Год | Разработка | Изменения (50/год) | Поддержка L2/L3 | Итого |
|---|---|---|---|---|
| 1 | 30 млн | 3 млн | 2 млн | 35 млн |
| 2–5 | — | 4 млн/год | 3 млн/год | 28 млн |
| Всего | 63 млн |
Экономия: 17 млн руб. (21%) за счёт снижения стоимости изменений.
Откуда берётся экономия
Сценарий B дешевле, потому что:
- 40% изменений делает бизнес в low-code (без разработчиков)
- Изменения в коде быстрее (модули изолированы, меньше регрессий)
- L3 поддержка дешевле (система понятна, меньше escalation на L4)
Модель владения: система как актив
Критерии зрелого владения
Уровень 1 (зависимость):
- Всё через подрядчика
- Нет документации
- Бизнес боится менять
Уровень 2 (контроль):
- Есть внутренняя команда
- Документация актуальна
- Архитектура понятна
Уровень 3 (актив):
- Бизнес самостоятельно делает 30–50% изменений в low-code
- Система развивается без критичной зависимости от подрядчика
- TCO предсказуем и снижается
Roadmap перехода к уровню 3 (6 месяцев)
Месяц 1–2: Аудит и документирование
- Описать архитектуру (C4 model)
- Выделить bounded contexts
- Зафиксировать ADR
Месяц 3–4: Внедрение low-code слоя
- Выбрать платформу (BPM, low-code UI)
- Перенести 5–10 форм/процессов
- Обучить бизнес-аналитиков
Месяц 5–6: Передача знаний
- Knowledge transfer для внутренней команды
- Регламенты эксплуатации
- Тестовые изменения под контролем
Результат: Система под контролем, TCO снижается на 20–30% со второго года.
Главные принципы
- Владение начинается с архитектуры: Без понятной структуры передать систему невозможно.
- Low-code снижает TCO, если на периферии: Ядро — код, изменения — low-code.
- Документация = страховка: Актуальная документация снижает риск потери команды.
- Бизнес должен участвовать: 30–50% изменений должны делать бизнес-аналитики без программистов.
- Хорошая архитектура дороже в начале, дешевле в эксплуатации: Экономия проявляется со второго года.
Инвестиция в контролируемость: +15–20% к стоимости разработки.
Возврат инвестиций: 12–18 месяцев за счёт снижения TCO.