5 часов мы обычно выделяем на большую трехкомнатную квартиру. Чтобы прийти к «стандарту» в 5 часов, мы сначала накопили данные о том, сколько в среднем занимает уборка трешки. Регулярная уборка должна постепенно снижать это время, потому что клинер учится наводить порядок именно так, как вам нужно, и со временем делает это быстрее.
Спасибо за годный комментарий.
На самом деле тут очень интересный опыт, который, возможно, достоин отдельного поста. В 2017 году мы очень экстенсивно развивались: запустили несколько городов, жгли кучу денег на маркетинг, скидки, акции, даже пробовали рекламу на ТВ. В какой-то момент мы заигрались и не сразу поняли, что результаты довольно грустные: да, у нас стабильно росла пользовательская база, мы регулярно отмечали рекорды по количеству уборок, но при этом падали когорты, средний чек и, вообще, всё что касалось юнит экономики. В итоге, в ноябре приняли решение что пока низкий сезон (в январе-марте традиционно меньше уборок) мы займёмся работой над ошибками: автоматизируем то что не было автоматизировано, оптимизируем операционку, настроим сегменты и поймём что кому можно предлагать. Сейчас мы опять вкладываемся в маркетинг, но теперь у нас гораздо больше опыта, знаний и понимания того чего мы хотим и как этого достигнуть. В итоге, оглядываясь назад, мы воспринимаем эту ошибку как очень дорогой, но ценный опыт.
Про микросервисы и выделенный сервер — тут я не вижу связи. Суммарная вычислительная мощность всей нашей системы небольшая и весь наш парк сервисов спокойно поместится на 3 сервера (третий для резервирования). Такое количество сервисов связано не с нагрузкой, а с логическим делением на какие-то небольшие независимые бизнес процессы: crm, найм исполнителей, аналитика, оплата/создание заказа и тд, плюс разделение на front и back.
На момент выбора эликсир не рассматривался как production-ready. Перфоманс тесты проводили, но по конкретному кейсу написать настолько подробно уже не сможем. Однако, в планах стоит написать подробную статью про переход с нативных приложений на react native: на что смотрели, как тестировали, как и почему делали выбор.
У нас в сутки выполняется 1000 заказов. Но нужно понимать, что хитов у нас гораздо больше. Суммарная медианная загрузка балансировщиков в районе 100rps. Да, половина из этого статика, но остальное — это заходы пользователей: работа с личным кабинетом, подпиской; различные акции, лендинги и тд. Перед нами стояла задача собирать аналитику по каждому действию пользователя как на сайте, так и в мобильном приложении и складывать это в нашу аналитическую базу. Мы взяли на клиентах решение на базе snowplow, допилили его под свои нужды, а в качестве бекенда написали простой сервис на Go, цель которого валидировать и обрабатывать поступающие данные и класть в базу в нужном формате. Ruby для этого по нашим тестам не подходил, поэтому выбрали go. Нагрузка тут не при чём, просто под конкретную задачу выбрали конкретный инструмент.
Вы действительно считаете, что 2 пары в неделю в течение одного семестра достаточно для курса «Веб-проектирование и веб-технологии»? RoR, C#, PHP и тд? сузьте область, непонятно же =)
На самом деле тут очень интересный опыт, который, возможно, достоин отдельного поста. В 2017 году мы очень экстенсивно развивались: запустили несколько городов, жгли кучу денег на маркетинг, скидки, акции, даже пробовали рекламу на ТВ. В какой-то момент мы заигрались и не сразу поняли, что результаты довольно грустные: да, у нас стабильно росла пользовательская база, мы регулярно отмечали рекорды по количеству уборок, но при этом падали когорты, средний чек и, вообще, всё что касалось юнит экономики. В итоге, в ноябре приняли решение что пока низкий сезон (в январе-марте традиционно меньше уборок) мы займёмся работой над ошибками: автоматизируем то что не было автоматизировано, оптимизируем операционку, настроим сегменты и поймём что кому можно предлагать. Сейчас мы опять вкладываемся в маркетинг, но теперь у нас гораздо больше опыта, знаний и понимания того чего мы хотим и как этого достигнуть. В итоге, оглядываясь назад, мы воспринимаем эту ошибку как очень дорогой, но ценный опыт.
Про микросервисы и выделенный сервер — тут я не вижу связи. Суммарная вычислительная мощность всей нашей системы небольшая и весь наш парк сервисов спокойно поместится на 3 сервера (третий для резервирования). Такое количество сервисов связано не с нагрузкой, а с логическим делением на какие-то небольшие независимые бизнес процессы: crm, найм исполнителей, аналитика, оплата/создание заказа и тд, плюс разделение на front и back.