Метрики та KPI

Вхідні дані, результати роботи, наслідки

Метриками називають три різні типи чисел, і плутанина між ними є коренем більшості суперечок про вимірювання. Input — те, що команда безпосередньо контролює цього тижня. Output — те, що ця робота дала. Outcome — зміна в поведінці чи бізнес-результаті, яка з цього випливла.

Пастка є з обох кінців. Вимірюйте лише inputs — отримаєте зайняту команду без доказів, що це важливо. Вимірюйте лише outcome — отримаєте число, що рухається з причин, які нікому не приписати: маркетингові витрати, сезонність, збій у конкурента, — і команду, яка не знає, чи допомогла її робота. Робочий набір має один outcome як ціль і два-три inputs, на які команда справді може натиснути цього тижня.

Те саме розрізнення часто описують як випереджальні й запізнілі індикатори. Запізнілий каже, що вже сталося, — виручка, відтік, річне утримання — точно й запізно, щоб діяти. Випереджальний рухається раніше й передбачає це неідеально: скільки нових акаунтів завершили налаштування цього тижня, скільки команд запросили другого учасника. Керуєте ви за випереджальними, а судять вас за запізнілими, і вся складність у тому, що зв’язок між ними — це гіпотеза, яку доводиться постійно перевіряти заново.

Закон Гудхарта і чому його не обійти

Закон стверджує: коли показник стає ціллю, він перестає бути добрим показником. Це не цинізм щодо людей, а арифметика. Будь-яка метрика є проксі для того, що не можна виміряти напряму, і достатньо наполеглива оптимізація завжди знайде розрив між проксі та реальністю.

Практичний захист — це права колонка. Обмежувач — метрика, яку ви зобов’язуєтесь не погіршити, женучись за головною, і обирати його треба саме як те, що зламається, якщо ціль почнуть накручувати. Кожна головна метрика заслуговує на питання: якби хтось безжально оптимізував це і більше нічим не переймався, що б він зіпсував?

Варто уточнити, хто саме «накручує», бо закон зазвичай пояснюють так, ніби він про нечесних людей. Це не так. Більшість спотворень метрик роблять сумлінні люди, ухвалюючи локально розумні рішення: агент підтримки закриває тікет, бо таймер черги почервонів; інженер ділить зміну, бо тижневе число деплоїв на видноті. Поведінка йде за вимірюванням незалежно від чиїхось намірів — і саме тому відповіддю є краще вимірювання, а не розмова про цінності.

Два фреймворки, які варто знати

• HEART — для фічі

  Happiness, Engagement, Adoption, Retention, Task success. Від Google research; корисний тим, що змушує вийти за межі adoption до питання, чи спрацювало.

• AARRR — для воронки

  Acquisition, Activation, Retention, Referral, Revenue. Описує життєвий цикл користувача й показує, який етап протікає, перш ніж ви оптимізуєте не той.

Обидва є чеклістами для пошуку кандидатів, а не наборами для повного впровадження. Команда, що відстежує всі п’ять вимірів HEART для кожної фічі, генерує звіт, а не керує. Оберіть один-два, які змінили б рішення.

North Star метрика, чесно

Єдина метрика на всю компанію справді корисна для узгодження і справді небезпечна наодинці. Вона працює, коли вимірює доставлену цінність, а не активність: заброньовані ночі, а не виконані пошуки; прочитані повідомлення, а не надіслані. Вона провалюється, коли команда трьома рівнями нижче не може на неї вплинути — тоді це вже не ціль, а погода.

Виправлення — не менша North Star, а дерево вхідних метрик під нею. Розкладіть метрику на множники, що в неї складаються: для заброньованих ночей — скільки мандрівників шукає, яка частка знаходить прийнятне, яка частка з них завершує бронювання, як часто бронювання скасовують — і дайте кожній команді той множник, який вона може зрушити. Компанія зберігає одне число; кожна команда отримує те, що справді може змінити до п’ятниці.

Як читати число, не обманюючи себе

Більшість поганих рішень за метриками спричинена не хибною метрикою, а правильною метрикою, прочитаною неправильно. Чотири звички запобігають майже всьому цьому.

Когорти, а не зрізи

Зріз змішує тих, хто прийшов учора, з тими, хто прийшов три роки тому, тож зміна складу виглядає як зміна поведінки. Когорта групує користувачів за часом приходу й стежить за цією групою в часі, відділяючи «продукт став кращим» від «ми залучили інших людей». Число утримання без когорти за ним зазвичай відображає торішній маркетинг, а не цьогомісячний продукт.

