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

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

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

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

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

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

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

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

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

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

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

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

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

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