#метрики — Public Fediverse posts

Правда ли, что медицинский ИИ точнее врачей? Наш фреймворк помогает это выяснить

Привет, Хабр! Меня зовут Илья Копаничук, я старший научный сотрудник лаборатории «Сильный ИИ в медицине» AIRI. Мы с коллегами создаём ИИ‑инструменты, задача которых сделать качественную медицину доступнее. Например, основанное на нашей технологии приложение «Помощник по здоровью» стало лучшим ИИ‑решением в клиентском сервисе по версии Generation AI Awards 2025 . Но речь сегодня не об этом. За время нашей работы мы поняли, что контроль качества ИИ‑диагностики в медицине — это одна из ключевых задач, которая, как оказалось, не была ещё достаточно хорошо решена. Во‑первых, тесты для медицинских моделей зачастую далеки от реальной практики. А во‑вторых, всегда ли точны люди? Пытаясь ответить на эти вопросы, мы с помощью коллег из ФГБУ «НМИЦ им. В. А. Алмазова» Минздрава России собрали собственный фреймворк и опубликовали про него статью в Scientific Reports . Здесь я расскажу, как он устроен и на какие метрики мы обратили внимание, а также постараюсь дать ответ на вопрос, заданный в заголовке.

https://habr.com/ru/companies/airi/articles/1079898/

#метрики #оценка_качества #llm #llmприложения

Ежедневный ряд подписчиков в MAX: публичный эндпоинт, четыре грабли и почему not_found — не измерение

У мессенджера MAX нет публичного API со статистикой каналов. Числа есть у каталогов-агрегаторов, но они чужие и заморожены с 10 июля. Нам нужен был свой ряд подписчиков — и мы полгода снимаем его каждую ночь с публичного data-эндпоинта max.ru. Ниже — как устроен сбор и четыре места, где мы ошиблись. Самая дорогая ошибка стоила трёх ночей молчащего ряда при зелёном логе и exit 0: парсер на любую неудачу писал один статус not_found, а под него попадали три разных события — канала нет, max.ru сменил формат, нас затроттлило. Пока они не разделены, скрипт ничего не измеряет — он производит число, похожее на измерение.

https://habr.com/ru/articles/1080198/

#MAX #мессенджер_MAX #парсинг #SvelteKit #SQLite #каталог_каналов #firstparty_данные #обработка_ошибок #антинакрутка #метрики

Prometheus и VictoriaMetrics: почему одни и те же метрики могут занимать в 139 раз больше места

Меня зовут Стас Погоржельский, я технологический евангелист VK Cloud и последние месяцы гоняю Prometheus и VictoriaMetrics на одном стенде, чтобы понять, сколько на самом деле стоит одна точка метрики на диске. Обе системы делают одно и то же: принимают миллионы точек в минуту, хранят их месяцами и быстро отдают в алерты и дашборды. Обе сжимают точку до байтов и долей байта. Именно эти байты, умноженные на миллиарды точек в сутки, превращаются в счёт за диск. Ошибка в расчёте цены сэмпла заканчивается переполненным диском под мониторингом, урезанным retention или незапланированным расходом. Когда место под метрики кончается, первым на планёрке звучит «сменим движок». Публичные бенчмарки подталкивают к тому же: Флант показывает, что Prom++, форк Prometheus, тратит памяти в 7,8 раза меньше Prometheus v2 ( разбор на Habr ), VictoriaMetrics показывает трёхкратную экономию диска против Grafana Mimir ( бенчмарк VictoriaMetrics , замер вендора, 2022 год). На моём стенде картина оказалась сложнее. В Prometheus 3.13 и VictoriaMetrics 1.149 ушёл один и тот же набор: 2,88 млн сэмплов, шесть профилей данных, один генератор с фиксированным seed. Внутри одного движка цена сэмпла различалась в 139 раз у VictoriaMetrics и в 12,8 раза у Prometheus. Между движками на одних данных разрыв доходил до 30,7 раза на шести профилях и до 34,3 раза в опыте с точностью. На равномерно случайных float64 движки менялись местами. Один лишний знак после запятой поднимал цену сэмпла у Prometheus в восемь раз, у VictoriaMetrics на 12%.

