Ситуация: приходишь к продакту с идеей рефакторинга, автотестов или quality gates. Кажется, всё логично: багов будет меньше, код улучшится, жить станет веселее. А в ответ: «Не сейчас».
Знакомо? Часто так бывает из-за того, что разработка объясняет задачу на техническом языке, а продукт принимает решения на бизнесовом — через эффект, метрики и приоритеты.
В какой-то момент для себя я понял: если хочется побеждать в этой игре, нужно уметь думать как продакт. По сути — стать продакт-менеджером технического бэклога.
Чтобы принять решение, ему нужно получить ответы на три вопроса:
🔴 Зачем мы это делаем?
🔴 Какой эффект это даст бизнесу?
🔴 Почему этим нужно заняться именно сейчас?
Ответить на них мне помогает фреймворк ICE
Это три коэффициента:
🔴 Impact — насколько сильно задача влияет на важную метрику
🔴 Confidence — насколько мы уверены в этой оценке
🔴 Ease — насколько задача проста в реализации
Для инженерных задач обычно сложнее всего оценить Impact. Здесь помогает разделение на два типа инициатив:
🔴 Операционные задачи улучшают то, что уже работает: багфиксы, ускорение страниц, quality gates, автотесты. Главные метрики для таких задач — уменьшение сбоев, скорость релиза, рост конверсии
🔴 Задачи роста открывают новые возможности: монетизация существующих и создание новых сценариев, эксперименты. Здесь мы говорим о сокращении TTM или о том, что эта инициатива станет энейблером для чего-то большего
Шкалы простые:
🔴 Impact: 1–2 — слабый эффект, 3–4 — локальное улучшение, 5–6 — заметное улучшение важного сценария, 7–8 — сильный эффект на ключевую метрику, 9–10 — большой эффект на стратегически важный показатель
🔴 Confidence: 0,1–0,2 — интуиция, 0,3–0,6 — есть аналоги у конкурентов, 0,7–0,8 — пилотный запуск, 0,9–1 — есть исторические данные или A/B-тест
🔴 Ease: 10 — пара часов, 5 — спринт, 1 — долго и сложно
Допустим, нужно выбрать между рефакторингом корзины и исправлением потери корзины при сбоях.
Для этого мы можем рассчитать ICE Score по формуле:
ICE Score = Impact × Confidence × Ease
Рефакторинг корзины: I = 10 — энейблер для других задач, C = 1 — провели ресёрч и написали ADR, E = 2 — проект большой.
ICE = 20
Исправление сбоев корзины: I = 8 — эффект чуть ниже, C = 1 — уверены в своей оценке, E = 9 — задача простая.
ICE = 72
Поэтому в работу логичнее брать вторую задачу.
❗️ Важно помнить, что ICE — это не точная математика, а язык разговора о приоритетах
Нельзя просто прийти к продакту со словами: «У меня тут ICE Score 72, значит, делаем». Но можно иметь на руках понятную логику: вот эффект, вот уверенность в оценке, вот стоимость и вот ответ на вопрос, почему эта задача сейчас в приоритете.
После этого техдолг, рефакторинги и автотесты перестают быть вечным «не сейчас» и становятся нормальными кандидатами на приоритизацию.
⏩️ А больше постов про разработку и управление командами можно найти в моём личном канале.
Подписывайтесь:
💬 @Yandex4Teamleads