Какие использовать метрики В прошлый раз я написал, что вместо того, чтоб давать негативную обратную связь и критиковать сотрудников, лучше использовать для этого прозрачные метрики, которые сами покажут реальное состояние дел. Тогда, если дела идут не очень, можно вместе с сотрудником сформировать коалицию по решению проблемы, то есть быть на одной стороне против проблемы, тогда как при критике всегда будет ситуация «сотрудник против менеджера». Сегодня расскажу про свой опыт, какие метрики устанавливать и какие принципы при этом использовать. Самая важная задача менеджера — это создавать единую картину будущего для своей команды. Другими словами, ставить цели и создать условия для их достижения командой (другая самая важная задача — это создать команду, и третья — создать условия для совместной работы (планирование, бюджеты, контроль и т. д.)). Таким образом, главная метрика, которую нужно отслеживать, — это приближение к этой амбициозной цели. Если ты руководитель проекта — это завершение проекта, если владелец продукта — это прибыль от твоего продукта, и т. д. Эта метрика сформулирована с позиции outcome или impact, то есть конкретно той пользы, которую получит организация от достижения цели (кстати, это ровно то, что в OKR стоит за буквой O — Objective). Вряд ли эта метрика будет меняться ежедневно, но следить за ней нужно, например, ежемесячно/раз в пару недель: как изменился P&L продукта или насколько проект приблизился к успешному запуску. Далее нам нужны более операционные метрики, чтобы отслеживать прогресс ежедневно/еженедельно. В этом случае нам нужно отслеживать output, то есть что именно делает команда для достижения цели. Для проектов можно использовать фреймворк p3.express — отслеживать выполнение недельного плана (plan vs fact), планировать задачи для корректировки, реагировать на обратную связь от стейкхолдеров и т. д. На ежедневном уровне — отслеживать выполнение задач (Jira и т. д.). Для продуктов и вообще разработки за еженедельные/ежемесячные можно взять метрики из DORA (lead time, deploy frequency, fail rate, recovery time) и следить за тем, чтобы они постепенно улучшались. На ежедневном уровне — вся та же Jira и выполнение задач в срок (для этого задачи должны быть длительностью < 1 дня, чтоб было что отслеживать). Понимаю, что пост весьма высокоуровневый (готов уйти в детали в комментариях или других постах) и не отвечает на вопрос: а как сказать сотруднику, что он упырь и идиот и его подготовленная презентация (написанный код, заваленный проект) — полная фигня? Но в этом и суть метода: если сотрудник делает не то, что приближает нас к идеальному будущему, то, скорее всего, виноват руководитель — либо цель (глобальную или конкретную задачу) неправильно поставил, либо допустил, что в команде есть упыри и идиоты. Поэтому и давать негативную обратную связь стоит, только если попросят, иначе (для своей команды) это выстрел себе же в ногу.