https://habr.com/ru/companies/vk/articles/1068798/

#vk_cloud #prometheus #victoriametrics #time_series #tsdb #мониторинг #метрики #observability #сжатие_данных #cardinality

Кто на самом деле сломал вашего ИИ-агента: модель или обвязка?

Когда агент в проде ошибается, спор идёт по кругу: модель тупит, промпт кривой, API виноват. Свежая работа Scale AI даёт отказам адрес — ребро между компонентами и сторону вины. Оказывается, «виновата модель» почти никогда не значит «чинить дообучением»: разбираю таксономию из 41 режима, каталог-выжимку и четыре своих отказа с числами — ни один не закрыт сменой модели.

https://habr.com/ru/articles/1079638/

#LLM #ИИагенты #agent_harness #обвязка #таксономия_отказов #RAG #отладка #метрики #тестирование #arXiv

Почему одинаковые показатели в разных отчётах не совпадают

Два отчёта показывают один показатель за один период. Название одинаковое, подразделение выбрано одно и то же, но значения различаются. В этот момент обсуждение часто сводится к поиску «неправильной цифры»: аналитики проверяют формулы, разработчики перезапускают загрузку, пользователи сравнивают выгрузки вручную. Проблема в том, что совпадения названия, периода и формулы недостаточно. Один отчёт может считать текущее состояние объектов, другой - события за период. Один использовать время совершения операции, другой - время загрузки записи. Один пересчитывать историю после исправлений, другой хранить опубликованный срез. Оба расчёта при этом могут быть технически корректными. В проектах с BI-отчётностью я работал с контуром, где данные проходили путь от операционных систем и общей базы через API и выгрузки к ручной обработке, отчётам и справкам. При такой схеме итог зависит не только от SQL-запроса. На него влияют состояние источника, дата среза, справочники, правила исключения, ручные преобразования и момент обновления каждого звена. Поэтому расхождение лучше расследовать не как спор двух чисел, а как сравнение двух воспроизводимых расчётов. В этой статье разберу, из каких слоёв состоит показатель, как локализовать различие и что изменить в аналитическом контуре, чтобы одинаковая бизнес-метрика не реализовывалась заново в каждом отчёте.

https://habr.com/ru/articles/1079462/

#аналитика_данных #BI #метрики #качество_данных #семантический_слой #data_lineage #data_contracts #сверка_отчётов #временные_данные #дашборды

1.5 миллиона событий в день и ни одной таблицы events: как мы считали продуктовую аналитику 300K-бота по голому проду

Маркетолог прислал мне скрин дашборда и одно слово: «пусто». На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке. Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций. Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль. Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день : без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу. Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at . Всё, что вы прочитаете ниже, — следствие этого факта. Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет. Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.

https://habr.com/ru/articles/1078480/

#grafana #mysql #продуктовая_аналитика #sql #retention #воронка #telegram_bot #highload #метрики

Написал детектор ИИ-текста на 13 правил и прогнал 59 своих статей: сумма баллов не забраковала ни одну

Площадки перестали пускать машинный текст самотёком. Habr проверяет публикации автоматически, а Кевин Индиг пишет о том, что платформы строят anti-slop-системы — механизмы подавления массового низкокачественного ИИ-контента. Дальше обычно следует совет писать хорошо, и на этом разговор заканчивается. Мне нужно было проверяемое условие вместо совета, поэтому я собрал детектор на правилах и прогнал через него 59 собственных статей. Главный результат оказался не в том, сколько текстов он забраковал, а в том, что при агрегатном подсчёте он не забраковал ни одного, хотя дефекты были в сорока.

https://habr.com/ru/articles/1077790/

#детектор_ИИтекста #антиплагиат #Python #регулярные_выражения #качество_текста #редактура #проверка_контента #автоматизация #лингвистика #метрики

От MTTD и MTTR к реальной ценности: как навести порядок в метриках SOC

