Из чего складывается стоимость ПО на заказ и как держать её под контролем

Две компании просят «простой портал для наших клиентов» и получают предложения, которые сильно отличаются по цене. Обычно оба подрядчика честны. Они оценивают разные вещи, потому что запрос оставляет открытыми большинство реальных решений: кто пользуется порталом, с какими системами он взаимодействует, что происходит, когда что-то идёт не так.

В разработке ПО на заказ стоимость определяется не столько количеством экранов, сколько количеством правил, ролей и связей, которые за ними стоят. Исследование McKinsey и Оксфордского университета, охватившее более 5400 ИТ-проектов, показало, что крупные проекты в среднем превышали бюджет на 45 процентов и при этом приносили на 56 процентов меньше ценности, чем прогнозировалось. Значительная часть этого разрыва возникает из-за того, что никто не зафиксировал на старте.

Ниже перечислены факторы стоимости, с которыми мы сталкиваемся чаще всего, и рабочие привычки, которые помогают держать их под контролем.

Основные факторы стоимости

Объём работ и количество ролей

Каждый тип пользователя добавляет больше, чем просто вход в систему. Система для одной группы (например, офисных сотрудников) намного проще, чем система для сотрудников, руководителей, клиентов, поставщиков и аудиторов, каждый из которых видит свои данные и может выполнять свои действия. Каждая роль умножает правила доступа, экраны, уведомления и тестовые сценарии. Составляя список пользователей, сразу укажите, что каждый из них не должен видеть.

Интеграции

Подключение к бухгалтерской системе, ERP, банку, курьерской службе, налоговому органу или платёжному провайдеру часто оказывается самой крупной отдельной статьёй проекта. Трудоёмкость зависит от другой стороны: есть ли документированный API, тестовая среда, стабильный формат данных, человек, который отвечает на вопросы? Подключение к хорошо документированному сервису может занять несколько дней. Подключение к старой системе, которая выгружает файлы только раз в сутки ночью, может занять недели, и оно будет требовать внимания при каждом изменении этой системы.

Миграция данных

Перенос данных из таблиц или старой системы кажется простым копированием. На практике это означает удаление дубликатов, заполнение пропущенных полей, сопоставление старых кодов с новыми и решение, что делать с записями, которые никуда не подходят. Кроме того, именно на миграцию представителям бизнеса приходится тратить больше всего времени, потому что только они знают, являются ли «ABC SRL» и «A.B.C. S.R.L.» одним и тем же клиентом.

Требования к качеству и безопасности

Инструмент, которым пользуются пять коллег, и система, которая обрабатывает платежи или персональные данные, являются разными продуктами, даже если экраны выглядят похоже. Требования к доступности системы, времени отклика, журналам аудита, резервному копированию, управлению доступом и защите данных добавляют работу по проектированию, тестированию и документированию. Опубликованные стандарты помогают сделать эти требования конкретными. ISO/IEC 25010 описывает характеристики качества продукта, такие как надёжность, безопасность и сопровождаемость, а OWASP Application Security Verification Standard содержит перечень требований к безопасности с разными уровнями строгости. Если выбрать уровень, соответствующий вашему реальному риску, вы не заплатите за недостаточный уровень и не переплатите за избыточный.

Платформы

Веб-приложение, которое хорошо работает в браузерах на компьютерах и мобильных устройствах, представляет собой один продукт. Нативные приложения для iOS и Android, офлайн-режим для сотрудников склада или поддержка старых браузеров в сети клиента добавляют каждый свою работу по разработке, тестированию и выпуску. Прежде чем выходить в магазины приложений, проверьте, не закрывает ли реальную потребность адаптивное веб-приложение.

Модель команды

Собственная команда, фрилансер, внешняя команда или их сочетание: у каждого варианта свой профиль затрат. Более низкая дневная ставка не всегда означает более низкую общую стоимость, если координация, переделки и передача дел занимают больше времени. Важно, кто принимает решения, как быстро вы получаете ответы на вопросы и как знания остаются в вашей компании, если люди меняются.

Как держать стоимость под контролем

Начните с минимально жизнеспособного продукта

Определите самую небольшую версию, которая приносит реальную пользу реальным пользователям, и создайте её первой. Для клиентского портала это может быть вход, статус заказа и скачивание документов, без чата, аналитики и мобильного приложения. MVP не является демоверсией: люди должны пользоваться им в ежедневной работе. Его задача в том, чтобы подтвердить действительно важное, прежде чем вы потратите деньги на то, что только может оказаться важным.

Поставляйте поэтапно

Разделите работу на короткие этапы, каждый из которых заканчивается работающим ПО, которое можно попробовать. Принцип из Манифеста Agile по-прежнему актуален: поставлять работающее ПО часто, с периодичностью от пары недель до пары месяцев. Каждый этап становится естественной точкой, чтобы пересмотреть расходы, изменить приоритеты или остановиться. Длинный проект с единственной поставкой в конце не даёт вам ни одной из этих возможностей.

Сформулируйте чёткие критерии приёмки

Для каждой функции письменно договоритесь, как вы поймёте, что она готова. «Счета можно экспортировать» звучит расплывчато. «Бухгалтер может экспортировать все счета за выбранный месяц в файл, который бухгалтерская система импортирует без ручных правок» можно проверить. Чёткие критерии сокращают споры, переделки и скрытые затраты на функции, которые месяцами остаются «почти готовыми».

Управляйте изменениями осознанно

Требования будут меняться, и это правильно, когда вы узнаёте что-то новое. Проблема в неуправляемых изменениях. Придерживайтесь простого правила: каждый новый запрос получает краткое письменное описание, оценку и решение о том, что переносится на потом, чтобы освободить для него место. Так бюджет остаётся прозрачным, а первая версия не разрастается незаметно.

Учитывайте совокупную стоимость владения

Первый релиз составляет лишь часть стоимости. За время жизни системы вы также платите за:

хостинг, домены, сертификаты и резервные копии
сторонние лицензии и плату за использование API
обновления безопасности и обновления библиотек, от которых зависит ПО
мониторинг и поддержку, когда что-то ломается
небольшие изменения по мере того, как меняются ваши процессы и законодательство
время, которое ваши сотрудники тратят на администрирование системы

Упрощения, на которые идут ради ранней даты запуска, тоже имеют свою цену. Мартин Фаулер называет это техническим долгом: запутанный внутренний код замедляет каждое будущее изменение, как проценты по кредиту. Определённый долг может быть разумным выбором для MVP, если это осознанное решение и вы погашаете его на следующих этапах.

Чек-лист перед запросом предложения

Перечислите роли пользователей и то, что каждая из них может видеть и делать.
Перечислите все системы, к которым должно подключаться ПО, с контактным лицом для каждой.
Опишите, какие данные у вас есть сегодня и где они хранятся.
Отметьте юридические требования и требования безопасности: персональные данные, электронные счета, аудит, сроки хранения.
Решите, какие платформы нужны сейчас, а какие могут подождать.
Определите, что должна включать первая рабочая версия, а чего в ней быть не должно.

Подрядчик, получивший такой список, может делать оценку на основе фактов, а не предположений, а вы можете сравнивать предложения по единым критериям.

Чем может помочь NOWANI TECH

Мы помогаем компаниям превратить приблизительную идею в чёткий объём работ, первую рабочую версию и поэтапный план с критериями приёмки, прежде чем начнутся крупные расходы. Мы работаем короткими этапами и с первого дня планируем хостинг, сопровождение и поддержку, чтобы полная стоимость была видна заранее. Если вы готовите проект и хотите получить стороннее мнение об объёме работ или бюджете, свяжитесь с нами.