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

Почему «душнила» — возможно, ваш лучший босс: 9 причин, зачем руководитель лезет в разработку

Согласитесь, мысль «Эх, вот я бы на их месте всё сделал иначе» хотя бы раз приходила в голову каждому, кому руководитель «мешал работать». Но что на самом деле значит это «иначе»? Что именно кажется лишним, душным или раздражающим? И главное — зачем руководитель вообще делает все эти вещи, которые так хочется назвать бюрократией? Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме Лукоморье. В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления. В статье я собрал своего рода рабочий чемоданчик из девяти инструментов. Он нужен не для того, чтобы делить руководителей на « плохих » и « хороших » . Моя задача — перевести вас на другую сторону баррикады и показать, как эти механизмы работают изнутри. Цель статьи простая: объяснить, почему человек, став руководителем, перестаёт думать только как разработчик. В его жизни появляются те самые «душные» штуки: метрики, бюджеты, приоритеты, риски, ресурсы и прочий управленческий слой. Этой статьёй я хочу объяснить логику управленца языком разработчика. P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены. Давай душнить

https://habr.com/ru/companies/lukit_ru/articles/1032384/

#itменеджмент #cto #разработка #метрики #лукоморье #управление #управление_людьми #управление_проектами #управление_командой #управление_разработкой

Почему «душнила» — возможно, ваш лучший босс: 9 причин, зачем руководитель лезет в разработку

Согласитесь, мысль «Эх, вот я бы на их месте всё сделал иначе» хотя бы раз приходила в голову каждому, кому руководитель «мешал работать». Но что на самом деле значит это «иначе»? Что именно кажется лишним, душным или раздражающим? И главное — зачем руководитель вообще делает все эти вещи, которые так хочется назвать бюрократией? Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме Лукоморье. В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления. В статье я собрал своего рода рабочий чемоданчик из девяти инструментов. Он нужен не для того, чтобы делить руководителей на « плохих » и « хороших » . Моя задача — перевести вас на другую сторону баррикады и показать, как эти механизмы работают изнутри. Цель статьи простая: объяснить, почему человек, став руководителем, перестаёт думать только как разработчик. В его жизни появляются те самые «душные» штуки: метрики, бюджеты, приоритеты, риски, ресурсы и прочий управленческий слой. Этой статьёй я хочу объяснить логику управленца языком разработчика. P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены. Давай душнить

https://habr.com/ru/companies/lukit_ru/articles/1032384/

#itменеджмент #cto #разработка #метрики #лукоморье #управление #управление_людьми #управление_проектами #управление_командой #управление_разработкой

Почему «душнила» — возможно, ваш лучший босс: 9 причин, зачем руководитель лезет в разработку

Согласитесь, мысль «Эх, вот я бы на их месте всё сделал иначе» хотя бы раз приходила в голову каждому, кому руководитель «мешал работать». Но что на самом деле значит это «иначе»? Что именно кажется лишним, душным или раздражающим? И главное — зачем руководитель вообще делает все эти вещи, которые так хочется назвать бюрократией? Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме Лукоморье. В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления. В статье я собрал своего рода рабочий чемоданчик из девяти инструментов. Он нужен не для того, чтобы делить руководителей на « плохих » и « хороших » . Моя задача — перевести вас на другую сторону баррикады и показать, как эти механизмы работают изнутри. Цель статьи простая: объяснить, почему человек, став руководителем, перестаёт думать только как разработчик. В его жизни появляются те самые «душные» штуки: метрики, бюджеты, приоритеты, риски, ресурсы и прочий управленческий слой. Этой статьёй я хочу объяснить логику управленца языком разработчика. P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены. Давай душнить

https://habr.com/ru/companies/lukit_ru/articles/1032384/

#itменеджмент #cto #разработка #метрики #лукоморье #управление #управление_людьми #управление_проектами #управление_командой #управление_разработкой

Почему «душнила» — возможно, ваш лучший босс: 9 причин, зачем руководитель лезет в разработку