Что можно выжать из базовых метрик SOC, если у тебя лапки Многие руководители начинают день с дашбордов и красивых «бубликов». На них традиционно горят классические временные метрики по заветам NIST SP 800-61: среднее время обнаружения/решения/взятия в работу инцидентов ИБ совместно с общим количеством обработанных инцидентов. Топ-менеджмент всё устраивает – они понятные, линейные и отлично смотрятся в квартальных отчетах. Но потом внезапно выясняется, что кейсы закрываются по инерции, решения становятся все более поверхностными, а качество расследований тихо уезжает в закат.

https://habr.com/ru/companies/gazpromcps/articles/1076804/

#incident_response #soar #siem #mttr #mttd #MTTA #кибербезопасность #метрики #falsepositive #soc

Соревнование замерло 16 августа, а таблица поехала дальше. Разбираю, что из этого настоящее

Я полез в данные соревнования Pokemon TCG AI Battle посмотреть, кто там выигрывает, и залип на другом. На публичной таблице 6806 команд. Самая поздняя отправка решения датирована 16 августа, 23:58:53. После этой секунды не отправил никто 1668 команд из 6806, почти четверть поля, сделали финальную отправку именно в этот день: 824 из них после шести вечера, 350 в последний час. Похоже, немалая часть узнала про срок в тот же день, когда он истекал

https://habr.com/ru/articles/1074532/

#kaggle #соревнования #анализ_данных #статистика #метрики #лидерборд #визуализация_данных #ошибки_анализа #значимость #байтовая_квота

Перестаньте делать фичи, которые никому не нужны

Периодически мы чувствуем , что предлагаем хорошее решение. Как в меме: «Эта фича будет прибыльной, но я пока не могу этого доказать». В этом случае оценка продукта не учитывает мнение целевой аудитории, как будто мы единственный пользователь нашего решения. Иногда при формировании новых гипотез мы можем столкнуться с подменой понятий идеи, ценности и спроса. В моменте идея может показаться нам настолько классной, что мы объясняем её ценность команде, но пропускаем этап её фактической проверки и сразу приступаем к разработке. Давайте разберёмся, как же всё-таки принимать решения с опорой на реальность.

https://habr.com/ru/companies/tochka/articles/1072436/

#Метрики #решения #data_driven #исследования #аналитика

Цена, которой не существовало: две недели поиска бага, который не видел мониторинг

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

https://habr.com/ru/articles/1070518/

#кэширование #распределённые_системы #консистентность_данных #мониторинг #наблюдаемость #метрики #разбор_инцидента

Как мониторить Java-приложения: метрики, алерты и правило 80/20

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20 . Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

https://habr.com/ru/companies/yandex/articles/1068874/

#мониторинг #метрики #алертинг #java #devops #sre #site_reliability_engineering #надежность #инцидентменеджмент

Цифры не сходятся: алгоритм действий, который поможет находить расхождения в отчетах

Сообщение в личку в 18:40: «Слушай, а почему у тебя в выгрузке 11 903 заказа, а на дашборде 12 480? Завтра в 11 показываем отчет». Дальше начинается то, что я про себя называю паникой первого года и человек открывает свой запрос и перечитывает его сверху вниз, надеясь, что ошибка как-нибудь сама подсветится. Не подсвечивается. Тогда он переписывает запрос немного иначе, получает третье число, и к полуночи у него уже три версии правды и ноль понимания. За годы работы я разбирала такие расхождения десятки раз, собрала алгоритм, по которому причина находится примерно за час: таблица симптомов, семь шагов и список типовых причин, от границ периода до кэша дашборда.

https://habr.com/ru/articles/1069396/

#качество_данных #аналитика #анализ #аналитика_данных #джуниор_аналитик #карьера_итспециалиста #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков #метрики

Как оценивать эффективность разработки

Меня зовут Антон Омельяненко, я Head of Software Development в EXANTE. Менеджер управляет командой так, чтобы она приносила бизнесу результат. Чтобы понимать, насколько хорошо люди справляются с задачами, ему нужны данные о работе и система оценки. С разработкой это сложнее, чем кажется. В статье я разберу три вопроса: почему классические метрики не подходят для оценки эффективности разработчиков, как измерять её правильно и что делать, если вам кажется, что сотрудник работает не только на вас.

https://habr.com/ru/articles/1067558/

