#метрики_производительности — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #метрики_производительности, aggregated by home.social.
-
GitPulse: как я перестал угадывать, что происходит в команде, и начал смотреть на данные
Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте Читать
https://habr.com/ru/articles/1032902/
#Инженерная_аналитика #Team_Lead #метрики_производительности #метрики_кода #метрики_процесса #jira #Метрики_доставки #Инсайты #sprint
-
GitPulse: как я перестал угадывать, что происходит в команде, и начал смотреть на данные
Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте Читать
https://habr.com/ru/articles/1032902/
#Инженерная_аналитика #Team_Lead #метрики_производительности #метрики_кода #метрики_процесса #jira #Метрики_доставки #Инсайты #sprint
-
GitPulse: как я перестал угадывать, что происходит в команде, и начал смотреть на данные
Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте Читать
https://habr.com/ru/articles/1032902/
#Инженерная_аналитика #Team_Lead #метрики_производительности #метрики_кода #метрики_процесса #jira #Метрики_доставки #Инсайты #sprint
-
GitPulse: как я перестал угадывать, что происходит в команде, и начал смотреть на данные
Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте Читать
https://habr.com/ru/articles/1032902/
#Инженерная_аналитика #Team_Lead #метрики_производительности #метрики_кода #метрики_процесса #jira #Метрики_доставки #Инсайты #sprint
-
Почему важно мониторить поисковую систему: Manticore → Prometheus → Grafana
Один из наших пользователей недавно пришёл к нам со знакомой проблемой: поиск внезапно стал заметно медленнее, хотя внешне ничего явно не ломалось. Сервис работал, ошибок в логах не было, загрузка CPU выглядела нормально, но пользователи уже начали жаловаться, что поиск тормозит. Так обычно и проявляются проблемы с поиском в продакшене. Не как драматичный сбой, а как медленное, ползучее ухудшение. Чуть больше трафика здесь, чуть больше индексации там, и прежде чем вы это заметите, производительность уже просела. К тому моменту, когда пользователи это замечают, настоящая проблема нередко копится уже несколько часов. Без хорошей видимости остаётся только гадать: система перегружена? Одна таблица съедает ресурсы? Или незаметно что-то идёт не так? Вот почему мониторинг важен. С ним расплывчатое «поиск стал медленным» превращается в проблему, которую можно диагностировать и исправить.
https://habr.com/ru/articles/1023608/
#grafanaдашборд #prometheus #мониторинг #сбор_метрик #визуализация_метрик #высокая_производительность #метрики_производительности #оптимизация_производительности
-
Наблюдаемое нагрузочное тестирование: Locust + OpenTelemetry
Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение. Открыть разбор
https://habr.com/ru/companies/otus/articles/986734/
#нагрузочное_тестирование #наблюдаемость #observability #OpenTelemetry #распределённая_трассировка #трассировка_запросов #метрики_производительности #задержка_соединения #Locust
-
Наблюдаемое нагрузочное тестирование: Locust + OpenTelemetry
Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение. Открыть разбор
https://habr.com/ru/companies/otus/articles/986734/
#нагрузочное_тестирование #наблюдаемость #observability #OpenTelemetry #распределённая_трассировка #трассировка_запросов #метрики_производительности #задержка_соединения #Locust
-
Наблюдаемое нагрузочное тестирование: Locust + OpenTelemetry
Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение. Открыть разбор
https://habr.com/ru/companies/otus/articles/986734/
#нагрузочное_тестирование #наблюдаемость #observability #OpenTelemetry #распределённая_трассировка #трассировка_запросов #метрики_производительности #задержка_соединения #Locust
-
Наблюдаемое нагрузочное тестирование: Locust + OpenTelemetry
Нагрузочный тест показывает «в среднем 800 мс», а распределённый трейс приложения упорно говорит «300 мс» — и начинается традиционная игра в ручную корреляцию. В этой статье разбираем, как связать нагрузку и наблюдаемость: запускать Locust с OpenTelemetry так, чтобы каждый запрос теста оставлял трейсы и метрики, продолжал Trace ID в сервисах и давал картину транзакции «от генератора до базы». А заодно, почему самый важный кусок времени часто прячется ещё до входа в приложение. Открыть разбор
https://habr.com/ru/companies/otus/articles/986734/
#нагрузочное_тестирование #наблюдаемость #observability #OpenTelemetry #распределённая_трассировка #трассировка_запросов #метрики_производительности #задержка_соединения #Locust
-
CaptainBridge: опенсорс эффективных менеджеров
Привет, Хабр! Меня зовут Алексей Панаэтов, я технический лидер Центра геосервисов в МТС Web Services. Каждый руководитель рано или поздно задается вопросом о количественной оценке эффективности команды. Метрики помогают принимать решения объективно, но их очень сложно строить, когда в работе активно используются множества разных инструментов: трекеры задач, системы контроля версии, корпоративный мессенджер и другие. К ним нужно сначала получить доступ, затем выгрузить и обработать нужные данные. Ad-hoc-методы вроде csv-файлов и таблиц Excel подходят для разового анализа, но их тяжело поддерживать. Я тоже столкнулся с этой проблемой и для ее решения создал и выложил в открытый доступ код CaptainBridge — инструмент, который помогает собирать и строить метрики эффективности команды.
https://habr.com/ru/companies/ru_mts/articles/921132/
#метрики #метрики_производительности #метрики_тестирования #сторипоинты #agile #декомпозиция #велосити #Управление_разработкой #управление_проектами
-
Метрики для оценки эффективности команд на удаленке и не только
В далёкие славные времена мы все работали в офисе и оценка эффективности команды решалась постоянными вербальными контактами. В те времена вовлеченность команды оценивались не столько по цифровым показателям, сколько по времени нахождения всех участников разработки в одном помещении… В 2020 году мы, как и все, перешли на удаленку. Логично, что через некоторое время у менеджмента возник вопрос — насколько мы там эффективны? И второй, вытекающий из первого: что мы, как менеджмент, делаем для управления этой самой эффективностью? Для ответов одних бизнес-показателей, очевидно, недостаточно, — они не отвечают на вопрос на сколько эффективно мы растем в ИТ. Нам нужны были метрики производства с учетом методологий и процессов применяемых в организации. В конце концов, мы же хотим понять — эффективна удаленка или нет?
https://habr.com/ru/companies/alfa/articles/781654/
#эффективность_разработки #delivery_management #метрики_производительности #итерационная_разработка #управление_проектом
-
Гайд с видео: метрики в Monq от сбора данных до алертинга
Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этойстатье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид,что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.
https://habr.com/ru/companies/monq/articles/901028/
#метрики #метрики_производительности #метрики_продукта #метрики_тестирования #метрики_процесса #метрики_по #мониторинг #мониторинг_сервера #мониторинг_сети #мониторинг_логов
-
Мониторинг Web Vitals через Яндекс.Метрику: пошаговое руководство
Web Vitals — набор метрик от Google, которые показывают, насколько быстро и стабильно загружается ваш сайт, как плавно отображается контент и насколько оперативно интерфейс реагирует на действия пользователя. В этой статье вы найдёте пошаговую инструкцию по интеграции Web Vitals в проект, отправке метрик в Яндекс.Метрику и настройке отчётов для оперативного мониторинга. Благодаря этому вы сможете своевременно выявлять и устранять «узкие места» в работе приложения ещё до появления жалоб пользователей.
https://habr.com/ru/articles/911672/
#web_vitals #яндексметрика #vuejs #performance #мониторинг #аналитика #метрики_производительности #дашборды #frontend #javascript
-
Как посчитать производительность команды разработки?
Среди топ‑менеджеров, а также линейных руководителей в IT‑компаниях периодически возникает вопрос: является ли та или иная команда разработки производительной? Пытаясь ответить на этот вопрос, многие приходят в тупик, так как осязать цифровое производство крайне непросто, а уж измерить его — тем более! В данной статье мы с вами попробуем разобраться, каким образом все‑таки можно попробовать измерить производительность команды разработки . Также стоит подчеркнуть, что все описанное в статье уже применяется в IT компании Flang , в которой я на данный момент времени являюсь CTO.
https://habr.com/ru/articles/907432/
#эффективность_работы #управление_разработкой #управление_командой #измерение_производительности #метрики_производительности #процессы_разработки #процессы_управления #процессы_в_it
-
Гайд с видео: метрики в Monq от сбора данных до алертинга
Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этойстатье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид,что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.
https://habr.com/ru/companies/monq/articles/901028/
#метрики #метрики_производительности #метрики_продукта #метрики_тестирования #метрики_процесса #метрики_по #мониторинг #мониторинг_сервера #мониторинг_сети #мониторинг_логов
-
Гайд с видео: метрики в Monq от сбора данных до алертинга
Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этойстатье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид,что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.
https://habr.com/ru/companies/monq/articles/901028/
#метрики #метрики_производительности #метрики_продукта #метрики_тестирования #метрики_процесса #метрики_по #мониторинг #мониторинг_сервера #мониторинг_сети #мониторинг_логов
-
Гайд с видео: метрики в Monq от сбора данных до алертинга
Как получить от мониторинга уверенность, что ИТ-инфраструктура работает как надо? В этойстатье разберемся, как устроена работа с метриками в Monq: от их сбора и автоматической привязки к контекстным элементам до создания кастомных метрик и контроля качества покрытия. Поговорим о том, как быть уверенным, что система действительно «зеленая» — а не делает вид,что у вас все в порядке. А в конце статьи вас ждет видео с конкретным примером работы с метриками от А до Я.
https://habr.com/ru/companies/monq/articles/901028/
#метрики #метрики_производительности #метрики_продукта #метрики_тестирования #метрики_процесса #метрики_по #мониторинг #мониторинг_сервера #мониторинг_сети #мониторинг_логов
-
Немного рассуждений про метрики в менеджменте
Иллюстрация взята с slidesgo / Freepik Data Driven Management… Долго об этом думал, часто встречал на практике, часто подгорало и вот наконец я понял почему. Короткий ответ: из метрик делают карго культ и они теряют смысл. Стоит отметить, что я не противник метрик, скорее противник распространённого способа их использования. Ниже я раскрою свою мысль. Начнём с того, что такое метрики и любые систематизации (а-ля матрица компетенций): Метрики - это наша проекция реальности на какой-то набор координат или метрик. В 99% случаев их набор неполностью описывает реальность. Как понять полная система или нет? Если в реальности случается какое-то событие и оно может не отразиться на метриках - значит система не полная и мы всегда что-то упускаем. Найти такое событие обычно не сложно, часто вы видите на метриках, что Вася из вашей команды задумал покинуть команду? И я редко. Обычно это видно на персональных встречах... но это другая тема. Какое следствие может быть такой неполноты метрик? Конечно ошибки. Пример из геометрии - тело Штейнмеца . Если взять только две проекции (круги) и попробовать сделать вывод о форме, вероятно будет допущена ошибка. Теперь про то как с метриками работать Сразу обозначу, что это не про работу тимлидов, которые полностью погружены в свои команды, а про работу тех, кто ими руководит вверх по иерархии. Текущий подход требует от менеджеров починки проекций, а не самой формы. Например: сверху приходит пожелание о снижении lead time. Вероятно за этим пожеланием стоит одна из двух потребностей: либо не хватает прозрачности, либо кто-то хочет «мотивировать» команды быть продуктивнее. Что может сделать менеджер? Он может:
-
Немного рассуждений про метрики в менеджменте
Иллюстрация взята с slidesgo / Freepik Data Driven Management… Долго об этом думал, часто встречал на практике, часто подгорало и вот наконец я понял почему. Короткий ответ: из метрик делают карго культ и они теряют смысл. Стоит отметить, что я не противник метрик, скорее противник распространённого способа их использования. Ниже я раскрою свою мысль. Начнём с того, что такое метрики и любые систематизации (а-ля матрица компетенций): Метрики - это наша проекция реальности на какой-то набор координат или метрик. В 99% случаев их набор неполностью описывает реальность. Как понять полная система или нет? Если в реальности случается какое-то событие и оно может не отразиться на метриках - значит система не полная и мы всегда что-то упускаем. Найти такое событие обычно не сложно, часто вы видите на метриках, что Вася из вашей команды задумал покинуть команду? И я редко. Обычно это видно на персональных встречах... но это другая тема. Какое следствие может быть такой неполноты метрик? Конечно ошибки. Пример из геометрии - тело Штейнмеца . Если взять только две проекции (круги) и попробовать сделать вывод о форме, вероятно будет допущена ошибка. Теперь про то как с метриками работать Сразу обозначу, что это не про работу тимлидов, которые полностью погружены в свои команды, а про работу тех, кто ими руководит вверх по иерархии. Текущий подход требует от менеджеров починки проекций, а не самой формы. Например: сверху приходит пожелание о снижении lead time. Вероятно за этим пожеланием стоит одна из двух потребностей: либо не хватает прозрачности, либо кто-то хочет «мотивировать» команды быть продуктивнее. Что может сделать менеджер? Он может:
-
Немного рассуждений про метрики в менеджменте
Иллюстрация взята с slidesgo / Freepik Data Driven Management… Долго об этом думал, часто встречал на практике, часто подгорало и вот наконец я понял почему. Короткий ответ: из метрик делают карго культ и они теряют смысл. Стоит отметить, что я не противник метрик, скорее противник распространённого способа их использования. Ниже я раскрою свою мысль. Начнём с того, что такое метрики и любые систематизации (а-ля матрица компетенций): Метрики - это наша проекция реальности на какой-то набор координат или метрик. В 99% случаев их набор неполностью описывает реальность. Как понять полная система или нет? Если в реальности случается какое-то событие и оно может не отразиться на метриках - значит система не полная и мы всегда что-то упускаем. Найти такое событие обычно не сложно, часто вы видите на метриках, что Вася из вашей команды задумал покинуть команду? И я редко. Обычно это видно на персональных встречах... но это другая тема. Какое следствие может быть такой неполноты метрик? Конечно ошибки. Пример из геометрии - тело Штейнмеца . Если взять только две проекции (круги) и попробовать сделать вывод о форме, вероятно будет допущена ошибка. Теперь про то как с метриками работать Сразу обозначу, что это не про работу тимлидов, которые полностью погружены в свои команды, а про работу тех, кто ими руководит вверх по иерархии. Текущий подход требует от менеджеров починки проекций, а не самой формы. Например: сверху приходит пожелание о снижении lead time. Вероятно за этим пожеланием стоит одна из двух потребностей: либо не хватает прозрачности, либо кто-то хочет «мотивировать» команды быть продуктивнее. Что может сделать менеджер? Он может:
-
Немного рассуждений про метрики в менеджменте
Иллюстрация взята с slidesgo / Freepik Data Driven Management… Долго об этом думал, часто встречал на практике, часто подгорало и вот наконец я понял почему. Короткий ответ: из метрик делают карго культ и они теряют смысл. Стоит отметить, что я не противник метрик, скорее противник распространённого способа их использования. Ниже я раскрою свою мысль. Начнём с того, что такое метрики и любые систематизации (а-ля матрица компетенций): Метрики - это наша проекция реальности на какой-то набор координат или метрик. В 99% случаев их набор неполностью описывает реальность. Как понять полная система или нет? Если в реальности случается какое-то событие и оно может не отразиться на метриках - значит система не полная и мы всегда что-то упускаем. Найти такое событие обычно не сложно, часто вы видите на метриках, что Вася из вашей команды задумал покинуть команду? И я редко. Обычно это видно на персональных встречах... но это другая тема. Какое следствие может быть такой неполноты метрик? Конечно ошибки. Пример из геометрии - тело Штейнмеца . Если взять только две проекции (круги) и попробовать сделать вывод о форме, вероятно будет допущена ошибка. Теперь про то как с метриками работать Сразу обозначу, что это не про работу тимлидов, которые полностью погружены в свои команды, а про работу тех, кто ими руководит вверх по иерархии. Текущий подход требует от менеджеров починки проекций, а не самой формы. Например: сверху приходит пожелание о снижении lead time. Вероятно за этим пожеланием стоит одна из двух потребностей: либо не хватает прозрачности, либо кто-то хочет «мотивировать» команды быть продуктивнее. Что может сделать менеджер? Он может:
-
Ускорение Яндекс Трекера: в погоне за Velocity Index
Внутренний трекер задач — Яндекс Трекер — важная часть Яндекса. В нём хранятся почти все планы: от целей отделов, до тикетов поддержки. RPS на фронтенд измеряется сотнями, а количество хитов в месяц — десятками миллионов. При таком масштабе даже небольшие задержки могут становиться критичными, поэтому мы задались целью ускорить Трекер. Спойлер: всё получилось не совсем так, как мы ожидали. Но обо всём по порядку. Для измерения скорости сервисов в Яндексе используется метрика Velocity Index — это агрегация метрик Web Vitals ( FCP , LCP , TBT , INP , CLS ). Итоговое значение получается в диапазоне от 0 до 100 баллов. Хорошим результатом считается индекс больше 85. Мы поставили себе амбициозную цель: увеличить Velocity Index до 85, а заодно подлечить очевидные «узкие места» в скорости и ускорить всё, до чего сможем дотянуться. Но до заветных 85 баллов мы так и не добрались. И вот почему
https://habr.com/ru/companies/yandex/articles/1010280/
#фронтенд #скорость_загрузки_сайта #интерфейсы #метрики #метрики_производительности #оптимизация
-
Эффективный мониторинг облачных решений: переходим к очередям и клиент-серверному взаимодействию
Привет! На связи команда Yandex Monium , это вторая часть серии про эффективный мониторинг. Исторически Monium был разработан командой Yandex Infrastructure как внутренняя observability‑платформа и использовался для мониторинга критических сервисов внутри Яндекса. В прошлый раз мы рассказали о том, что важно знать про мониторинг в целом, а также рассмотрели подробнее асинхронные задачи. На примере кейса с таинственным зависанием задач мы увидели, как с помощью метрик можно определить не очевидную проблему, вызванную скрытым багом. Но вполне возможно, что у вас всё взаимодействие происходит через очереди, а не через асинхронные задачи. Далее в этой статье: — В первой части разберём кейсы на примере in‑memory‑очереди. Это также применимо для различных типов очередей, в том числе для Apache Kafka. — Во второй части перейдём к клиент‑серверному взаимодействию.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/1010874/
#Мониторинг #мониторинг_сервера #observability #golden_signals #sre #метрики #метрики_производительности #мониторинг_очередей
-
Как измерить работу системного аналитика: метрики, которые говорят на языке бизнеса
/tl;dr Бизнесу нужны рубли и проценты, а не слова про «выявление требований». Аналитик не кодит и не продаёт — как доказать, что он вообще что-то даёт? Цифрами. Минимум метрик: трудозатраты на требования, доработки после релиза, конверсия, средний чек, время отклика бизнеса, ROI аналитики. Начните с двух–трёх — трудозатраты, баги, конверсия. Остальное добавите позже. Сравнивать только «было» и «стало»: один и тот же функционал до и после переделки с аналитиком (например, при смене API). Иначе «задачи разные», «сезон другой» — и ваши цифры списывают на совпадение. Зафиксируйте базовый период, нормализуйте цифры (на релизы, команду, сложность), постройте тренд и переведите эффект в рубли. Один график «до/после» сильнее десяти слайдов про «мы поработали хорошо». ИИ и инструменты тоже измеримы: путь от требований до ТЗ сократился вдвое — считайте экономию в часах и рублях на фичу. Подставьте свои цифры — получите конкретный финансовый эффект. Метрики — не способ оправдаться, а способ показать вклад аналитика и улучшать процессы. Сначала измеряй, потом убеждай.
https://habr.com/ru/articles/992604/
#аналитика #метрики #метрики_производительности #системный_анализ
-
Эффективный мониторинг облачных решений: первые шаги от метрик к асинхронным задачам
Без мониторинга инфраструктуры и сервисов любая проблема с приложением становится сюрпризом, причём обычно неприятным, который случается в самый неподходящий момент. С помощью настроенного мониторинга мы можем обнаружить проблемы до того, как пользователи придут и начнут жаловаться. Меня зовут Юлия Рубцова, я ведущий менеджер продукта Yandex Monitoring. В этой серии статей я и мой коллега Владимир Гордийчук @gordiychuk рассказываем про реальные сценарии использования мониторинга облачных решений. Что вас ждёт: мы покажем, как настроить дашборды, быстро проверить гипотезы при расследовании инцидента, а в конце соберём лучшие практики для настройки мониторинга. Начнём с базы: что такое мониторинг, для чего он нужен, что такое золотые сигналы, как использовать гистограммы и перцентили. А уже затем рассмотрим сценарии мониторинга асинхронных задач.
https://habr.com/ru/companies/yandex_cloud_and_infra/articles/956666/
#observability #monitoring #golden_signals #sre #sreпроцессы #мониторинг #метрики #метрики_производительности
-
Дизайн-метрики, которые не бесят. Как мы начали считать эффективность и подружили дизайн с цифрами
Не так давно в моем календаре появилась встреча под названием «Эффективность дизайнеров». И это выглядело как личное оскорбление. Мы всегда работали по спринтам, закрывали задачи, и вопросов к нашей эффективности ни у кого не возникало. До этого дня. На встрече мне поставили задачу — разработать систему для подсчета производительности каждого дизайнера. Я была уверена, что это невозможно: разный профиль дизайнеров, разный объем проектов. В каких таких попугаях я должна считать, насколько эффективно отрисовал дизайнер MES-интерфейс или сгенерировал картинки для сайта?! И в целом, идея засунуть творчество в рамки Excel-таблицы казалась мне абсурдом, который убьет всю магию, превратит вдохновение в сухую отчетность и по итогам моя команда выгорит тотально. Но я ошибалась. Это было не концом, а началом истории о том, как самая ненавистная и абсурдная идея превратилась в главный инструмент, который понятен бизнесу. Но при этом защищает, а не угнетает команду.
https://habr.com/ru/companies/nlmk/articles/948130/
#метрики_производительности #эффективность_команды #jira #excel
-
Финтех: новый технологический цикл — показатели в реальном времени
Итак, в предыдущих статьях я разбирал проблематику нового финтеха в целом и вывел потребность в метриках. Общий подход описан в статье Финтех: новый технологический цикл и инструменты будущего на примере людей и метрик . Однако общие описания - это прекрасно, а конкретные рекомендации - еще лучше. Приступим. Метрики поддержки Метрики поддержки, с точки зрения бизнеса, скорее, относятся к репутационным метрикам и метрикам риска. А еще поддержка - мощный инструмент получения обратной связи от пользователей. Кто-то боится говорить о проблемах, но если вы подойдёте к этой задаче открыто и искренне, то получите ценнейшую информацию о пути развития своего продукта и сервиса. Поддержка покрывает важные бизнес-риски, такие как сбои, аварии, недостатки продукта и негативный пользовательский опыт. Всё это нагромождение рисков вполне можно разделить на две категории:
-
Метрики команды разработки
Заказчику задачи в конечном счёте всё равно, какой методологией управления разработкой пользуется команда исполнителей - точная дата получения результата для него важнее. Чтобы называть эту дату более обоснованно, необходимо понимать, как на самом деле работает команда: сколько поставляет задач, как долго проходит процесс анализа задачи перед взятием в работу, на каких этапах в целом происходит "застревание" задачи. Под катом - описание метрик и способы их расчёта.
-
Метрики команды разработки
Заказчику задачи в конечном счёте всё равно, какой методологией управления разработкой пользуется команда исполнителей - точная дата получения результата для него важнее. Чтобы называть эту дату более обоснованно, необходимо понимать, как на самом деле работает команда: сколько поставляет задач, как долго проходит процесс анализа задачи перед взятием в работу, на каких этапах в целом происходит "застревание" задачи. Под катом - описание метрик и способы их расчёта.
-
DORA для DevSecOps: как оценить эффективность процессов ИБ
Всем привет! Меня зовут Анастасия Арсеньева, я аналитик данных в Swordfish Security. Наша команда разрабатывает модуль визуализации метрик DevSecOps в рамках развития платформы AppSec.Hub. В предыдущих статьях мы рассказывали вам о том, как можно оценить риски ИБ, зрелость подхода Shift Left и эффективность обработки обнаруженных уязвимостей. Сегодня мы разберем еще один дашборд для оценки процессов безопасности в разработке и поговорим о проекции метрик DORA на DevSecOps.
https://habr.com/ru/companies/swordfish_security/articles/778568/
#devops #dora #devsecops #метрики_производительности #безопасная_разработка #дашборд #информационная_безопасность #appsec #аналитика