Согласитесь, мысль «Эх, вот я бы на их месте всё сделал иначе» хотя бы раз приходила в голову каждому, кому руководитель «мешал работать». Но что на самом деле значит это «иначе»? Что именно кажется лишним, душным или раздражающим? И главное — зачем руководитель вообще делает все эти вещи, которые так хочется назвать бюрократией? Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме Лукоморье. В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления. В статье я собрал своего рода рабочий чемоданчик из девяти инструментов. Он нужен не для того, чтобы делить руководителей на « плохих » и « хороших » . Моя задача — перевести вас на другую сторону баррикады и показать, как эти механизмы работают изнутри. Цель статьи простая: объяснить, почему человек, став руководителем, перестаёт думать только как разработчик. В его жизни появляются те самые «душные» штуки: метрики, бюджеты, приоритеты, риски, ресурсы и прочий управленческий слой. Этой статьёй я хочу объяснить логику управленца языком разработчика. P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены. Давай душнить

https://habr.com/ru/companies/lukit_ru/articles/1032384/

#itменеджмент #cto #разработка #метрики #лукоморье #управление #управление_людьми #управление_проектами #управление_командой #управление_разработкой

Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%

Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.

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

#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда

Как посчитать ROI AI‑проекта, а не нарисовать его в презентации

AI‑проекты часто выглядят убедительно на уровне демо: модель отвечает, интерфейс работает, в презентации уже стоит ROI и срок окупаемости. Проблемы начинаются позже — когда нужно доказать, что продукт действительно меняет бизнес‑процесс, экономит деньги или влияет на выручку. В этой статье разберём, как считать ROI AI/ML‑проекта без самообмана: от baseline и полного TCO до adoption rate, value drivers и риск‑поправок, которые быстро превращают красивую экономику пилота в куда более приземлённую модель.

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

#AIпроект #ROI #окупаемость #TCO #baseline #adoption_rate #AIпродукт #MLпродукт #бизнесценность #метрики

Как посчитать ROI AI‑проекта, а не нарисовать его в презентации

AI‑проекты часто выглядят убедительно на уровне демо: модель отвечает, интерфейс работает, в презентации уже стоит ROI и срок окупаемости. Проблемы начинаются позже — когда нужно доказать, что продукт действительно меняет бизнес‑процесс, экономит деньги или влияет на выручку. В этой статье разберём, как считать ROI AI/ML‑проекта без самообмана: от baseline и полного TCO до adoption rate, value drivers и риск‑поправок, которые быстро превращают красивую экономику пилота в куда более приземлённую модель.

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

#AIпроект #ROI #окупаемость #TCO #baseline #adoption_rate #AIпродукт #MLпродукт #бизнесценность #метрики

Как посчитать ROI AI‑проекта, а не нарисовать его в презентации

AI‑проекты часто выглядят убедительно на уровне демо: модель отвечает, интерфейс работает, в презентации уже стоит ROI и срок окупаемости. Проблемы начинаются позже — когда нужно доказать, что продукт действительно меняет бизнес‑процесс, экономит деньги или влияет на выручку. В этой статье разберём, как считать ROI AI/ML‑проекта без самообмана: от baseline и полного TCO до adoption rate, value drivers и риск‑поправок, которые быстро превращают красивую экономику пилота в куда более приземлённую модель.

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

#AIпроект #ROI #окупаемость #TCO #baseline #adoption_rate #AIпродукт #MLпродукт #бизнесценность #метрики

Как посчитать ROI AI‑проекта, а не нарисовать его в презентации

AI‑проекты часто выглядят убедительно на уровне демо: модель отвечает, интерфейс работает, в презентации уже стоит ROI и срок окупаемости. Проблемы начинаются позже — когда нужно доказать, что продукт действительно меняет бизнес‑процесс, экономит деньги или влияет на выручку. В этой статье разберём, как считать ROI AI/ML‑проекта без самообмана: от baseline и полного TCO до adoption rate, value drivers и риск‑поправок, которые быстро превращают красивую экономику пилота в куда более приземлённую модель.

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

