В этой статье будут затронуты некоторые особенности разработки и поддержки ПО, которые основываются на экономических критериях оценки целесообразности.
При разработке ПО важно понимать, что любая возможность программного продукта стоит денег как для её разработки и внедрения, так и для последующего сопровождения. Чем больше функциональных возможностей закладывается в продукт, тем он будет дороже и в создании, и в дальнейшем сопровождении. Поэтому при разработке сайтов, веб‑приложений и сервисов стоит задумываться о необходимости реализации тех или иных функций с коммерческой точки зрения.
Еще один аспект «платы за широкие возможности» — это баги (ошибки и сбои): чем больше и сложнее продукт, чем активнее внедряются в него новые функции, тем больше вероятность, что в нём будут ошибки. Если привести аналогию, то «вычитать» литературный текст объёмом в один лист A4 можно достаточно быстро и ошибок там избежать просто, а вот с многостраничным документом с перекрёстными ссылками уже часто возникают сложности. В разработке ПО всё усложняется тем, что компонентов в разрабатываемых продуктах достаточно много и они тесно взаимосвязаны — два вполне корректно работающих по отдельности компонента вполне могут при совместной работе приводить к сбоям, а добавление чего‑либо в одном месте — вызывать ошибки в другом. В какой‑то мере этих проблем можно избежать при использовании автоматического тестирования и методологии TDD, но и это тоже не панацея — тесты снижают риски, но не исключают проблемы на 100%.
Как правило, подавляющее большинство «дополнительных» функций программных продуктов неэффективны с коммерческой точки зрения — затраты на них существенные, а вот финансовой выгоды они не приносят.
Система, которая работает на одном выделенном сервере в нормальном дата‑центре, в реальности не является отказоустойчивой. Однако средняя её доступность обычно не ниже 99,9%. Кластер нужен в том случае, если прирост в 0,05-0,09% доступности реально окупит вложения в разработку и в сопровождение, а также в аренду или покупку оборудования. Кластерное решение обычно дороже в разработке и поддержке как минимум на 20-30%, а затраты на оборудование при разворачивании отказоустойчивого кластера удваиваются (опять же, это как минимум).
Таким образом, движение в сторону отказоустойчивости имеет смысл, если исключаемые на простое потери позволяют финансировать разработку и поддержку более «навороченного» решения. Честно говоря, таких веб‑проектов не так уж и много и большая часть коммерческих сайтов к ним не относится.
Ситуация схожая с отказоустойчивостью. Имеет смысл организовывать такого рода саппорт только в том случае, если срок реакции на обращения крайне критичен с точки зрения бизнеса, например, если сопровождается бизнес‑система, пользователи которой работают в нескольких часовых поясах и есть существенные коммерческие или репутационные риски из‑за вызванного сбоем простоя сервиса (которые, как правило, если и случаются, то в ночное время, да и происходит это достаточно редко).
Даже простая поддержка 24/7 обычно существенно дороже поддержки только в рабочее время. Простая поддержка — это приём обращений и выполнение неспецифических операций, например, перезапуск служб на сервере. А вот круглосуточный саппорт, который в состоянии решать в том числе и специфические проблемы проекта, стоит в несколько раз дороже, так как требует выделенных под проект разработчиков достаточно высокой квалификации.
В случае «простой» поддержки или поддержки коробочных решений на собственной инфраструктуре подрядчик для сопровождаемых проектов выделяет некую команду. И чем больше клиентов, тем меньше затраты на каждого клиента в отдельности, также поддержка, связанная с работоспособностью, не требует «производственных мощностей», а просто своевременной доступности специалистов. По сути, если клиентов 100, то каждый из них оплачивает 1% от стоимости такого отдела.
В случае «продвинутой» поддержки индивидуальных решений подрядчик формирует отдел «под клиента», а заказчик оплачивает если не полную стоимость этого отдела, то значительную её часть. Специалисты поддержки получают оплату не за выполнение заявок, а за фактическое присутствие на рабочем месте, то есть себестоимость такого отдела достаточно постоянная и она должна компенсироваться за счёт поступлений денег от заказчика ради которого этот отдел был сформирован. Технически можно такой отдел «разделить» между 3-4 проектами, но обеспечить высокую осведомленность специалистов по большему числу проектов на практике нереально.
Тематические статьи
Самый простой ответ на этот вопрос: прямо пропорционально. На разработку действительно хорошего проекта требуется много времени и денег, а плохой проект можно и «на коленке» за пару часов собрать. При профессиональном менеджменте результат проекта гарантированно лучше, чем в случае, когда менеджмента нет или он неэффективный. Но есть нюансы и влияние этих факторов достаточно нелинейно.
Добавление функций в программный продукт всегда вызывает дополнительные изменения в проекте, а эти изменения не всегда очевидны. Влияние расширения списка функциональных возможностей на различные аспекты разработки зависит и от того, когда изменения поступили, и от того, каков их объём, и от их связанности с другими функциями программного продукта.
Большинство компаний, занимающихся созданием сайтов и веб‑приложений, оценивают свою работу на основе цены человеко/часа или нормочаса. В этой статье приводится схема расчета стоимости часа работы специалиста и объясняется логика ценообразования.
То, что сайт разработан и запущен, еще не означает, что можно больше ничего не делать и продажи резко пойдут вверх. Впереди еще много работы.
Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями. Сценарий лучше всего описывать в по схеме: [роль пользователя] может [действие], [описание целей пользователя, а также необходимых шагов и вариантов развития событий]. Оптимально — разбивать описание больших компонентов на маленькие составляющие.