Как объяснить топам, что у нас всё хорошо с качеством?
Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение SLA на исправление багов (aka zero bug policy);
- надёжность ключевых пользовательских сценариев (aka «девятки», 99.99);
- среднее время восстановления после сбоя (Mean Time to Recovery)
- скорость работы интерфейса (например, Time to Interactive, Freeze Time);
- и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью.
Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию.
Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой.
Для общей логики хорошо заходит идея: смотрим на то, насколько продукт кажется пользователю качественным. Её легко объяснить бизнесу.
А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов.
Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог:
Quality Score = Σ (вес метрики × значение метрики в шкале)
На выходе получаем один показатель, который отражает общую картину с качеством — и выглядит вполне понятным для бизнеса.
Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728
Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение SLA на исправление багов (aka zero bug policy);
- надёжность ключевых пользовательских сценариев (aka «девятки», 99.99);
- среднее время восстановления после сбоя (Mean Time to Recovery)
- скорость работы интерфейса (например, Time to Interactive, Freeze Time);
- и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью.
Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию.
Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой.
Для общей логики хорошо заходит идея: смотрим на то, насколько продукт кажется пользователю качественным. Её легко объяснить бизнесу.
А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов.
Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог:
Quality Score = Σ (вес метрики × значение метрики в шкале)
На выходе получаем один показатель, который отражает общую картину с качеством — и выглядит вполне понятным для бизнеса.
Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728
👍22🔥9❤7👏2
ChatGPT vs performance review
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?
Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.
Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.
Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂
А что нас ждёт дальше — с учётом того, как быстро развиваются модели?
С развитием агентности в моделях, я думаю, мы придём к полностью автоматической генерации самоотзыва.
Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.
Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?
Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.
Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.
Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂
А что нас ждёт дальше — с учётом того, как быстро развиваются модели?
С развитием агентности в моделях, я думаю, мы придём к полностью автоматической генерации самоотзыва.
Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.
Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...
👍18🔥5
В июле я выступил с докладом «Быть заметным и расти: как руководителю взять развитие в свои руки» на первой конференции Яндекса для тимлидов — Dream Team Lead. Делюсь ключевыми идеями и полезными материалами.
«Стеклянный тупик»
Многие руководители рано или поздно сталкиваются с этим ощущением: работаешь, стараешься, задачи усложняются, а роста — нет. Кто-то в такой момент ждёт, что его «заметят» или подскажут путь. Но, на мой взгляд, развитие — это зона личной ответственности.
Не обязательно идти на дорогое обучение — можно собрать кастомный план развития под себя. DIY-подход, который я сам использую и рекомендую другим.
Что помогает расти:
— Диагностика через матрицы компетенций
Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки:
• TL roadmap
• Avito Tech Lead Profile
• Dropbox Career Framework
— Развитие скиллов
Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами».
— Работа с майндсетом
Применять знания часто мешают внутренние барьеры — страх, самозванец, установки и т.п. Тесты вроде Hogan и Gallup помогают понять себя и дают инструменты для изменения.
— Окружение
Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать:
• GetMentor
• Solvery
• No Flame No Game (бот в Telegram)
• IT-мастермайнды
Где посмотреть доклад:
• VK Video
• YouTube
• Слайды
Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.
«Стеклянный тупик»
Многие руководители рано или поздно сталкиваются с этим ощущением: работаешь, стараешься, задачи усложняются, а роста — нет. Кто-то в такой момент ждёт, что его «заметят» или подскажут путь. Но, на мой взгляд, развитие — это зона личной ответственности.
Не обязательно идти на дорогое обучение — можно собрать кастомный план развития под себя. DIY-подход, который я сам использую и рекомендую другим.
Что помогает расти:
— Диагностика через матрицы компетенций
Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки:
• TL roadmap
• Avito Tech Lead Profile
• Dropbox Career Framework
— Развитие скиллов
Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами».
— Работа с майндсетом
Применять знания часто мешают внутренние барьеры — страх, самозванец, установки и т.п. Тесты вроде Hogan и Gallup помогают понять себя и дают инструменты для изменения.
— Окружение
Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать:
• GetMentor
• Solvery
• No Flame No Game (бот в Telegram)
• IT-мастермайнды
Где посмотреть доклад:
• VK Video
• YouTube
• Слайды
Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.
👍33🔥17❤6