#AIпроект #ROI #окупаемость #TCO #baseline #adoption_rate #AIпродукт #MLпродукт #бизнесценность #метрики

Как проводить нагрузочное тестирование на Python

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить? В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес-сценарии и когда инфраструктура начинает деградировать.

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

#нагрузочное_тестирование #Python #Locust #производительность #метрики #RPS #время_отклика #тестирование_стабильности #HTTPзапросы #сценарии_нагрузки

Как проводить нагрузочное тестирование на Python

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить? В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес-сценарии и когда инфраструктура начинает деградировать.

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

#нагрузочное_тестирование #Python #Locust #производительность #метрики #RPS #время_отклика #тестирование_стабильности #HTTPзапросы #сценарии_нагрузки

Как проводить нагрузочное тестирование на Python

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить? В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес-сценарии и когда инфраструктура начинает деградировать.

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

#нагрузочное_тестирование #Python #Locust #производительность #метрики #RPS #время_отклика #тестирование_стабильности #HTTPзапросы #сценарии_нагрузки

Как проводить нагрузочное тестирование на Python

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить? В такие секунды и выясняется, что без нагрузочного тестирования команда на самом деле не знает, где у системы потолок, как проседает производительность и в какой точке критично растёт время отклика. Хорошо настроенное нагрузочное тестирование на Python помогает опираться на цифры: сколько запросов выдерживает API, как ведут себя ключевые бизнес-сценарии и когда инфраструктура начинает деградировать.

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

#нагрузочное_тестирование #Python #Locust #производительность #метрики #RPS #время_отклика #тестирование_стабильности #HTTPзапросы #сценарии_нагрузки

oosmetrics.com — когда публикация на строннем сайте может навредить вашему проекту

Однажды я получил занимательное письмо от некой организации, которая добавила мой проект в свой рейтинг, да еще и метрики к нему прикрутила. Но мне стало интересно, какая у нее репутация.

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

#oosmetrics #метрики #безопасность #скам #мошенничество #начинающим #начинающие_разработчики #начинающие_программисты #opensource

Почему вредно сразу начинать рисовать макеты

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

https://habr.com/ru/companies/alfa/articles/1028446/

#продуктовый_дизайн #продуктовое_мышление #метрики #теория_ограничений #дизайн

Eat your own dog food: почему продукт, которым не пользуются создатели, обречён

Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает. Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует. У нас есть три живых кейса, которые демонстрируют, что происходит, когда принцип нарушается систематически, публично и в промышленных масштабах.

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

#dog_food #продуктовый_менеджмент #VK #MAX #Rutube #метрики #product_culture #принуждение #мессенджеры #блокировки

Eat your own dog food: почему продукт, которым не пользуются создатели, обречён

Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает. Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует. У нас есть три живых кейса, которые демонстрируют, что происходит, когда принцип нарушается систематически, публично и в промышленных масштабах.

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

#dog_food #продуктовый_менеджмент #VK #MAX #Rutube #метрики #product_culture #принуждение #мессенджеры #блокировки

Eat your own dog food: почему продукт, которым не пользуются создатели, обречён

Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает. Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует. У нас есть три живых кейса, которые демонстрируют, что происходит, когда принцип нарушается систематически, публично и в промышленных масштабах.

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

#dog_food #продуктовый_менеджмент #VK #MAX #Rutube #метрики #product_culture #принуждение #мессенджеры #блокировки

Eat your own dog food: почему продукт, которым не пользуются создатели, обречён

Это не про политику. Это про продуктовый сигнал, который считывают все — кроме тех, кто его посылает. Есть старый принцип в разработке: eat your own dog food — пользуйся тем, что создаёшь. Microsoft внедрила его в 1988-м, когда менеджер написал вирусное письмо коллегам: «Ты ешь свой собственный корм для собак?» Смысл прост — если вы не пользуетесь собственным продуктом, у вас нет мотивации его улучшать. Пользователи это видят. Рынок это чувствует. У нас есть три живых кейса, которые демонстрируют, что происходит, когда принцип нарушается систематически, публично и в промышленных масштабах.

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

