Здравствуйте. Понимаем, что это может приносить неудобства. Устанавливать обновления автоматически технически возможно не на всех устройствах. С точки зрения производителя вашего телефона, RuStore — это сторонний источник, а не дефолтный стор. В таком случае для установки или обновления любого приложения нужно дополнительное подтверждение, это требование и стандарт системы Android
Привет, спасибо) Про приоритезацию в целом описала в статье, алгоритм простой: - если проблема высококритичная и находится в сценарии, на котором завязаны важные для продукта метрики, ее стараются забрать в работу чем раньше, тем лучше. И далее по убыванию. - Проблема крепится к существующей продуктовой задаче (в редких случаях как самостоятельная задача). Остальное уже в рамках работы над фичей по RICE.
То есть при таком подходе конфликтов практически не возникает. Мы знаем, что продукт знает о проблеме, и чем она ему потенциально "грозит", продукт - взвешивает и, исходя из своих ресурсов, решает в какой очередности что сможет взять. Не берут в работу скорее в случаях, когда поняли, что результаты исследования совсем грустные, и имеет смысл вообще отказаться от реализации.
Ситуации, когда есть сомнения в степени критичности проблемы - есть всегда у всех, мне кажется. Если проблема донесена корректно, но все-равно остались сомнения - а/б, количественная валидация или аналитика
Здравствуйте. Понимаем, что это может приносить неудобства. Устанавливать обновления автоматически технически возможно не на всех устройствах. С точки зрения производителя вашего телефона, RuStore — это сторонний источник, а не дефолтный стор. В таком случае для установки или обновления любого приложения нужно дополнительное подтверждение, это требование и стандарт системы Android
Привет, спасибо)
Про приоритезацию в целом описала в статье, алгоритм простой:
- если проблема высококритичная и находится в сценарии, на котором завязаны важные для продукта метрики, ее стараются забрать в работу чем раньше, тем лучше. И далее по убыванию.
- Проблема крепится к существующей продуктовой задаче (в редких случаях как самостоятельная задача). Остальное уже в рамках работы над фичей по RICE.
То есть при таком подходе конфликтов практически не возникает. Мы знаем, что продукт знает о проблеме, и чем она ему потенциально "грозит", продукт - взвешивает и, исходя из своих ресурсов, решает в какой очередности что сможет взять.
Не берут в работу скорее в случаях, когда поняли, что результаты исследования совсем грустные, и имеет смысл вообще отказаться от реализации.
Ситуации, когда есть сомнения в степени критичности проблемы - есть всегда у всех, мне кажется. Если проблема донесена корректно, но все-равно остались сомнения - а/б, количественная валидация или аналитика