Короткий ответ: стоимость корпоративного портала определяется не количеством экранов, а числом процессов, ролей, интеграций и требований к данным. Один портал может быть простым рабочим кабинетом, а может включать заявки, документы, согласования, уведомления, поиск и связь с CRM или ERP. Поэтому корректная оценка начинается с карты процессов и границ первой версии, а не с фразы «сделайте как у нас в таблицах».
Что именно оплачивает заказчик
В бюджете есть несколько разных слоёв: discovery и проектирование, интерфейс, серверная часть, авторизация, роли, интеграции, тестирование, перенос данных, инфраструктура и сопровождение. Если считать только разработку экранов, позднее появляются «неучтённые» работы: права доступа, повторная отправка данных, журнал действий, обработка ошибок и обучение пользователей.
Портал полезно описывать через результат процесса. Например, не «раздел заявок», а «сотрудник создаёт запрос, руководитель согласует, исполнитель получает задачу, а инициатор видит статус и историю». Такая формулировка сразу показывает, какие состояния, роли и уведомления нужны системе.
- процессы и роли
- данные и интеграции
- интерфейс и доступность
- тестирование и эксплуатация
Три уровня сложности
Условно можно выделить три уровня. Первый — несколько справочников, авторизация и один внутренний процесс. Второй — несколько отделов, разные права, уведомления, файлы, поиск и интеграции. Третий — много источников данных, сложные согласования, аудит действий, импорт истории, повышенные требования к безопасности и доступности.
Это не готовая таблица цен: границы между уровнями зависят от конкретной компании. Такая классификация нужна, чтобы сравнивать предложения по одинаковому составу работ и не путать демо-версию с системой, которой будут пользоваться все отделы.
- описать один сквозной сценарий
- отделить MVP от плана развития
- выделить рискованные интеграции
- согласовать критерии приёмки
Интеграции меняют оценку сильнее дизайна
Связь с CRM, ERP, кадровой системой, почтой, файловым хранилищем или электронным документооборотом добавляет не только API-вызов. Нужно определить источник истины, правила синхронизации, владельца данных, формат ошибок, повторы и журналирование. Если внешняя система недоступна, портал должен понятным образом показать состояние и дать восстановить обмен.
NIST SSDF рекомендует встраивать безопасные практики в жизненный цикл разработки, а не оставлять их на последнюю неделю. Для заказчика это означает простой вопрос к подрядчику: где в плане учтены секреты, права, логи, тестовые данные, резервирование и исправление уязвимостей?
- зафиксировать контракт обмена
- проверить тестовый контур
- описать повторную отправку
- назначить владельца интеграции
Безопасность и доступность — часть бюджета
Роли «сотрудник», «руководитель» и «администратор» — только начало. Важно проверить доступ к объектам, скачивание файлов, экспорт, смену подразделения, завершение сессии и действия от имени другого пользователя. OWASP ASVS можно использовать как основу для проверяемых требований к безопасности веб-приложения и как язык для договора.
WCAG 2.2 помогает обсуждать доступность не абстрактно, а через клавиатурную навигацию, фокус, контраст, подписи полей, сообщения об ошибках и понятные состояния интерфейса. Это полезно и для сотрудников без особых ограничений: хороший фокус и ясная ошибка сокращают число неправильных действий.
- матрица ролей и объектов
- негативные сценарии
- загрузка и экспорт файлов
- клавиатура и сообщения об ошибках
Как разбить проект на этапы
Практичный порядок — короткий discovery, карта данных и ролей, прототип одного пути, техническая проверка самой рискованной интеграции, реализация сквозного MVP, тестирование, пилот и расширение. После каждого этапа должен оставаться проверяемый результат: прототип, работающий сценарий, отчёт тестов или список принятых ограничений.
Для бюджета отдельно покажите разовые и эксплуатационные расходы: разработку, миграцию, инфраструктуру, мониторинг, поддержку и изменения после запуска. Так руководитель видит не только цену старта, но и условия, при которых портал останется рабочим через полгода.
- результат каждого этапа
- допущения и исключения
- критерии готовности
- план поддержки
Когда портал не нужен
Если процесс редкий, несложный и не требует интеграций, готового инструмента может быть достаточно. Заказная разработка оправдана, когда ручная координация повторяется, ошибки дороги, нужны собственные роли и источники данных или существующие системы не дают контролируемого сквозного сценария.
Сравнивать стоит не «портал против ничего», а несколько вариантов владения: настроить готовый продукт, расширить текущую систему или разработать своё решение. В расчёт входят лицензии, ограничения, перенос данных, обучение, поддержка и стоимость обходных ручных операций.
- частота и цена процесса
- ограничения готового решения
- стоимость владения
- готовность владельца продукта
Как Paladin Engineering помогает оценить задачу
Paladin Engineering может начать с discovery: разобрать роли и сценарии, найти источник истины для данных, выделить интеграционные риски и собрать варианты первой версии. В результате заказчик получает не обещание «портал под ключ», а понятные границы, последовательность работ и список решений, которые нужно принять до договора.
Для предварительной оценки достаточно принести один частый процесс, список систем, пример ролей и несколько исключений. Этого уже хватает, чтобы провести рабочую сессию и понять, где нужна настройка, а где — отдельная разработка.
Нужна предварительная оценка? Напишите в Telegram или оставьте заявку: обсудим задачу, границы первой версии и риски до начала основной разработки.
Часто задаваемые вопросы
Можно ли назвать цену по числу страниц?
Нет. Страницы не показывают число ролей, состояний, интеграций и проверок. Надёжнее оценивать сквозные процессы и отдельно фиксировать допущения.
Что включить в MVP портала?
Один приоритетный процесс, авторизацию, нужные роли, журнал статусов, обработку ошибок и критерии пилота. Второстепенные модули вынести в план развития.
Нужен ли discovery?
Если есть несколько отделов, систем или владельцев данных, да. Он помогает проверить границы проекта до основной разработки.
Как сравнить предложения подрядчиков?
Свести их к одной матрице: этапы, результат, интеграции, безопасность, тестирование, миграция, поддержка, исключения и условия изменения оценки.
Как не забыть поддержку?
Заранее определить мониторинг, владельца продукта, канал ошибок, сроки реакции и порядок выпуска изменений.
Как Paladin Engineering может помочь
Проведём discovery, разложим пользовательские сценарии, проверим данные и интеграции, подготовим прототип или план реализации. Такой разбор помогает принять решение между готовым решением, настройкой и заказной разработкой.
Если задача уже сформулирована, пришлите описание процесса и ограничения. Мы поможем оценить следующий шаг и обсудить реализацию без обещаний, которые не подтверждены входными данными.
Веб-разработка Paladin Engineering · Контакты · Другие статьи
Комментарии