#dog_food #продуктовый_менеджмент #VK #MAX #Rutube #метрики #product_culture #принуждение #мессенджеры #блокировки

Советские гвозди и токены: что общего?

Менеджмент нашёл способ измерить AI-продуктивность. Он такой же удобный, как и всегда. Компании начали ранжировать инженеров по количеству потреблённых AI-токенов. Не по результату, не по коду — по токенам. Это называется tokenmaxxing.

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

#ии #история #метрики #продукт #проджект #аналитика

Модно не значит правильно — про pgx, метрики и OpenTelemetry

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами. Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

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

#pgx #sqlx #OpenTelemetry #Prometheus #observability #трейсинг #метрики #QueryTracer #otelsql #otelpgx

Модно не значит правильно — про pgx, метрики и OpenTelemetry

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами. Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

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

#pgx #sqlx #OpenTelemetry #Prometheus #observability #трейсинг #метрики #QueryTracer #otelsql #otelpgx

Модно не значит правильно — про pgx, метрики и OpenTelemetry

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами. Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

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

#pgx #sqlx #OpenTelemetry #Prometheus #observability #трейсинг #метрики #QueryTracer #otelsql #otelpgx

Модно не значит правильно — про pgx, метрики и OpenTelemetry

Один вопрос про pgx — и три инструмента которые легко перепутать. QueryTracer не замена декоратору, декоратор не устарел, а выбор драйвера — неожиданно важное решение для observability. Какую комбинацию драйвера и обёртки выбрать — зависит от того что вы хотите видеть. В статье взгляд на комбинации драйверов и оболочек для анализа запросов в PostgreSQL. Разбираем на реальном проекте — с кодом, ошибками и выводами. Лучше один раз разобраться, чем каждый раз сомневаться в выборе.

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

#pgx #sqlx #OpenTelemetry #Prometheus #observability #трейсинг #метрики #QueryTracer #otelsql #otelpgx

Не просто дашборд: как DORA-метрики помогли нам сократить инциденты на 80%

DORA-метрики легко обсуждать как что-то довольно очевидное: выбрал четыре показателя, подключил данные, построил графики — готово. На практике все интересное начинается в тот момент, когда пытаешься сделать это не в презентации, а в живой компании с сотнями сервисов, разными сценариями деплоя и командами, у каждой из которых свой способ довозить код до прода. В Островке из этой задачи в итоге вырос отдельный сервис: он собирает события о релизах, связывает их с изменениями в GitLab, сопоставляет с инцидентами и отдаёт данные в Grafana. На MVP мы покрыли 90% проектов, а после регулярного разбора метрик и автоматизации узких мест количество критичных сбоев по последним данным снизилось на 80% . Под катом — история о том, как мы к этому пришли: откуда брали данные для DORA-метрик, как считали их в условиях очень разных релизных процессов и почему самой сложной частью оказалось не нарисовать графики, а вообще договориться с реальностью.

https://habr.com/ru/companies/ostrovok/articles/1024148/

#dora_metrics #django #backend #метрики #инциденты #стабильность #деплой #python #gitlab

[Перевод] Почему observability-данные теряют ценность ещё при сборе

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

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

#observability #логирование #наблюдаемость #трассировка #метрики #кардинальность #DevOps_практики #качество_данных

Founder Mode: как ИИ вытащил меня из иллюзии занятости, или…