#продуктивность #удаленка #ии #эффективность #аналитика #метрики #разработка_по #gitlab #jira

OpenTelemetry как единый стандарт наблюдаемости для распределённых систем

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

https://habr.com/ru/companies/otus/articles/1059546/

#OpenTelemetry #наблюдаемость #распределённые_системы #телеметрия #метрики #логирование #распределённая_трассировка #OpenTelemetry_Collector #OTLP #сэмплирование

Мы чинили инциденты всё быстрее — а недовольство клиентов росло. Почему MTBF важнее MTTR

Инцидентов стало в два раза больше. Время восстановления сократилось вдвое. Uptime сервисов держался в норме. По всем ключевым метрикам мы становились лучше. А обращения в саппорт росли, аккаунт-менеджеры передавали жалобы, и в клиентском чате всё чаще писали, что сервис нестабилен. Эта статья о том, как метрики надёжности могут хором врать о клиентском опыте, почему установка «чините быстрее» — ловушка, которая сжигает дежурных инженеров и прячет настоящую причину проблем, и как мы развернули фокус с MTTR на MTBF, сократили количество инцидентов вдвое и вернули поток обращений клиентов к норме.

https://habr.com/ru/articles/1064948/

#mtbf #mttr #sre #надежность #метрики #инциденты #управление_разработкой

Логарифм для аналитика: где он спасает отчет, а где его ломает

Модель прогноза выручки занижала цифры вдвое. Ошибка была в одной строке – np.exp() вместо честного возврата из логарифмов. Разбираю этот кейс и всё остальное, что аналитику нужно знать про логарифм: декомпозиция роста, эластичность, A/B-тесты и поправка Дуана. С кодом и цифрами.

https://habr.com/ru/articles/1064212/

#математика_для_аналитика #анализ_данных #аналитика_данных #логарифм #логарифмы #эластичность #абтесты #метрики #выручка

ClickHouse: сценарии, сильные стороны, лучшие практики работы в 2026 году

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform , VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

https://habr.com/ru/companies/vktech/articles/1061284/

#vk_cloud #clickhouse #olap #колоночное_хранение #большие_данные #data_platform #логирование #метрики #архитектура_данных #best_practices

Вместо DORA: как перестать измерять всё подряд и начать управлять процессом разработки

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

https://habr.com/ru/companies/tochka/articles/1060134/

#метрики_процесса #метрики #команда_разработки #точка_банк

Сократили цикл разработки на 20% — и получили вдвое больше инцидентов

В продуктовой B2B-компании, где я отвечал за надёжность, поставили амбициозную цель: сократить цикл разработки (dev cycle time) на 20%. Забегая вперёд, скажу: к концу года цель достигли. Но уже через несколько месяцев после старта я смотрел на график инцидентов и не верил своим глазам: рост в два раза год к году. Эта статья — о том, почему так происходит почти всегда, когда компания оптимизирует одну метрику, как мы это починили и — главное — как продать решение руководству. Именно на продаже всё обычно и умирает.

https://habr.com/ru/articles/1059894/

#контрметрики #sre #метрики #надёжность #управление_разработкой #инциденты #dev_cycle_time

Как оценивать работу специалиста, отвечающего за автотесты, метрики и KPI?

Привет, Хабр! Меня зовут Андрей, я SDET-специалист в компании SimbirSoft. В этой статье мы разберём, какие метрики действительно применимы к специалисту по автотестированию и как их корректно использовать. Будет полезно для тимлидов команд по обеспечению качества, автотестировщиков и любых специалистов, которые хотят оценить метрики автотестирования. Традиционный метод постановки задач сотрудникам — это каскадная модель «сверху вниз»: общие цели проекта декомпозируются до целей подразделения, а затем преобразуются в индивидуальные задачи сотрудников. Логично предположить, что цели проекта и сотрудника синхронизированы, а собрав структурированные цели всех сотрудников, можно получить условный макет проекта. Однако возникает вопрос: как оценить вклад конкретного специалиста по автотестированию? Жми, чтобы узнать подробности 🤓

https://habr.com/ru/companies/simbirsoft/articles/1057952/

