Размытые требования - это не проблема коммуникации, это статья расходов
Техническое задание - дорогой документ. Его составление требует времени аналитика, архитектора и, нередко, юриста.
Заказчики нередко воспринимают этот этап как формальность - что-то, что надо «быстро согласовать» перед стартом. Это ошибка.
Каждое неуточнённое требование на этапе ТЗ стоит в 5-10 раз дороже при правке в процессе разработки и в 20-50 раз дороже - после запуска.
Это не метафора, это практическая реальность: чем позже обнаруживается несоответствие ожидаемому поведению системы, тем больше частей решения нужно переделать.
Что нужно зафиксировать до старта
- Сценарии использования - не функции, а конкретные пользовательские пути
- Граничные случаи - что происходит при ошибке, недоступности сервиса, нестандартном вводе
- Интеграции - какие внешние системы уже или будут задействованы, есть ли у них программный интерфейс обмена данными и насколько стабильно они работают
- Масштаб - сколько пользователей, какова пиковая нагрузка, каковы требования к отказоустойчивости
На практике мы нередко замечаем, что у заказчика есть чёткое представление о продукте - но оно существует в голове, а не в документе.
Наша задача на старте - его оттуда извлечь. Это не собеседование и не экзамен: чем больше вы рассказываете, тем точнее мы считаем и тем меньше вы доплачиваете.
Инфраструктура: ежемесячные расходы, которые не входят в смету
Разработка - это единовременная стоимость. Инфраструктура - это постоянная.
И она начинается в день запуска.
Серверы и размещение системы
Выбор инфраструктуры зависит от характера нагрузки, требований и географии пользователей.
Облачные решения и собственные центры обработки данных - это разные стоимостные модели и разные компромиссы.
Для нагруженных корпоративных систем мы, как правило, проектируем инфраструктуру под конкретный профиль нагрузки ещё на этапе архитектуры - это позволяет избежать переплаты за избыточные мощности и аварийного масштабирования в спешке.
Сторонние сервисы и абонентские платы
Если в продукте предусмотрены SMS-уведомления, приём платежей, распознавание документов или карт - каждый из этих компонентов имеет свою стоимостную модель: поштучную, подписочную или процентную.
Это не скрытые расходы - это архитектурные решения, которые нужно принимать осознанно.
Мы по умолчанию анализируем, где целесообразно использовать готовый сервис, а где выгоднее собственная реализация.
Зависимость от внешнего поставщика - это всегда риск: изменение тарифов, прекращение работы сервиса, санкционные ограничения.
Это нужно учитывать при проектировании.
Резервирование и безопасность
Отдельная статья бюджета, которую заказчики склонны откладывать «на потом».
Стоимость восстановления после инцидента - потеря данных, сетевая атака, уязвимость в коде - как правило, на порядок выше, чем превентивные вложения в безопасность.
Для систем, работающих с персональными данными или чувствительными для бизнеса данными, этот вопрос не опциональный.
Поддержка и развитие: продукт не заканчивается на запуске
Запуск - это не финиш, это начало эксплуатации. И у эксплуатации есть своя экономика.
В любой сложной системе могут появляться ошибки, которые не воспроизводятся в тестовой среде и проявляются только под реальной нагрузкой и в реальных сценариях использования.
Это нормально. Ненормально - не иметь договорённости о том, кто, в какие сроки и за какой бюджет их устраняет.
Второй типичный сценарий: после нескольких месяцев работы с продуктом у команды заказчика появляются обоснованные правки - изменение бизнес-логики, новые интеграции, доработка интерфейса.
Если этот процесс не структурирован с самого начала (как именно формируются задачи, оцениваются, приоритизируются и оплачиваются), каждая правка превращается в отдельные переговоры.
Мы предпочитаем обсуждать модель поддержки еще на стадии активной разработки: фиксированная абонентская плата, оплата по фактически затраченному времени и ресурсам или гарантированный уровень обслуживания - каждый формат подходит под разные ситуации и о каждом из них стоит говорить чтобы заложить оптимальный.
Юридическая и документальная сторона
Программный продукт, работающий с пользователями, обязан соответствовать требованиям законодательства.
Минимальный набор для большинства пользовательских и корпоративных сервисов:
Минимальный набор
- Пользовательское соглашение / оферта
- Политика обработки персональных данных
- Политика использования cookie
- Лицензионное соглашение (если продукт лицензируется)
Отсутствие этих документов - это не просто формальное нарушение.
Регуляторные штрафы, блокировка сервиса, невозможность обработки платежей - реальные последствия, которые мы видели на практике.
В нашей команде есть специалист, закрывающий юридическую сторону проектов: от разработки документации до консультаций по вопросам, специфичным для конкретного продукта или рынка.
Это не обязательная услуга, но она существенно снижает риски на старте.
Свои юридические документы мы держим открытыми на сайте: политика обработки персональных данных и политика использования cookie - это минимум, который мы сначала сделали у себя, а потом рекомендуем заказчикам.
Обучение и внедрение
Для корпоративных систем - планирование ресурсов предприятия (ERP), управление клиентами (CRM), управление производством (MES), управление персоналом (HRM), бизнес-аналитика (BI), внутренних платформ и государственных систем - стоимость внедрения нередко сопоставима со стоимостью разработки.
Обучение персонала, миграция данных, параллельная эксплуатация старой и новой системы, адаптация бизнес-процессов - всё это имеет временной и финансовый эквивалент.
Мы закладываем этот этап в план проекта с самого начала: разрабатываем обучающие материалы, проводим сессии с ключевыми пользователями, документируем процессы.
Экономия на внедрении почти всегда выходит дороже: сотрудники медленнее переходят на новую систему и продолжают работать по старым привычкам.