Как я потерял несколько лет, делая всё кроме главного — и что с этим сделал Эта статья — про две вещи. Сначала — зачем : годы прокрастинации, иллюзия занятости и простая механика, которая это сломала. Потом — как : 35-й вайбкодинг-проект за 10 месяцев, событийная архитектура, 39 коммитов за 3 недели, TypeScript, Playwright, LLM и деплой на двухъядерный VDS. На Хабре вышла [ статья Эдуарда Ланчева ] — честная история, как один человек за 3 месяца с помощью ИИ собрал полноценный шахматный сервис. У меня похожая. Только не про шахматы, а про предпринимательство. И не 100 тысяч строк, а 9 500 — но с event store, инвариантами и Prometheus на проде. --- Часть 1. Медоборудование, прокрастинация и иллюзия занятости Несколько лет назад накопилось достаточно денег, чтобы попробовать своё дело. Ниша знакомая — проектные продажи медицинского оборудования. Бизнес-модель простая: находишь клиники и госпитали, заходишь к нужным людям, продаёшь. Казалось бы, что сложного. Я не продавал. Вместо этого — маркетинговые материалы, поиск уникального оборудования, изучение конкурентов, чтение про отрасль. Классика жанра. Всё это ощущалось как работа: занят, устал, лёг спать с чувством, что что-то делал. Но денег не было, потому что без продаж денег не бывает. Самое неприятное: не было момента осознания, не было точки, чтобы посмотреть в зеркало и сказать: «окей, ты избегаешь главного». Просто отсутствие прогресса накапливалось, доходило до критической точки — тогда начиналось шевеление, минимальный результат, и всё возвращалось на круги своя. Я потерял несколько лет. Единственный вывод: что-то подсознательно избегалось. Другие проекты — та же история Прошло время. Новые проекты, другая сфера. И всё повторилось. Снова — что угодно, кроме того, что действительно двигало бизнес вперёд. Допиливал продукт бесконечно, перескакивал между проектами, находил причины, почему «сегодня не лучший день», и проводил его в телефоне.

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

#Founder_Mode #прокрастинация #вайбкодинг #событийная_архитектура #PossibilityDriven_Architecture #метрики #daily_fixations #LLM #read_models #инварианты

Как я в одиночку сделал систему аналитики для Clubs в EA FC, потому что нормальной статистики там просто нет

Начну с контекста. Я играю в EA FC (ранее FIFA) в режиме Clubs (11×11), где каждым виртуальным игроком управляет человек. Сам по себе режим интересный, но мне, как человеку, который любит цифры и аналитику, довольно быстро стало не хватать доступной статистики. Я пришёл в лигу, у которой уже был свой сайт (я в этой статье опущу тему о том, что я администрировал проект порядка 3 лет). Там статистику собирали вручную: люди пересматривали записи матчей и заносили базовые показатели — голы, ассисты, перехваты, отборы и так далее. На основе этих данных считались различные рейтинги: лучшие игроки, бомбардиры, разрушители и прочее. Выглядело это примерно так: набор таблиц, где действия сгруппированы по категориям и амплуа.

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

#EA_FC #clubs #футбольная_аналитика #статистика #анализ_данны #метрики #nextjs #mysql #петпроект #system_design

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Нагрузочное тестирование с нуля: наши грабли, гонка за токеном и рабочий чек-лист

Привет, хабровчане! Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. Все мы знаем эту боль: фича идеально работает на деве и предпроде, проходит все тесты, а когда под реальной нагрузкой на нее заходят сотни пользователей одновременно - все начинает тормозить, сыпать ошибками или просто падать. Чтобы этого избежать, мы решили, что НТ должно стать обязательным этапом для всех фичевых задач, которые серьезно меняют логику, затрагивают запросы к серверу, кэширование или обработку данных. Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

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

#нагрузочное_тестирование #race_condition #кэширование_данных #memcached #оптимизация_производительности #чеклист_нагрузочного_тестирования #кейс_нагрузочного_тестирования #гонка_процессов #метрики #анализ_работы_web_сервисов

Продуктовые метрики: пример расчета на SQL

У нас есть продукт и нам нужно рассчитать ключевые метрики, которые показывают здоровье продукта: - DAU/MAU – вовлеченность - Conversion Rate – конверсия в целевое действие (у нас это создание объявления) - Retention – удержание пользователей - LTV – жизненная ценность клиента - ARPPU – средний доход с платящего пользователя В статье разберем последовательный расчет с примером синтетических данных и готового кода на SQL.

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

