В этой статье
Главная мысль
Достоверная оценка SaaS связывает первый рабочий сценарий с трудозатратами, неопределённостью и эксплуатацией. Разбейте объём на пакеты работ, оценивайте одинаковые допущения и явно учитывайте миграцию и поддержку.
Оценивайте путь пользователя, а не список экранов
Возьмём условный B2B-сервис бронирования. Первый рабочий сценарий позволяет организации пригласить коллегу, создать бронь, избежать конфликта и получить подтверждение. «Пять экранов» не описывают работу: приглашения истекают, права различаются, брони создаются одновременно, а почтовый сервис может отказать.
Задайте приёмочные примеры каждого шага. Может ли администратор отозвать доступ? Что после сбоя подтверждения? Какие записи видит поддержка? Это раскрывает логику интерфейса и делает предложения поставщиков сравнимыми: одна оценка включает восстановление и администрирование, другая молча предполагает только успешный путь.
Бюджет следует за объёмом работ
Категории затрат для оценки, а не фиксированная смета.
Объём продукта
Пользовательские сценарии, бизнес-правила и критерии приёмки.
Интеграции и данные
API, миграция, права доступа и внешние зависимости.
Эксплуатация во времени
Хостинг, поддержка, безопасность и будущие изменения.
Постройте прозрачную модель трудозатрат
Учебный сценарий, не предложение и не рыночный ориентир: 8 человеко-дней на исследование и дизайн, 18 на основной сценарий, 10 на идентификацию и интеграции, 12 на проверки и выпуск, 7 на администрирование и передачу. Всего 55 человеко-дней. Условный резерв неопределённости в 11 дней даёт плановый объём 66 человеко-дней.
Умножьте трудозатраты на согласованную среднюю дневную ставку; лицензии и инфраструктуру считайте отдельно. Человеко-дни не равны календарным: параллельность, частичная занятость, ожидание обратной связи и зависимости меняют срок. Ценность модели — в видимых допущениях, которые исследование заменяет доказательствами, а не в самих числах.
На что уходят условные 55 человеко-дней
Учебные допущения, не смета. База: 55 дней; резерв: 11 дней; плановый объём: 66 человеко-дней. Календарный срок и внешние расходы отдельно.
человеко-дней
Сократите первый выпуск, сохранив пригодность
В бронировании отложите несколько календарных провайдеров, сложные тарифы и конструктор аналитики. Сохраните предотвращение конфликтов, базовые права, видимость для поддержки и восстановление. Удаление второстепенной функции сокращает объём; удаление исправления неудачной брони перекладывает работу на пользователей и поддержку.
Первый выпуск отвечает на продуктовый вопрос: будут ли команды координировать брони здесь? Измеряйте завершения и отказы, общайтесь с вернувшимися к таблицам. Не финансируйте каталог второстепенных функций до использования основного пути. При этом прототип, не способный работать с реальными клиентскими данными, нельзя оценивать или представлять как промышленный выпуск.
Найдите неопределённости, меняющие оценку
Недокументированный API, несогласованные старые данные или неясная изоляция арендаторов меняют архитектуру, а не просто добавляют экраны. Изучите их заранее ограниченным техническим экспериментом. Для календаря проверьте аутентификацию, лимиты и конфликты на типичной учётной записи до фиксации точной оценки.
Ведите реестр допущений: владелец, доказательства, дата решения и влияние на бюджет. Если допущение не подтвердилось, обсуждайте изменение объёма, а не прячьте трудозатраты в старой оценке. Диапазон полезен, когда понятна разница нижней и верхней границ. Отделяйте неизвестные требования от обычного резерва реализации.
Планируйте месяцы после запуска
Регулярные расходы — хостинг, хранение, почта, мониторинг, резервные копии и внешние сервисы. Работа людей — обновление зависимостей, поддержка, инциденты и развитие продукта. Считайте это отдельно от разработки, указывая трафик, сроки хранения и часы обслуживания. Дешёвый хостинг может сочетаться с большой ручной нагрузкой.
Запрашивайте инструкции развёртывания, владельцев доступов, доказательства восстановления и список отложенных работ. После запуска сверяйте использование и заменяйте допущения измерениями. Бюджет сможет развиваться с продуктом, а не потеряет смысл с приходом первого клиента.
ВОПРОСЫ / РЕШЕНИЯ
Частые вопросы
Можно начать с небольшого бюджета?+
Сокращайте область решения, не скрывая необходимые безопасность, восстановление и ответственность. Если минимальный безопасный объём не помещается, остановитесь или выберите другой подход.