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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тематические статьи

Как зависит качество разработанного сайта от количества выделенных ресурсов и менеджмента проекта?

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

экономика
веб-разработка
управление проектами
управление продуктами
Статья опубликована в 2014 году

Влияние добавление функционала на проекты по разработке программного обеспечения

Добавление функций в программный продукт всегда вызывает дополнительные изменения в проекте, а эти изменения не всегда очевидны. Влияние расширения функционала на различные аспекты разработки зависит и от того, когда изменения поступили, и от того, каков их объём, и от их связанности с другими функциями программного продукта.

веб-разработка
управление продуктами
управление проектами
методологии разработки
Статья опубликована в 2014 году

​Создание сайта быстро, дешево, индивидуально и качественно

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».

экономика
веб-разработка
управление продуктами
управление проектами
Статья опубликована в 2014 году

Сколько стоит разработка сайта?

​Ежедневно мы отвечаем на этот вопрос и не один раз. Очень часто это первый вопрос позвонившего Клиента. Мы понимаем, что Клиенты устали слушать, что всё зависит от сложности разработки этого самого сайта.

экономика
управление проектами
Статья опубликована в 2014 году

О гарантиях в сфере услуг, связанных с разработкой и продвижением сайтов

Гарантии в IT‑услугах встречаются не так уж и редко: это и SLA в поддержке, и гарантии трафика или позиций в продвижении, и гарантии качества в разработке. Но тем не менее, понимаются эти гарантии не всегда правильно.

управление проектами
SEO
интернет-маркетинг
Статья опубликована в 2014 году

Иллюзорные гарантии в разработке и продвижении сайтов

​Давайте рассмотрим «иллюзорные» гарантии, которые вроде как присутствуют в том или ином виде, но на самом деле их нет.

управление проектами
SEO
интернет-маркетинг
Статья опубликована в 2014 году

Мотивация через гарантийные обязательства

Заказчик, получая гарантийные обязательства, в какой‑то мере мотивирует Исполнителя на качественное исполнение взятых на себя обязательств. Однако тут есть подводные камни, о которых стоит знать.

управление проектами
SEO
интернет-маркетинг
Статья опубликована в 2014 году

Сколько стоят настоящие гарантии в продвижении и разработке сайтов

​Гарантии, подкреплённые реальными обязательствами Подрядчика, всегда заложены в цену услуги (или товара). Это бизнес, иначе не бывает.

управление проектами
SEO
интернет-маркетинг
Статья опубликована в 2014 году

Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска

То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.

управление продуктами
управление проектами
Статья опубликована в 2014 году

Как расчитывается стоимость часа работы специалиста

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

экономика
веб-разработка
управление проектами
Статья опубликована в 2014 и обновлена в 2022 году

Как написать функциональное техническое задание?

Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.

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

управление продуктами
управление проектами
проектирование
Статья опубликована в 2019 и обновлена в 2020 году