#sql #sql_server #sqlite #разбор_задач #анализ_данных #метрики #метрики_продукта #карьера_аналитика #карьера_аналитика_данных #карьера_аналитиков

SQL: 5 задач по анализу торгового пространства для ритейла

В ритейле каждый сантиметр полки – это деньги (буквально). В этой статье я разберу примеры задач, которые решает аналитик в ритейле, и покажу, как их решать на SQL. Каждая задача сложнее предыдущей для каждой есть код и готовые синтетические данные, поэтому все результаты можно получить самостоятельно, повторив код.

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

#анализ_данных #sql #sqlite #sql_server #эффективность_выкладки #планограмма #оконные_функции_sql #метрики #карьера_аналитика #карьера_аналитика_данных

Метрики команды разработки: какие считать, а какие — игнорировать

Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются. В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов. Разобраться в метриках

https://habr.com/ru/companies/simpleone/articles/1007380/

#метрики #метрики_продуктивности #управление_проектами #управление_командой #управление_разработкой_продукта #Agile_метрики #cycle_time #wipлимиты #Lead_Time #Velocity

Метрики команды разработки: какие считать, а какие — игнорировать

Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются. В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов. Разобраться в метриках

https://habr.com/ru/companies/simpleone/articles/1007380/

#метрики #метрики_продуктивности #управление_проектами #управление_командой #управление_разработкой_продукта #Agile_метрики #cycle_time #wipлимиты #Lead_Time #Velocity

Метрики команды разработки: какие считать, а какие — игнорировать

Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются. В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов. Разобраться в метриках

https://habr.com/ru/companies/simpleone/articles/1007380/

#метрики #метрики_продуктивности #управление_проектами #управление_командой #управление_разработкой_продукта #Agile_метрики #cycle_time #wipлимиты #Lead_Time #Velocity

Метрики команды разработки: какие считать, а какие — игнорировать

Velocity, Burndown и количество закрытых задач выглядят как контроль над разработкой. На практике эти метрики часто создают только видимость управляемости: отчёты красивые, а сроки всё равно срываются. В статье разбираем, какие показатели действительно помогают прогнозировать сроки, находить узкие места и держать баланс между скоростью разработки и качеством релизов. Разобраться в метриках

https://habr.com/ru/companies/simpleone/articles/1007380/

#метрики #метрики_продуктивности #управление_проектами #управление_командой #управление_разработкой_продукта #Agile_метрики #cycle_time #wipлимиты #Lead_Time #Velocity

QA метрики как база управленческих решений

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно . Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления . Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: не ломали команду, не показывали погоду, работали в пользу продукта и бизнеса. Ограничения и рекомендации: Здесь описана модель системы управления . Задумано, чтобы она была узнаваемой и вызывала отклик. Если вы узнаете себя в тексте, призываю использовать статью для поиска собственных взаимосвязей. Прямое копирование решений без опоры на контекст может навредить. Модель охватывает все стороны управления QA — это большой пласт . Одно предложение в тексте может означать месяц согласований, поэтому подобные изменения внедряют по частям. В статье есть карта «частей» с рекомендациями по сборке собственного роадмапа. Описание — в Навигаторе . Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных. Я выбрала метрики завершенного цикла (рефлексии) : они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе « О метриках ».

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

#qa_метрики #метрики_тестирования #метрики_процесса #метрики_продукта #метрики #lean #метрики_качества #qa

QA метрики как база управленческих решений

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно . Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления . Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: не ломали команду, не показывали погоду, работали в пользу продукта и бизнеса. Ограничения и рекомендации: Здесь описана модель системы управления . Задумано, чтобы она была узнаваемой и вызывала отклик. Если вы узнаете себя в тексте, призываю использовать статью для поиска собственных взаимосвязей. Прямое копирование решений без опоры на контекст может навредить. Модель охватывает все стороны управления QA — это большой пласт . Одно предложение в тексте может означать месяц согласований, поэтому подобные изменения внедряют по частям. В статье есть карта «частей» с рекомендациями по сборке собственного роадмапа. Описание — в Навигаторе . Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных. Я выбрала метрики завершенного цикла (рефлексии) : они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе « О метриках ».

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

