Снижение стоимости владения IT продуктом

Для кого-то может быть новостью, но зачастую разработка продукта составляет только небольшую часть будущих затрат на развитие и сопровождение проекта. Начальная версия проекта может стоить, например, 200 тысяч рублей, но за 2 года затраты на развитие проекта в техническом плане могут перевалить за 1 млн. руб. Почему так происходит? Как можно это предусмотреть в самом начале проекта?

Давайте ответим вопросы о стоимости владения сайтом.

Основные статьи расходов на содержание проекта

Домен

Для обычного, не премиум домена это совсем мелкие расходы, не более 1000 рублей в месяц. Даже не рассматриваем в качестве статьи расходов.

Хостинг

Это может быть обычный хостинг либо аренда сервера. Хостинг может занимать от 150 рублей в месяц. Аренда сервера сильно дороже - от 1000 рублей в месяц. В целом это тоже малые расходы для серьезного IT проекта.

Интеграции

Поддержание актуальности данных и синхронизация данных по АПИ. Это далеко не для всех систем актуально, и является очень специфичным вопросом. Как минимум нужно делать эти интеграции, и во-вторых, необходимо решать возникающие проблемы стыковки по 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.

Итак, преобразования, которые снизили стоимость услуг

1. Очень узкий стек с сохранением гибкости системы. Все управление бизнес-логикой и частично выводом данных - через SQL.
2. Закрыты все типовые потребности в компонентах (ключевой момент - без ограничения по гибкости бизнес-логики).
3. Возможность быстрых правок. Разработка идет по-живому, поставка новых возможностей происходит прямо из кабинета администратора-разработчика (альтернативно можно делать все на отдельном тестовом экземпляре БД).
4. На проекте требуется меньше людей, чем на аналогичном проекте разработки по полному стеку. Меньше людей - меньше согласования, недопонимания и координации действий участников проекта.
5. Скрытие сложностей и нюансов веб от разработчика. Его задача - правильно написать SQL, а все остальное система сделает за него. При этом остается возможность "подлезть" и написать кастомную логику на JS или сделать свою верстку.
6. Проще копить кодовую базу. Из-за стандартного подхода к разработке стало гораздо проще делать типовые решения и добавлять их по необходимости в проект: Faq, Финансы, Статьи, Задачи и др стандартные блоки.

Идеальный вариант, когда вы сами базово владеете SQL.

В этом случае вы можете самостоятельно делать некоторые простые вещи, не ожидая, когда освободится программист. Скорость подобного подхода будет очень высокой - не нужно никому объяснять бизнес-логику, не нужно ждать исправления простых помарок. Вы можете сразу, в процессе работы, поправить нужные моменты и проверить сразу, как это работает. Правка с проверкой может занять 5 минут, а не 2-3 дня в случае работы с разработчиком.

Заключение

Главный тезис данной статьи - учитывайте не только начальную стоимость создания своего решения, но и последующие затраты на его развитие, которые будут в любом случае, если ваш проект будет пользоваться спросом.

Постарайтесь максимально детально понять свои возможные затраты в процессе сопровождения проекта. Это избавит вас от незапланированного перерасхода по бюджету на поздних стадиях проекта.

Автор статьи - Руслан Раянов

Cоздатель платформы Falcon Space

Платформа Falcon Space

Это снижение стоимости владения

за счет меньшего количества людей для поддержки

Это быстрое внесение изменений

по ходу эксплуатации программы

Это современный интерфейс

полная адаптация под мобильные устройства

Демо-стенд компонентов
На стенде можно посмотреть различные компоненты в действии: таблицы, формы, модальные окна, диаграммы, карта и т.д.
Демо-сайт решений
Базисные решения, которые можно гибко адаптировать под себя: менять внешний вид, бизнес-логику и даже структуру базы данных.
Обсудить проект
Задайте начальные вопросы по проекту, которые вас сейчас волнуют. Мы бесплатно проконсультируем вас и порекумендуем лучшее решение.

If you like our articles, then please subscribe to our channel in Telegram - Falcon Space.
In it we will publish updates on articles and other materials regarding our platform.