AST-анализатор. Он просканировал код продуктов и собрал статистику реального использования List-item
Помимо статистики использования разработчиками важна статистика использования пользователями в фактически протекающих в системе сценариях. Потому как, например, тестировщиков или продактов интересует/должно интересовать именно это. И может так оказаться, что распределение окажется совсем другим, нежели в кодовой базе. Частотные комбинации-сочетания нужно вылизывать и помещать ListItem, а все прочие вынести в отдельный компонент, условно RareBeastItem.
Хоть один адекватный коммент. Для того, что бы провести техническое интервью, у интервьювера опыт/скиллы должны быть больше (в идеале, кратно больше), чем у интервьюируемого. Тогда и собеседование длится 20 минут, вместо двух часов или N этапов. А если этих опыта и скиллов нет — начинается соревнование снаряда и брони.
если у нас есть предположение о том, что пользователи по-разному реагируют на наше воздействие ... смотреть на тот же ATE, но уже в разрезе конкретной группы (например, только среди мужчин или только среди женщин)
Спасибо за ответ, еще вопрос. Есть ли какие-либо общеупотребительные механики/техники/способы/инструменты для построения таких предположений? Сложилось впечатление, что стратификация/когортирование выполняется «пальцем в небо» в режиме «мы так чувствуем» (ну то есть точно так же, как и продакты продуктовые гипотезы ваяют). Мужчины и женщины — это в контексте поведения не более чем ярлыки. Более того, утром я веду себя одним образом, а вечером после рабочего дня совершенно другим, хотя мой ID и пол не особо поменялся =)
Эксперимент — эталонный подход к подобным задачам: мы случайно делим пользователей на группы, меняем только D и смотрим, как «сдвинулся» Y. Например, части пользователей даем промо, а части — нет, и сравниваем ARPU в обеих группах. Так, мы почти полностью защищаемся от большей части возможных смещений.
А что делать, если в той части, где промо было, 50% пользователей этой части отреагировали положительно, а вторые 50% отрицательно, т.е. суммарное влияние на метрику дало нулевой эффект?
Метрика «заработать 10 млн. (Revenue)» не может быть рутовой, потому что в этом случае проще всего ограбить банк. А если имеют значение другие метрики, такие как законность деятельности, то какую тогда считать рутовой?
А зачем двигатели и прочую нутрянку за пределами прочного корпуса заливать эпоксидкой? Можно же маслом. И давление держать будет, и от коррозии защитит. По крайней мере, так делают в Институте Проблем Морских Технологий, что в Приморском крае.
Чего-то развели кучу жалоб на сервис, в то время как статья не об этом. А о создании кастомного программно-аппаратного комплекса, о выборе готовых компонентов, о прототипировании, о композиции различных технологий, просто о решении интересной задачи, наконец. Читать интересно.
Вот набросились-то… То, что роботы «случайно» не убегают, это очевидно. То, что это очень годный инфоповод для пиара — теперь тоже очевидно. Разработчики и маркетологи молодцы. А что касается Амура и Тимура, то эта парочка принесла сафари-парку 10-кратное увеличение посещаемости. И да, это лучший зоопарк Приморья с точки зрения организации процессов. В частности, местные постоянно туда приносят всякое сбитое на дорогах/охотниками зверье (особенно много птиц). Не каждый «обман» стоит принимать на свой счет.
Полагаю, что большая часть приложений, как и в моем случае, была зарегистрирована в последний момент, ибо разработчику всегда не хватает всего нескольких дней ) И я хочу выразить признательность организаторам и сертификационной команде. Они действительно помогали в работе, несмотря на очевидные косяки с моей стороны (а отправить все в последний день, невнимательно читать условия, наспех выгружать бинарник в магазин – это косяки). Для себя я сделал несколько выводов (которые сейчас, разумеется, выглядят очевидными):
1) Никаких «финальных правок» перед релизом, особенно, если код не покрыт тестами. Лучшее – враг хорошего: маааленький костыль, исправляющий такой же маленький дефект, сломал весьма критичную часть функциональности. И ушел в релиз. Разумеется, все было исправлено в следующем апдейте, но… поезд тоже уже ушел.
2) Разработчик должен сам пользоваться своим продуктом. Да, это не всегда удается, но в сфере мобильной разработки (особенно узконишевой) это сильно проще. Когда пользуешься продуктом сам, то точно знаешь, где его сильные и слабые стороны, отпадает необходимость в разнообразных фокус-группах и т.п. Я сам бегаю со StepPlayer, и мне очень нравится, что получилось.
3) Стучи, и откроют. С вероятностью, всегда превышающую вероятность успеха при «обидеться и уйти без шапки в ночь холодную». При этом очень помогает вера в свой продукт, а для этого важен пункт 2.
Приложение таки успело вовремя пройти в Samsung GALAXY Apps и принять участие в конкурсе. Хочу выразить признательность команде сертификации магазина и организаторам конкурса за проделанную работу!
Помимо статистики использования разработчиками важна статистика использования пользователями в фактически протекающих в системе сценариях. Потому как, например, тестировщиков или продактов интересует/должно интересовать именно это. И может так оказаться, что распределение окажется совсем другим, нежели в кодовой базе. Частотные комбинации-сочетания нужно вылизывать и помещать ListItem, а все прочие вынести в отдельный компонент, условно RareBeastItem.
Хоть один адекватный коммент. Для того, что бы провести техническое интервью, у интервьювера опыт/скиллы должны быть больше (в идеале, кратно больше), чем у интервьюируемого. Тогда и собеседование длится 20 минут, вместо двух часов или N этапов. А если этих опыта и скиллов нет — начинается соревнование снаряда и брони.
Спасибо за ответ, еще вопрос. Есть ли какие-либо общеупотребительные механики/техники/способы/инструменты для построения таких предположений? Сложилось впечатление, что стратификация/когортирование выполняется «пальцем в небо» в режиме «мы так чувствуем» (ну то есть точно так же, как и продакты продуктовые гипотезы ваяют). Мужчины и женщины — это в контексте поведения не более чем ярлыки. Более того, утром я веду себя одним образом, а вечером после рабочего дня совершенно другим, хотя мой ID и пол не особо поменялся =)
А что делать, если в той части, где промо было, 50% пользователей этой части отреагировали положительно, а вторые 50% отрицательно, т.е. суммарное влияние на метрику дало нулевой эффект?
Метрика «заработать 10 млн. (Revenue)» не может быть рутовой, потому что в этом случае проще всего ограбить банк. А если имеют значение другие метрики, такие как законность деятельности, то какую тогда считать рутовой?
Одно из самых вдохновляющих интервью, которые я читал за последнее время. Лю Цысинь и ода знаниям VS Талеб c антихрупким таксистом.
Очень многие тим лиды с опытом почему-то не могли решить задачу и за час.
занятно то, что тимлиды с опытом в принципе соглашались подобные задачи решать =)
Спасибо за статью, пригодилась!
груг говорить спасибо этот груг
очень понятный для другой груг письмена про тест
Статья огонь, отличный слог. Читал с удовольствием, спасибо! =)
https://www.dvfu.ru/news/fefu-news/robot_junior_brought_the_robotics_of_the_university_the_bronze_medal_of_the_open_championship_asia/?date=2020-09-10
Вот тут есть фоточки, в прозрачных трубках масло )
А зачем двигатели и прочую нутрянку за пределами прочного корпуса заливать эпоксидкой? Можно же маслом. И давление держать будет, и от коррозии защитит. По крайней мере, так делают в Институте Проблем Морских Технологий, что в Приморском крае.
Отправиться в пеший поход по незнакомому маршруту.
Скрафтить картофелемет.
1) Никаких «финальных правок» перед релизом, особенно, если код не покрыт тестами. Лучшее – враг хорошего: маааленький костыль, исправляющий такой же маленький дефект, сломал весьма критичную часть функциональности. И ушел в релиз. Разумеется, все было исправлено в следующем апдейте, но… поезд тоже уже ушел.
2) Разработчик должен сам пользоваться своим продуктом. Да, это не всегда удается, но в сфере мобильной разработки (особенно узконишевой) это сильно проще. Когда пользуешься продуктом сам, то точно знаешь, где его сильные и слабые стороны, отпадает необходимость в разнообразных фокус-группах и т.п. Я сам бегаю со StepPlayer, и мне очень нравится, что получилось.
3) Стучи, и откроют. С вероятностью, всегда превышающую вероятность успеха при «обидеться и уйти без шапки в ночь холодную». При этом очень помогает вера в свой продукт, а для этого важен пункт 2.