#qa_метрики #метрики_тестирования #метрики_процесса #метрики_продукта #метрики #lean #метрики_качества #qa

QA метрики как база управленческих решений

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно . Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления . Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: не ломали команду, не показывали погоду, работали в пользу продукта и бизнеса. Ограничения и рекомендации: Здесь описана модель системы управления . Задумано, чтобы она была узнаваемой и вызывала отклик. Если вы узнаете себя в тексте, призываю использовать статью для поиска собственных взаимосвязей. Прямое копирование решений без опоры на контекст может навредить. Модель охватывает все стороны управления QA — это большой пласт . Одно предложение в тексте может означать месяц согласований, поэтому подобные изменения внедряют по частям. В статье есть карта «частей» с рекомендациями по сборке собственного роадмапа. Описание — в Навигаторе . Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных. Я выбрала метрики завершенного цикла (рефлексии) : они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе « О метриках ».

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

#qa_метрики #метрики_тестирования #метрики_процесса #метрики_продукта #метрики #lean #метрики_качества #qa

QA метрики как база управленческих решений

Привет, Хабр! Меня зовут Кияшева Екатерина, я занимаюсь качеством. Сегодня хочу поделиться опытом о метриках качества системно . Предложить примеры, провести взаимосвязи: Метрики ⇔ Процессы ⇔ Области управления . Эта статья для руководителей, кто и сам ищет решения, чтобы метрики: не ломали команду, не показывали погоду, работали в пользу продукта и бизнеса. Ограничения и рекомендации: Здесь описана модель системы управления . Задумано, чтобы она была узнаваемой и вызывала отклик. Если вы узнаете себя в тексте, призываю использовать статью для поиска собственных взаимосвязей. Прямое копирование решений без опоры на контекст может навредить. Модель охватывает все стороны управления QA — это большой пласт . Одно предложение в тексте может означать месяц согласований, поэтому подобные изменения внедряют по частям. В статье есть карта «частей» с рекомендациями по сборке собственного роадмапа. Описание — в Навигаторе . Метрики качества раскрывают уютный хаос — это выгодно на дистанции, но неприятно в моменте. Готовность к «рабочим моментам в полях» и культура общей безопасности обязательны для получения честных данных. Я выбрала метрики завершенного цикла (рефлексии) : они строятся на основе операционных и служат фундаментом для стратегических. Это позволило рассмотреть QA со всех ракурсов и не закопаться в деталях. Определение типов метрик приведено в разделе « О метриках ».

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

#qa_метрики #метрики_тестирования #метрики_процесса #метрики_продукта #метрики #lean #метрики_качества #qa

Многогранный мониторинг Angie — продолжение истории

Многогранный мониторинг Angie - продолжение истории Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром . Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

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

#Angie #WebServer #Мониторинг #DevOps #Observability #API #Метрики #СистемныйАдминистратор #Бэкенд

Многогранный мониторинг Angie — продолжение истории

Многогранный мониторинг Angie - продолжение истории Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром . Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

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

#Angie #WebServer #Мониторинг #DevOps #Observability #API #Метрики #СистемныйАдминистратор #Бэкенд

Многогранный мониторинг Angie — продолжение истории

Многогранный мониторинг Angie - продолжение истории Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром . Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

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

#Angie #WebServer #Мониторинг #DevOps #Observability #API #Метрики #СистемныйАдминистратор #Бэкенд

Многогранный мониторинг Angie — продолжение истории

Многогранный мониторинг Angie - продолжение истории Мы привыкли, что веб-сервер - это чёрный ящик, который просто гонит трафик. Стандартные метрики Angie представлены широким спектром . Но что, если нам надо еще больше? Что если, прямо на уровне сервера, без изменения кода приложения, можно в реальном времени видеть, что именно клиенты добавляют в корзину, строить гистограммы времени ответа бэкендов, или подсчитать буквально что угодно и делать это с производительностью атомарных операций в памяти? Сегодня разбираем мощнейший модуль metric в Angie.

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