#автоматизация_тестирования #оценка_трудозатрат #метрики #kpi #kpi_показатели #обеспечение_качества

А вы правильно считаете MRR? Что включать в расчет, что нет?

5 клиентов по 10 000 рублей в месяц - 50 000 рублей MRR. Но при корректном подсчете на выходе получается лишь 27 000 - почти половина регулярной выручки будто испаряется. Разбираю типичные ошибки, которые допускают команды при расчете MRR, и объясняю, почему одна и та же база клиентов может показывать совершенно разные цифры в зависимости от методики подсчёта.

https://habr.com/ru/articles/1055318/

#mrr #биллинг #saas #saas_сервисы #product #биллинговые_системы #рекуррентные_платежи #метрики_продукта #метрики #выручка

SonarQube в CI: подключили, забили, а потом удивляемся

SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества. Статья будет полезна QA, разработчикам и тимлидам, у которых SonarQube уже есть, но результаты анализа живут ни на что не влияют.

https://habr.com/ru/companies/2gis/articles/1053620/

#sonarqube #sonar #метрики

Все внедрили AI. Почти никто им не пользуется. Разбор самого массового вранья года

В прошлом году я наблюдал одно и то же внедрение AI в четырёх разных компаниях. Разные индустрии, разные бюджеты, один сценарий, вплоть до реплик. Сценарий такой. Сверху приходит: «нам нужен AI, все уже внедрили». Спешно выкатывают корпоративного ассистента — чат поверх LLM, обёрнутый в фирменные цвета. Через месяц готов слайд: «AI-ассистентом воспользовались 10 000 раз». Совет доволен. В письме инвесторам — строчка про «AI-трансформацию». Продукту — премия. А теперь то, чего на слайде нет. Я в таких случаях прошу показать не «количество запросов», а три других числа. Сколько людей пришло во второй раз. Сколько пользуется раз в неделю спустя месяц. И что эти люди перестали делать по-старому. В одной из тех четырёх компаний картина была такая: из десяти тысяч запросов девять тысяч — люди, которые задали один вопрос, получили ерунду и не вернулись. Никогда. Из оставшихся — половина это сотрудники, которых попросили «потестить», и демо для руководства. Недельная активная аудитория «внедрённого» AI спустя квартал — четырнадцать человек. Из четырёх тысяч сотрудников. В отчёте осталось «10 000». Слайд ещё дважды показывали на советах.

https://habr.com/ru/articles/1055268/

#ai #внедрение_ai #adoption #метрики #llm #закон_гудхарта #управление_продуктом

Логи, бэкапы, образы, артефакты: где мы используем S3 внутри Рег.облака

Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

https://habr.com/ru/companies/runity/articles/1054318/

#регоблако #s3 #s3server #s3хранилище #k8s #kubernetes #логи #бэкап #метрики #артефакты

6 ошибок в метриках дефектов, из-за которых QA теряет контроль над качеством

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

https://habr.com/ru/companies/otus/articles/1047054/

#QA #метрики #тестирование #QALead #управлениекачеством #баги #escaperate #DRE #reopenrate

Я устал писать одноразовые скрипты для бенчмарков LLM и собрал харнесс, который сам считает Pareto-front

Неважно, где ты гоняешь инференс: в проде на vLLM под нагрузкой или в локалке на llama.cpp, пытаясь втиснуть Llama-3 в 4 ГБ видеопамяти — вопрос всегда один. Какая конфигурация влезет в бюджет по VRAM и при этом не уронит p95? В статье рассказываю про разработанный харнесс, который берет эту рутину на себя и честно сравнивает бэкенды. Разбираем реальные грабли локального и прод-инференса.

https://habr.com/ru/articles/1052678/

#LLM #инференс #бенчмаркинг #vLLM #llamacpp #метрики #воспроизводимость #энергоэффективность #производительность #gpu

MRR считают почти все. Правильно считают единицы

Пять клиентов по 10 000 рублей в месяц должны давать MRR 50 000 рублей. На практике после корректного расчёта остаётся всего 27 000. Куда исчезла почти половина регулярной выручки? Разбираю самые распространённые ошибки в расчёте MRR и показываю, почему одна и та же клиентская база может давать совершенно разные цифры.

