Использование экономических критериев в веб‑разработке для оценки целесообразности реализации

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

Цена избыточных функциональных возможностей

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

Еще один аспект «платы за широкие возможности» — это баги (ошибки и сбои), чем больше и сложнее продукт, чем активнее внедряются в него новые функции, тем больше вероятность, что в нём будут ошибки. Если привести аналогию, то «вычитать» литературный текст объёмом в один лист A4 можно достаточно быстро и ошибок там избежать просто, а вот с многостраничным документом уже часто возникают сложности. В разработке ПО всё усложняется тем, что компонентов в разрабатываемых продуктах достаточно много и они тесно взаимосвязаны — два вполне корректно работающих по отдельности компонента, например, могут при сочетании приводить к сбоям, а добавление чего‑либо в одном месте — ошибки в другом. В какой‑то мере этих проблем можно избежать при использовании автоматического тестирования и методологии TDD, но это тоже не панацея.

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

Цена отказоустойчивости

Система, которая работает на одном выделенном сервере в нормальном дата‑центре, в реальности не является отказоустойчивой. Однако средняя её доступность обычно не ниже 99,8%. Кластер нужен в том случае, если прирост в 0,2% доступности реально окупит вложения в разработку и в сопровождение, а также в аренду или покупку оборудования. Кластерное решение обычно дороже в разработке и поддержке на 10-20%, а затраты на оборудование при разворачивании отказоустойчивого кластера удваиваются (как минимум).

Таким образом, движение в сторону отказоустойчивости имеет смысл, если исключаемые на простое потери позволяют финансировать разработку и поддержку более «навороченного» решения. Честно говоря, таких веб‑проектов не так уж и много и большая часть коммерческих сайтов к ним не относится.

Цена поддержки 24/7

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

Даже простая поддержка 24/7 обычно существенно дороже поддержки только в рабочее время. Простая поддержка — это приём обращений и выполнение неспецифических операций (например, перезапуск служб на сервере). А вот круглосуточный саппорт, который в состоянии решать специфические проблемы проекта, стоит в несколько раз дороже, так как требует выделенных под проект специалистов.

В случае «простой» поддержки или поддержки коробочных решений на собственной инфраструктуре Подрядчик для сопровождаемых проектов выделяет некую команду. И чем больше клиентов, тем меньше затраты на каждого клиента в отдельности (поддержка, связанная с работоспособностью, не требует «производственных мощностей», а просто своевременной доступности специалистов). По сути, если клиентов 100, то каждый из них оплачивает 1% от стоимости такого отдела.

В случае «продвинутой» поддержки индивидуальных решений Подрядчик формирует отдел «под клиента», а Заказчик оплачивает если не полную стоимость этого отдела, то значительную её часть. Специалисты поддержки получают оплату не за выполнение заявок, а за фактическое присутствие на рабочем месте, то есть себестоимость такого отдела достаточно постоянная и она должна компенсироваться за счёт поступлений денег от Заказчика ради которого этот отдел был сформирован. Технически можно такой отдел «разделить» между 3-4 проектами, но обеспечить высокую осведомленность специалистов по большему числу проектов на практике нереально.