#Angie #WebServer #Мониторинг #DevOps #Observability #API #Метрики #СистемныйАдминистратор #Бэкенд

Как не попасть пальцем в небо: принятие решений на основе данных

В управлении почти всегда есть отчёты, дашборды и десятки показателей — и при этом решения всё равно принимаются «по ощущениям». Почему так происходит и где именно рвётся связь между данными и реальными действиями? В статье разбираем, что такое data-driven подход на практике: от управленческих ошибок и зрелости аналитики до экономических моделей и проверки гипотез, которые действительно влияют на бизнес.

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

#gartner #datadriven #datadriven_decisions #datadriven_решения #Datadriven_management #управленческие_решения #управленческие_ошибки #метрики #дашборды

Импакт под прикрытием: почему российские ИТ-гиганты стесняются называть свои продукты социальными

В российском ИТ сложилась парадоксальная ситуация. Мы строим умные города, цифровизируем образование, переводим госуслуги в проактивный режим. Мы тратим миллиарды на импортозамещение и искусственный интеллект. Но никто не называет это импакт-проектами. Почему термин, который на Западе давно стал мейнстримом в ESG-отчётности и венчурных фондах, в российских ИТ-командах вызывает либо недоумение, либо подозрение в ненаучной благотворительности? Российские ИТ-проекты уже давно работают как импакт, просто мы не умеем это измерять и правильно упаковывать. А значит — теряем деньги, репутацию и влияние.

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

#импакт #esg #цифровизация #гостех #управление_проектами #метрики #социальный_эффект

Созвоны как токсин, но не яд: как я выкинул половину встреч и впервые за долгое время перестал умирать к вечеру

Я жил в календаре. Встреча, встреча, статус, синк, планирование, разбор, созвон про созвон. В какой то момент я понял, что я не работаю, я просто пересаживаю мозг с темы на тему, а вечером у меня остается ноль сил и ощущение, что я весь день был занят чем то важным, но прод не стал лучше. В этой статье я расскажу, как я технически расковырял проблему встреч, как мы измеряли созвоны, как резали их без боли, какие правила сработали, какие сломались, и как сделать так, чтобы команда не превращалась в выжатый лимон. Будет много прагматики, три больших куска кода, и несколько приемов, которые я до сих пор считаю читерскими. У тебя тоже бывает такое, что после трех созвонов подряд ты смотришь в IDE и не понимаешь, кто ты и что тут происходит? Я раньше думал, что это я слабый и не умею держать фокус. Потом заметил, что в дни без встреч я вдруг становлюсь почти гением, а в дни с встречами я максимум могу переименовать переменную и забыть, зачем. Самое обидное, что встречи сами по себе не зло. Иногда созвон реально экономит неделю переписок и спасает проект от глупой ошибки. Проблема начинается, когда встречи становятся дефолтом. Типа, если непонятно что делать, давай созвонимся. Если кто то переживает, давай созвонимся. Если надо показать прогресс, давай созвонимся. И вот у тебя команда, где календарь решает, кто сегодня продуктивный. Я не тимлид, я тот самый человек, который сначала ноет, потом идет ковыряться, потом приносит штуку, которая вроде бы странная, но внезапно работает. Так и получилось: я пришел к ребятам не с мотивационной речью, а с цифрами, логами и инструментами.

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

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

Метрики технического долга в ИБ

Представьте ситуацию: директор спрашивает про состояние информационной безопасности, а вы отвечаете — «Мы закрыли 100 уязвимостей за квартал». Звучит солидно. Для бизнеса же это почти ничего не значит. Руководству важнее понимать, насколько снизился риск и работает ли вообще то, на что компания тратит деньги. Поговорим о метриках технического долга в ИБ, которые помогают ответить на эти вопросы и перевести ценность безопасности на язык, понятный бизнесу.

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

#метрики #технический_долг #метрики_ИБ #управление_рисками #уязвимости #MTTR