Один из первых вопросов, который слышат наши клиенты — How many users do you expect in your first month? How many are likely to use it simultaneously? (Да, мы много работаем с зарубежными стартапами: чаще всего спрашиваем по-английски).
Многие отвечают неохотно и неуверенно: в диапазоне от “а вам зачем” до “вы разработчики, вы лучше знаете”. Между тем, точный ответ может сэкономить клиенту деньги, и достаточно солидные. А иногда — и помочь заработать.
Можно ли сэкономить или даже заработать?
Поговорим о том, для чего это всё делается: о деньгах. Информация о количестве пользователей не только поможет вашей проектной команде, но и поможет сэкономить или преумножить средства. Как же?
Зная, сколько человек будет пользоваться платформой, мы сможем:
- рассчитать нужные серверные мощности: клиенту не придётся переплачивать за неиспользуемые ресурсы;
- выстроить архитектуру системы, которая будет масштабироваться
- оценить затраты на нагрузочное тестирование
- построить такой план разработки, который позволит проекту выйти на рынок (или представить пользователям новую версию) как можно быстрее.
Экономим, исключая ненужные сейчас траты и планируя внедрение новых функций.
Помогаем заработать, обеспечивая быстрый выход на рынок. И обеспечиваем уверенность в том, что платформа выполняет поставленные задачи.
Что именно мы спрашиваем?
В зависимости от специфики платформы, нам важно узнать:
- максимальное количество пользователей платформы в месяц;
- максимальное количество пользователей на платформе онлайн единовременно;
- что именно делают пользователи на платформе: например, выкладывают посты, совершают звонки, заходят в игру – сколько раз в день?
- предполагаемая динамика роста аудитории
А что, если я правда не знаю?
Если ваш проект уже живой, скорее всего, там есть аналитика. Google Analytics или его аналоги позволяют оценить количество пользователей быстро и точно.
Если нет — можно опираться на более технические данные: информацию из баз данных, статистику загрузки серверов или сводки из консоли облачного провайдера, и так далее.
Если вам нужна наша команда, чтобы создать проект с нуля, есть смысл взглянуть на статистику конкурентов, например, с помощью сервиса SimilarWeb. Если это по какой-то причине невозможно, опирайтесь на условное число в 1000 активных пользователей — опыт подсказывает, что в первые месяцы жизни продукта этого достаточно.
И, конечно, в обоих случаях стоит посоветоваться с нашими аналитиками — мы поможем собрать нужные данные и сделать выводы.
Это важно для всех проектов?
Да, для всех. Особенно это критично для систем, которые соответствуют как минимум одному из этих критериев:
- Большой входящий/исходящий трафик: пользователи загружают и скачивают HD-видео, проводят видеоконференции на 3+ пользователей,
- Есть требование обеспечить минимальные задержки: пользователи играют в онлайн-игру, репетируют на музыкальных инструментах по видеосвязи или микшируют DJ-сет,
- Приложение включает в себя долгие и ресурсоёмкие операции: сжатие, конвертация или обработка видео, архивация файлов, маршрутизация видео/аудиозвонков, обработка или генерация данных нейросетями.
Почему не сделать с расчётом на многотысячный и очень интенсивный онлайн сразу и для всех?
Во-первых, такая платформа попадёт в продакшен позже.
Если мы знаем, что первые месяцы ею будет пользоваться только небольшая аудитория (такую обычно называют early adopters), разумнее и выгоднее не откладывать запуск до момента, пока будут готовы и проверены под нагрузкой системы балансировки и масштабирования.
Во-вторых, чем больше расчетная нагрузка — тем дороже эксплуатация системы. Особенно, если она работает в облаках. Ориентироваться на большой онлайн – значит, не только уметь масштабироваться, но и иметь достаточный запас мощности здесь и сейчас, чтобы выдержать значительный наплыв пользователей в любой момент. То есть держать постоянно включенным не маленький дешевый, а большой и дорогой сервер.
В-третьих, не ко всем проектам такой расчёт вообще применим.
Для закрытых корпоративных платформ просто нет смысла разрабатывать продукт, рассчитанный на многотысячную армию пользователей.
Что с этими данными делает разработчик?
Разработчик поймет:
- какой сервер нужен: on-premise (физическое аппаратное обеспечение клиента), облачный (AWS, Hetzner, Google Cloud, AliCloud), или целая сеть серверов,
- можно ли и нужно ли перенести часть нагрузки на пользовательское устройство (клиент),
- какие из задач, связанных с оптимизацией и производительностью, необходимо реализовать сразу, а какие можно отложить на более поздние спринты.
Оффтопик: а чем отличается серверная нагрузка от клиентской?
Простой пример: допустим, мы делаем свой инстаграм. Пользователь снимает видео, добавляет несложные эффекты, выкладывает результат в свою ленту.
Если задача — быстро и экономно выйти к первой аудитории, пилотный билд может делать практически всё на сервере.
Плюсы:
- нет риска упереться в ограничения конкретных платформ: форматы видео, ограничения по нагрузке и прочие нюансы нас не волнуют. Всё обработается централизованно, поэтому можно быстро сделать продукт под все платформы и выпустить одновременно.
- нет жестких требований к клиентским устройствам: проще выходить на растущие рынки — такие как Африка, ЮВА, Латинская Америка. Справится даже супер бюджетный телефон, каких много в таких регионах.
- приложения нашего “неИнстаграма” для отдельных платформ, таких как веб и мобильные ОС получаются очень простыми. Авторизация, лента, кнопка загрузить, всё.
А если задача — сразу дать полную функциональность большой действующей аудитории, то тяжелые серверные расчёты теряют привлекательность: имеет смысл сразу задействовать мощность клиентских устройств.
Плюсы:
- меньше серверов и затрат на эксплуатацию при таком же количестве пользователей
- пользователь чувствует, что приложение более отзывчиво. К тому же, если клиентов уже много, а мы добавили новые сложные фичи, отзывчивость платформы не станет ниже.
- пользователям удобнее экспериментировать с новой функциональностью: она реализуется на клиенте, а значит задержки минимальны,
- в процессе обработки контента может не требоваться интернет - экономим трафик,
- загруженное видео публикуется быстрее: ему не нужно попадать в очередь на серверную обработку,
- чем проще и быстрее отдельные операции на сервере, тем проще и дешевле этот сервер масштабировать. Это особенно критично при резком наплыве новых пользователей
Компромиссный, но зачастую оптимальный вариант — тот, который не перекладывает всю нагрузку на одну из сторон. Например, задачи обработки видео, такие как наложение эффектов или графики, часто разумно выполнять на клиенте, а конвертацию мобильного видео в нужные форматы и разрешения — на сервере. И в этом случае распределение задач между клиентским устройством и сервером тоже зависит от планируемого охвата.
Что, если мы разрабатываем только компонент для живого проекта?
В случае расширения уже существующего продукта, необходимо узнать, где на данный момент обрабатываются задачи: на устройстве или на сервере.
Далее, исходя из назначения будущего компонента и прогноза количества пользователей и их деятельности на платформе после его появления, разработчик поймет, улучшать ли текущую архитектуру или мигрировать на более эффективную.
Так в итоге, зачем мы спрашиваем про количество пользователей?
Всё сводится к эффективности и экономии ресурсов и финансов: чем точнее мы знаем скоуп продукта по масштабу и по нагрузке, тем лучше сможем спланировать запуск, тем точнее сможем оптимизировать расходы, и тем надежнее будет система в долгосрочной перспективе.
Комментарии