https://habr.com/ru/articles/1052054/

#mrr #биллинг #биллинговые_системы #рекуррентные_платежи #выручка #метрики #метрики_продукта

Гросхакинг в бигтехе (да и вообще) — это реально?

Некоторые продуктовые процессы никогда не смогут быть вместе. Слишком много противоречий, слишком разный внутренний мир. Ты Венера, я Юпитер. Ты большой таргет стейт, я mvp-дривен. Но постойте… Разве реальная любовь в жизни случается только с теми, у кого много общего? Лид кластера геймификации приложения «Магнит», народный продакт-старовер Магнит Плюс (входит в бизнес-группу MAGNIT OMNI) Евгений Коврижин написал дискуссионную статью про внедрение процесса growth hacking в бигтехе. Только собственный 17-летний продуктовый опыт и никакого AI. Кто оставит комментарий, тот молодец.

https://habr.com/ru/companies/magnit/articles/1050266/

#Growth_Hacking #Управление_продуктом #Продактменеджмент #Метрики #Продуктовые_команды #Внедрение_изменений #Рост_метрик #Product_Owner

Кейс обучения QA-персонала: развитие навыков оценки задач и контроль качества через метрики

Роль и контекст Короче говоря, я QA лид. Отвечаю за обеспечение и контроль качества сразу на нескольких проектах в компании IT Test. А это значит, что пребывая к контексте десятка имеющихся у нас в портфеле проектов, я выстраиваю процессы тестирования, анализирую связанные с качеством инциденты, развиваю компетенции тестировщиков и, в целом, делаю всё, чтобы QA активности были прогнозируемыми результативными. Команда у нас распределена между тремя типами проектов: аутстафф-, аутсорс- и внутренними проектами, и каждый из таковых требует индивидуального подхода к организации работ по тестированию. На аутстафф-проектах я обычно не осуществляю прямое административное управление, но остаюсь точкой экспертной поддержки: помогаю разбирать сложные ситуации, решаю возникающие проблемы, консультирую по процессам и участвую в квалификационном росте специалистов. Полноценный менеджемент в той форме, в какой он обычно понимается, я осуществляю на внутренних и аутсорс-проектах. Именно я формулирую здесь стратегию тестирования, осуществляю контроль выполнения задач, анализ эффективности и обучение команды. И здесь, в условиях разнообразия проектов, становится важным соблюсти баланс между единым подходом к обеспечению качества и уникальностью отдельных процедур тестирования, каковые требуют проекты. Например, любому QA-инженеру очевидна необходимость ведения тестовой документации. Но как вести таковую, если мы заранее знаем, что текущая реализация функционала отличается от того, как это будет реализовано в итоге? Писать кейсы, опираясь на то, как это работает сейчас, или на то, как это должно быть в финале? Такие вопросы наравне со множеством иных мне приходится ежедневно решать в ходе своей деятельности. И данный формат работы требует специфического подхода к обеспечению качества, когда само понимание качества от проекту к проекту начинает варьироваться. На помощь здесь мне приходят, во-первых, метрики. Те же самые, с которыми работает большинство лидов QA: метрики дефектов, метрики тестового покрытия, выполнения тестов, релизного качества и та метрика, о которой мы далее поговорим более детально - метрика эффективности команды. Ну а, во-вторых, моему управлению обеспечения качества помогает постоянная работа с профессиональным ростом сотрудников. Именно о том, как эти два явления - моя работа с профессиональным ростом и метрика эффективности сосуществуют, - я бы и хотел здесь рассказать. В рамках текущей статьи я оставлю вне нашего внимания метрики релизного качества и выполнения тестирования, и лишь скажу, что к таковым метрику эффективности команды я не отношу, несмотря на присутствие в них взаимного влияния. Метрика эффективности команды в нашем случае оперирует таким понятием, как оценка или эстимейт, и служит для понимания предсказуемости и стабильности QA - процесса. Эта метрика включает в себя:

https://habr.com/ru/articles/1050940/

#QA #тестирование #оценка_задач #эстимейт #метрики #управление_качеством #аутстаффинг