Крива утримання — найінформативніший графік, який може намалювати більшість продуктів. Важливо не те, звідки вона починається, а чи вона виположується: крива, що вирівнюється на 30%, означає продукт, яким третина прибулих справді користується далі, і зростання накопичується на цій підлозі. Крива, що й далі спадає до нуля, означає, що кожен новий користувач зрештою йде, і жодне залучення цього не виправить — ви просто швидше наповнюєте відро з діркою.

Середнє — найменш корисна статистика

Середні ховають усе цікаве. Середнє завантаження сторінки в 800 мс може означати, що всі чекають 800 мс, або що 90% чекають 300 мс, а 10% — п’ять секунд, і проблемою є лише другий варіант, і лише він пояснює звернення в підтримку. Читайте медіану й 90-й або 95-й перцентиль разом: для всього, чого користувач чекає, саме хвіст і є тим досвідом, про який говорять.

Те саме стосується поведінки користувачів, де розподіли зазвичай далекі від симетричних. «Середня кількість сесій на користувача: 4» у продукті, де невелика група активних робить сорок сесій, а решта — одну, не описує взагалі нікого. Спершу сегментуйте, потім усереднюйте всередині сегмента — і ніколи навпаки.

Що каже і чого не каже результат A/B

Два правила рятують від більшості шкоди. Перше: визначте розмір вибірки й тривалість до початку і не дивіться на результат, щоб вирішити, коли зупинитися, — постійні підглядання й зупинка «коли гарно» частіше дають «перемогу» з чистого шуму, ніж ні. Друге: проганяйте щонайменше повний тиждень, щоб було представлено і будні, і вихідні.

І «незначущий» результат не є результатом «різниці немає». Він означає, що цей тест не зміг відрізнити ефект від шуму, — очікуваний наслідок, коли ефект малий, вибірка скромна або і те й інше. Чесне прочитання — «ми все ще не знаємо», і рішення тоді спирається на судження, ціну й зворотність, рівно як і до тесту.

Як це виявляється в реальній поставці

Метрика заслуговує на місце тим, що змінює рішення. Перевірка пряма: для кожного числа на дашборді назвіть рішення, яке пішло б інакше, якби воно змінилося на 20%. Більшість дашбордів втрачає дві третини вмісту на цьому питанні — і команді від цього краще: стіна чисел, за якими ніхто нічого не робить, привчає ігнорувати й ті, що важливі.

Де вони вироджуються

• Метрики марнославства — сукупні числа, що лише зростають і тому ніколи не сигналізують про проблему.
• Головна метрика без обмежувача — відкрите запрошення її накрутити.
• Немає записаного визначення — дві команди сперечаються про тренд у двох різних числах.
• Зрізи замість когорт — зміни в залученні читаються як зміни продукту.
• Середні, що ховають розподіл: медіана й 90-й перцентиль розповідають різні історії.
• Зупинка A/B-тесту, щойно він виглядає добре, — це виготовлення перемог із шуму.
• Метрики, прив’язані до оцінки окремих людей, псують число за один цикл рев’ю.

Коли це застосовувати

Пов’язані сторінки

• МенеджментProduct DiscoveryProduct discovery — це безперервна робота з визначення того, що варто будувати. Discovery не є фазою перед розробкою і не є збором вимог — це звичка щотижня говорити з користувачами й розкладати почуте як можливості, щоб рішення конкурували між собою, а не приходили вже вирішеними. На цій сторінці — тріо, дерево можливостей, карта припущень, чотири ризики й найдешевші перевірки для кожного.
• МенеджментРоадмапінгРоадмапінг — це робота з донесення того, куди рухається продукт і чому. Складне тут не намалювати таймлайн, а встояти перед проханням зафіксувати фічі за датами: це прив’язує вас до обсягу робіт саме тоді, коли ви найменше знаєте, чи спрацює задумане. На цій сторінці — формат на основі результатів, для кого який роадмап, як упорядковувати пункти і коли дата справді потрібна.
• МенеджментOKROKR (Objectives and Key Results) — це одна якісна ціль у парі з кількома вимірюваними результатами, які доводять, що її досягнуто. OKR — інструмент постановки цілей і узгодження; щойно вони стають списком задач чи оцінкою продуктивності, вони перестають працювати — і зазвичай саме їх у цьому й звинувачують. На цій сторінці — outcomes проти outputs, committed проти aspirational, каденція, оцінювання та відмінність від KPI.