Низкая стоимость разработки выглядит убедительным аргументом при выборе ИТ-подрядчика. Если несколько компаний обещают одинаковый результат, естественно выбрать предложение с меньшей ценой. Проблема в том, что за одинаковыми формулировками часто скрываются разные объёмы работ, составы команд и обязательства.
Когда низкая цена становится риском
Бюджетный подрядчик не обязательно работает плохо. Низкая стоимость может быть обоснована, если задача типовая, используется готовое решение, проект ограничен по объёму или исполнитель специализируется на конкретной технологии.
Низкая цена обоснована
- Задача типовая и имеет чёткие границы.
- Решение можно быстро проверить и передать другой команде.
- Подрядчик объясняет, за счёт чего снижена стоимость.
- Состав работ, ограничения и результат зафиксированы.
Низкая цена скрывает риски
- Оценка дана до обследования систем и требований.
- Не раскрываются состав и квалификация команды.
- Тестирование, безопасность и документация исключены.
- Цена изменений и поддержки заранее не определена.
Риск возникает, когда низкая цена достигается за счёт исключения необходимых работ или привлечения команды, не соответствующей сложности проекта. До заключения договора разница почти незаметна. Она проявляется позже — при интеграции, росте нагрузки, устранении уязвимостей или передаче системы другому исполнителю.
Что может отсутствовать в бюджетном предложении
| Область | Полная оценка проекта | Формально низкая оценка |
|---|---|---|
| Требования | Предварительное обследование и уточнение сценариев. | Работа по краткому описанию задачи. |
| Архитектура | Проектирование интеграций, нагрузок и отказоустойчивости. | Решения принимаются по ходу разработки. |
| Команда | Зафиксированы роли и требования к квалификации. | Состав команды не раскрывается. |
| Тестирование | Функциональные, интеграционные и нагрузочные проверки. | Только базовая проверка разработчиком. |
| Безопасность | Требования ИБ включены в проектирование и приёмку. | Проверка проводится после запуска или отсутствует. |
| Документация | Передаются схемы, инструкции и описание интерфейсов. | Документы готовятся только по отдельному запросу. |
| Поддержка | Определены SLA, порядок исправлений и обновлений. | Поддержка не входит в стоимость. |
| Передача проекта | Репозиторий, доступы и среды контролируются заказчиком. | Критичные ресурсы остаются у подрядчика. |
Почему стоимость может быть занижена
Проект рассчитывается по краткому описанию без изучения систем, интеграций, данных и ограничений инфраструктуры.
В проекте нет архитектора, аналитика, тестировщика или специалиста по ИБ. Их задачи перекладываются на разработчиков либо остаются без ответственного.
Начальная стоимость компенсируется дополнительными соглашениями, изменениями и поддержкой после запуска.
Оценка заканчивается запуском. Мониторинг, резервное копирование, обновления, сопровождение интеграций и обучение в неё не входят.
Низкая оценка не всегда является коммерческой уловкой. Иногда исполнитель действительно не понимает масштаб задачи. Для заказчика последствия будут теми же: пересмотр бюджета, перенос сроков и снижение качества.
Полная стоимость ИТ-проекта
Стоимость договора — только одна часть расходов. Для сравнения подрядчиков полезно рассчитывать совокупную стоимость владения системой.
В расчёт следует включать:
- время руководителей, аналитиков и технических специалистов заказчика;
- подготовку и согласование требований;
- лицензии, облачные ресурсы и оборудование;
- интеграцию с корпоративными системами;
- тестирование и контроль качества;
- проверку информационной безопасности;
- документацию и обучение пользователей;
- гарантийную и последующую поддержку;
- устранение технического долга;
- перенос проекта другой команде;
- потери из-за задержки запуска или недоступности системы.
Условный пример расчёта
Компания сравнивает два предложения: 5 млн и 3,5 млн рублей. Второй вариант выглядит выгоднее на 1,5 млн рублей. После начала работ появляются расходы, которых не было в исходном предложении.
договор
новые работы
тесты и переделка
передача проекта
Итог — не менее 6,9 млн рублей без учёта потерь из-за переноса запуска. Цифры приведены как модель расчёта, а не как рыночный норматив.
Технические и процессные риски
Технический долг
В начале проекта упрощённые решения могут почти не влиять на скорость работы. Проблемы появляются по мере развития системы: новая функция требует изменения нескольких модулей, обновление одной библиотеки нарушает совместимость с другими компонентами, а рост нагрузки приводит к замедлению или отказам.
Технический долг возникает в любом длительном проекте. Опасно отсутствие управления им:
- упрощения и архитектурные решения не фиксируются;
- рефакторинг постоянно откладывается;
- автоматические проверки отсутствуют;
- зависимости не обновляются;
- ответственного за архитектуру нет.
В результате значительная часть бюджета расходуется не на развитие продукта, а на сохранение его работоспособности.
Активность команды не равна результату
Количество закрытых задач, часов и отчётов не показывает ценность выполненной работы. Подрядчик может демонстрировать высокую активность, но неоднократно переделывать одну задачу, выпускать изменения с дефектами или реализовывать функции, которые не соответствуют бизнес-сценариям.
Принимать нужно не объём активности, а работающий бизнес-сценарий с понятными критериями качества и комплектом передаваемых материалов.
Для каждого этапа необходимо определить:
- какой пользовательский или бизнес-сценарий реализован;
- какие требования выполнены;
- с какими системами проведена интеграция;
- какие проверки пройдены;
- какие ограничения остаются;
- какие документы и исходные материалы переданы заказчику.
Текучесть команды
Частая замена специалистов увеличивает стоимость проекта, даже если ставка каждого исполнителя остаётся низкой. Новому разработчику необходимо изучить код, архитектуру и историю решений. Пока он погружается в проект, скорость снижается, а вероятность ошибок растёт.
Независимая оценка поможет определить, связана ли проблема с требованиями, архитектурой, квалификацией команды или организацией разработки.
Риски информационной безопасности
Подрядчик получает доступ к исходному коду, инфраструктуре, учётным записям, тестовым средам и иногда к рабочим данным. Поэтому выбор исполнителя — это также решение в области информационной безопасности.
Общие учётные записи, постоянные административные права и отсутствие отзыва доступов после замены специалиста.
Копии рабочих баз переносятся в тестовые среды, на личные устройства или внешние облачные ресурсы.
Используются устаревшие библиотеки, а пароли, ключи и токены попадают в исходный код или журналы.
Действия подрядчика не журналируются, поэтому при инциденте невозможно восстановить полную последовательность событий.
Даже работоспособная система может оказаться небезопасной. Проверка пользовательских функций не выявит ошибки управления доступом, небезопасные настройки и уязвимости архитектуры.
Если подрядчик получает доступ к значимым системам и данным, область проекта следует включить в аудит информационной безопасности. Для публичных веб-сервисов дополнительно может потребоваться тестирование на проникновение.
Если в системе обрабатываются персональные данные, необходимо проверить не только защиту приложения, но и основания обработки, состав данных, доступы, сроки хранения и порядок взаимодействия с исполнителем. Эти вопросы рассматриваются в рамках аудита соответствия требованиям 152-