Спасибо.
Просто тема большая. По моей задумке в каждой статье будет раскрываться одна мысль или один вывод.
Следующую статью планирую после НГ выпустить
Чётких критериев слащавых метрик нет. Главный отличительный признак, на мой взгляд — когда они растут или падают, а Вы не можете понять почему.
Обычно этим грешат метрики, построенный по срезам, например, посещаемость по дням, количество заказов по дням или неделям, DAU/MAU, количество скачиваний и т.п.
В принципе, такие метрики тоже требуются, но применять их надо с очень большой осторожностью.
Свои размышления на тему слащавости я в своё время написал в виде статьи: habr.com/users/varenich/posts
Я уже писал выше и еще раз повторю, что я категорически против оценки людей и использования метрик для оценки команд.
Вообще, практически любую метрику разработки можно притянуть к людям, потому что именно люди производят код, но как Вы правильно написали, одна команда может кодировать медленнее просто потому, что им досталась более сложная задача.
Поэтому какую метрику не используй для оценки команд, она всё равно будет врать.
Но метрики все же нужны, особенно когда разработка производится в больших количествах.
Представьте, что происходит тысячи сборок в день и к Вам периодически приходят жалобы на конвейер. Вы же должны как-то понять, действительно ли он работает как надо и есть проблемы, или жалобы связаны с некоторыми специфическими случаями.
Посчитав текущую производительность конвейера и сравним её с целевой Вы сможете это понять, верно?
Моё мнение, что любая оценка людей субъективна и оценивает в первую очередь того, кто эту оценку дает :-)
Особенно хорошо эффективность такой оценки видна в больших компаниях. Вернее, отсутствие какого-либо эффекта.
Я провожу когортный анализ различных конверсий по той структуре индекса, скрин которого привел в начале статьи. Пока что не нашел способа как это сделать в Кибане. Поговорив с другими людьми я понял, что они тоже с этим сталкивались и не смогли получить результат.
Приходится сначала делать выгрузки записей по одному состоянию, а потом по другому. Далее объединять их в Excel в одну таблицу функцией ВПР.
Потому что некому было mvp делать
Видимо, везде по-разному.
Согласен полностью
Почему Вы так думаете? Лично я знаю хорошие примеры, когда аналитик отлично рулит бэклогом и проекты защищает.
Быстрые результаты не обозначают, что на них останавливаются. Система в дальнейшем была сделана по всем правилам.
Классный проект, очень интересный.
Спасибо, что поделились опытом — такие примеры вдохновляют
Просто тема большая. По моей задумке в каждой статье будет раскрываться одна мысль или один вывод.
Следующую статью планирую после НГ выпустить
Обычно этим грешат метрики, построенный по срезам, например, посещаемость по дням, количество заказов по дням или неделям, DAU/MAU, количество скачиваний и т.п.
В принципе, такие метрики тоже требуются, но применять их надо с очень большой осторожностью.
Свои размышления на тему слащавости я в своё время написал в виде статьи: habr.com/users/varenich/posts
Вообще, практически любую метрику разработки можно притянуть к людям, потому что именно люди производят код, но как Вы правильно написали, одна команда может кодировать медленнее просто потому, что им досталась более сложная задача.
Поэтому какую метрику не используй для оценки команд, она всё равно будет врать.
Но метрики все же нужны, особенно когда разработка производится в больших количествах.
Представьте, что происходит тысячи сборок в день и к Вам периодически приходят жалобы на конвейер. Вы же должны как-то понять, действительно ли он работает как надо и есть проблемы, или жалобы связаны с некоторыми специфическими случаями.
Посчитав текущую производительность конвейера и сравним её с целевой Вы сможете это понять, верно?
Почему Вы считаете, что метрика нерелевантная?
Особенно хорошо эффективность такой оценки видна в больших компаниях. Вернее, отсутствие какого-либо эффекта.
Приходится сначала делать выгрузки записей по одному состоянию, а потом по другому. Далее объединять их в Excel в одну таблицу функцией ВПР.