Сколько стоит содержать сайт? Как снизить стоимость владения IT продуктом
Начальная версия проекта может стоить, например, 200 тысяч рублей, но за 2 года затраты на развитие проекта в техническом плане могут перевалить за 1 млн. руб. Почему так происходит? Как можно это предусмотреть в самом начале проекта будущие затраты на развитие и сопровождение проекта? Читайте ответы на эти вопросы.
Для кого-то может быть новостью, но зачастую затраты на разработку сайта составляют только небольшую часть будущих затрат на развитие и сопровождение проекта.
Давайте ответим на вопрос сколько составят затраты на сайт.
Основные статьи расходов на владение сайтом
Домен сайта. Для обычного, не премиум домена это совсем мелкие расходы, не более 1000 рублей в год. Даже не рассматриваем в качестве статьи расходов.
Хостинг сайта. Это может быть обычный хостинг либо аренда сервера. Хостинг может занимать от 150 рублей в месяц. Аренда сервера сильно дороже — от 1000 рублей в месяц. В целом, это тоже малые расходы для серьезного IT проекта.
Интеграции с внешними системами. Поддержание актуальности данных и синхронизация данных по API. Это далеко не для всех систем актуально, и является очень специфичным вопросом.
Как минимум нужно делать эти интеграции, и во-вторых, необходимо решать возникающие проблемы стыковки по API. А это затраты на разработчиков, сопровождающих этот API.
Развитие системы. Появляются новые идеи, новые требования к системе. Может расти нагрузка, возникают проблемы производительности системы. Все это необходимо обслуживать. По сути любой рабочий проект должен развиваться и успевать за изменениями текущими реалиями бизнеса.
Если система будет медленно реагировать на изменения бизнес-среды, то часть процессов будет просто проходить мимо нее. Это основная часть расходов, и здесь может быть зарыто до 90% (конечно, если не считать маркетинг и продвижение сайта в сети).
Операционная деятельность сайта. Это затраты на персонал сайта — модерация, обработка запросов пользователей. Это относительно небольшие затраты, и самое главное — они прогнозируемые.
Внешние сервисы. Если сайт использует некие платные сервисы, то это также статья расходов для владельцев сайта.
Маркетинг и трафик. Для работающего функционального сайта 2 главные статьи — это программисты и маркетинг. В идеале все 100% тратить бы именно на привлечение трафика. Т.е. это создание контента, рекламный бюджет, поисковая оптимизация, веб-аналитика, социальные сети и другие каналы продвижения.
Бюджет маркетинга очень сильно зависит от стратегии и возможностей проекта. В целом можно делать маркетинг и без бюджета. Например, мы практически не тратим на маркетинг. Весь наш маркетинг — это создание контента в виде статей и видео, а также ретаргетинг через контекстную рекламу.
Затраты на исполнителей. С программистами (или другим персоналом для развития продукта — дизайнеры, верстальщики и др.) все сложнее. Очень много зависит от выбранного способа создания сайта.
Если это чисто заказная разработка, то любое изменение проходит полный стек разработки, и это очень дорого. Даже добавить 1 раздел на 2–3 страницы в панель управления — это уже десятки тысяч рублей. И это объективная цена, а не желание легких денег со стороны разработчиков, просто для этих задач нужно подключать сразу несколько специализаций — бекенд программист, бизнес-аналитик, фронтенд программист, верстальщик, дизайнер, тестировщик.
Еще хуже дела обстоят с готовыми продуктами. В них поменять даже самые простые вещи может занять весь день. Продукт быстро ставится в начальной конфигурации, но очень проблематично его развивать, если такая возможность вообще есть.
Очень важно, чтобы систему можно было менять, и чтобы для этого не нужно было привлекать целую бригаду людей.
Решение проблемы в Falcon Space
В Falcon Space мы снизили стоимость владения за счет объединения ролей людей и убрали часть сложности разработки в использование типовых вещей.
1. Нет backend и frontend программиста. Вся логика пишется на SQL. Слоя логики на PHP или C# просто нет. Все управляется через SQL и выводится через Front end компоненты.
2. Нет верстальщика. В системе для компонентов выводится по умолчанию нормальная верстка + при желании можно поменять эту верстку на свою за отдельную плату.
3. Для реализации API не требуется отдельный программист. Все это может делать тот же человек, который знает SQL.
Вся система заточена на такого человека-оркестра, который знает SQL и чуть Bootstrap (для кастомной верстки — без нее никуда). При этом платформа скрывает от него внутренние сложности по рендерингу таблиц, форм и других компонентов.
Дополнительным плюсом является меньшее количество точек, где можно допустить ошибку. Разработчик написал нужный sql, у него что-то не работает. Ошибка с вероятностью 99% в SQL, который он написал. Таким образом, можно очень быстро создавать решения.
4. Быстрый перенос решений, накопление кодовой базы. Следующим моментом, снижающим стоимость, является возможность быстрых трансферов решений. Ведь любое решение — это по факту большой файл с SQL кодом, который можно портировать в другую базу. К примеру, механизм базы знаний с нашего сайта можно портировать на другое решение за 1 час (перенести таблицы и компоненты через механизм генерации SQL).
Все новые возможности в платформе делаются с учетом того, что все управление будет идти через SQL.
К примеру, бот телеграм работает через одну хранимую процедуру, которая обрабатывает все входящие команды бота. Такой подход позволяет сохранять узким стек специалиста (SQL, Bootstrap), что упрощает поиск специалистов в дальнейшем, а также ускоряет их обучение для включения в процесс разработки.
Конечно в системе остается возможность делать кастомные вещи: внедрять свои лендинги, писать свои JS компоненты с обращением к серверу через AJAX запросы. Если бы этого не было, то платформа имела бы критические ограничения, что для универсального продукта было бы недопустимо. Но для 95% потребностей хватает стандартного функционала, управляемого через SQL. Таким образом, 1–2 человека на проекте, знающих SQL, могут очень быстро внедрять новые возможности в проект.
Считаю крайне важным моментом возможность быстрых правок бизнес-логики.
Если любое малейшее изменение требует запуска сложного механизма обновления, то неизбежно возникают большие задержки по времени, особенно когда задействовано сразу много людей для выполнения обновления. Чем меньше людей, и чем меньше требуется действий для внесения правки в бизнес-логику, тем быстрее и дешевле будет делать множественные правки по проекту.
Если брать наш кейс, то создание типовых вещей стало выполняться в 4–5 раз быстрее по сравнению с прежним способом разработки на полном стеке. Если раньше некую управляющую таблицу мы делали за 4–5 часов (на полном стеке), то сейчас ее можно собрать за 1 час, при этом сопровождать ее в будущем проще, т.к. 95% правок — это изменение SQL.
Итак, преобразования, которые повлияли на снижение стоимости услуг:
Очень узкий стек с сохранением гибкости системы. Все управление бизнес-логикой и частично выводом данных выполняется через SQL.
Закрыты все типовые потребности в компонентах (ключевой момент — без ограничения по гибкости бизнес-логики).
Возможность быстрых правок. Разработка идет по-живому, поставка новых возможностей происходит прямо из кабинета администратора-разработчика (альтернативно можно делать все на отдельном тестовом экземпляре БД).
На проекте требуется меньше людей, чем на аналогичном проекте разработки по полному стеку. Меньше людей — меньше согласования, недопонимания и координации действий участников проекта.
Скрытие сложностей и нюансов веб от Falcon-разработчика. Его задача — правильно написать SQL, а все остальное система сделает за него. При этом остается возможность «подлезть» и написать кастомную логику на JS или сделать свою верстку и стили.
Проще копить кодовую базу. Из-за стандартного подхода к разработке стало гораздо проще делать типовые решения и добавлять их по необходимости в проект: Faq, Финансы, Статьи, Задачи и другие стандартные блоки.
Идеальный вариант, когда вы сами базово владеете SQL. В этом случае вы можете самостоятельно делать некоторые простые вещи, не ожидая, когда освободится программист. Скорость подобного подхода будет очень высокой — не нужно никому объяснять бизнес-логику, не нужно ждать исправления простых помарок. Вы можете сразу, в процессе работы, поправить нужные моменты и проверить сразу, как это работает. Правка с проверкой может занять 5 минут, а не 2–3 дня в случае работы с разработчиком.
Заключение
Главный тезис данной статьи — учитывайте не только затраты на разработку сайта, но и последующие затраты на его развитие, которые будут в любом случае, если ваш проект будет пользоваться спросом.
Постарайтесь максимально детально понять свои возможные затраты в процессе сопровождения проекта. Это избавит вас от незапланированного перерасхода по бюджету на поздних стадиях проекта.
Просто о сложном
Неделя рекламы 
Новости 
Кейсы 
How to 
Интервью и дискуссии 
Маркетинговые исследования 
Проверено ADPASS 
Рекламные кампании 
