Почему мы уточняем у клиентов, сколько человек использует платформу?

Один из первых вопросов, который слышат наши клиенты — How many users do you expect in your first month? How many are likely to use it simultaneously? (Да, мы много работаем с зарубежными стартапами: чаще всего спрашиваем по-английски).

Многие отвечают неохотно и неуверенно — от «а вам зачем» до «вы разработчики, вы лучше знаете». Между тем, точный ответ может сэкономить клиенту деньги — и иногда довольно серьёзные. А иногда — и помочь заработать.

Можно ли сэкономить или даже заработать?

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

• рассчитать нужные серверные мощности: клиенту не придётся переплачивать за неиспользуемые ресурсы;
• выстроить архитектуру системы, способной масштабироваться
• оценить затраты на нагрузочное тестирование
• построить такой план разработки, который позволит проекту выйти на рынок (или представить пользователям новую версию) как можно быстрее.

Экономим, исключая ненужные траты и планируя внедрение новых функций.

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

Что именно мы спрашиваем?

В зависимости от особенностей платформы, нам важно выяснить:

• максимальное количество пользователей платформы в месяц;
• максимальное количество пользователей на платформе онлайн одновременно;
• что именно делают пользователи на платформе: например, выкладывают посты, звонят, играют — сколько раз в день?
• предполагаемая динамика роста аудитории

А что, если я действительно не знаю?

Если ваш проект уже работает, скорее всего, в нём настроена аналитика. Google Analytics или его аналоги помогут быстро и точно оценить количество пользователей.
Если аналитика не настроена — можно использовать более технические данные: информацию из баз данных, статистику нагрузки на сервер или отчёты из консоли облачного провайдера и так далее.

Если вам нужна наша команда, чтобы создать проект с нуля, стоит посмотреть статистику конкурентов — например, с помощью сервиса SimilarWeb. Если по каким-то причинам это невозможно, можно ориентироваться на условную цифру в 1000 активных пользователей. Опыт показывает, что в первые месяцы жизни продукта этого вполне достаточно.

И, конечно, в обоих случаях стоит проконсультироваться с нашими аналитиками — они помогут собрать нужные данные и сделать выводы.

Это важно для всех проектов?

Да, для всех. Особенно это важно для систем, которые соответствуют хотя бы одному из этих критериев:

• Большой входящий/исходящий трафик: пользователи загружают и скачивают HD-видео, проводят видеоконференции с тремя и более участниками,
• Есть требование обеспечить минимальные задержки: пользователи играют в онлайн-игры, репетируют на музыкальных инструментах по видеосвязи или микшируют DJ-сеты,
• Приложение выполняет длительные и ресурсоёмкие операции: сжатие, конвертацию или обработку видео, архивацию файлов, маршрутизацию видео- и аудиозвонков, обработку или генерацию данных нейросетями.

Почему сразу не сделать расчёт на многотысячный и очень интенсивный онлайн для всех?

Во-первых, такая платформа выйдет в продакшен позже.

Если мы знаем, что первые месяцы сервисом будет пользоваться небольшая аудитория (такую группу обычно называют early adopters), разумнее и выгоднее не откладывать запуск до тех пор, пока не будут готовы и протестированы под нагрузкой системы балансировки и масштабирования.

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

В-третьих, такой расчёт не подходит для всех проектов.

Для закрытых корпоративных платформ нет смысла создавать продукт, рассчитанный на многотысячную аудиторию.

Что с этими данными делает разработчик?

Разработчик поймёт:

• какой сервер нужен: on-premise (физическое оборудование клиента), облачный (AWS, Hetzner, Google Cloud, AliCloud) или целая сеть серверов,
• можно ли и нужно ли перенести часть нагрузки на устройство пользователя (клиент),
• какие из задач, связанных с оптимизацией и производительностью, нужно реализовать сразу, а какие можно отложить на более поздние спринты.

Оффтопик: а чем отличается серверная нагрузка от клиентской?

Простой пример: допустим, мы делаем свой инстаграм. Пользователь снимает видео, добавляет простые эффекты и выкладывает результат в свою ленту.

Если цель — быстро и недорого выйти на первую аудиторию, пилотный билд может выполнять почти всё на сервере.

Плюсы:

• нет риска упереться в ограничения конкретных платформ: форматы видео, ограничения по нагрузке и прочие нюансы нас не волнуют. Всё обработается централизованно, поэтому можно быстро сделать продукт под все платформы и выпустить одновременно.
• нет жестких требований к клиентским устройствам: проще выходить на растущие рынки — такие как Африка, ЮВА, Латинская Америка. Справится даже самый дешёвый телефон, которых в этих регионах много.
• приложения нашего “неИнстаграма” для отдельных платформ, таких как веб и мобильные ОС, получаются очень простыми. Авторизация, лента, кнопка «загрузить» — и всё.

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

Плюсы:

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

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

А что, если мы разрабатываем компонент только для живого проекта?

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

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

Так в итоге, зачем мы спрашиваем про количество пользователей?

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