Как приоритезировал проблемы?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Как приоритизировал проблемы?
Приоритизация проблем (баги, issue, проблемы с UX) — это постоянная работа Product Manager. Проблемы приходят со всех сторон: support tickets, user feedback, внутренние наблюдения, метрики падают. Нужно решить, какую проблему атаковать первой, а какую отложить.
Типы проблем
Сначала я разделяю проблемы на категории:
Критичные баги (Production Issues)
- Пользователи не могут купить (checkout не работает)
- Данные теряются (user profile удаляется случайно)
- Security/privacy issue (люди видят чужие данные)
- App crashes
Эти решаются в ПЕРВУЮ очередь, иногда в течение часа.
Значительные проблемы (Major Issues)
- Медленная загрузка страницы (> 5 сек вместо 2)
- Неочевидный UX (люди не понимают, как использовать)
- Потеря функционала (кнопка работала, теперь нет)
- High complaint rate (много юзеров жалуются)
Эти решаются в текущем спринте или следующем.
Маленькие проблемы (Minor Issues)
- Опечатки в тексте
- Дизайн не совпадает с mockup на 2%
- Edge case (3 пользователя столкнулись с проблемой)
- Улучшения (было бы неплохо)
Эти могут ждать месяцы или решаться попутно.
Фреймворк приоритизации
Для каждой проблемы я считаю 2 вещи: IMPACT и EFFORT.
IMPACT (Влияние)
Влияние на пользователей и бизнес:
| Score | Определение | Примеры |
|---|---|---|
| 5 | Критичное: люди не могут использовать продукт вообще | Checkout сломан, app crashes, security breach |
| 4 | Высокое: часть пользователей не может использовать | Медленная загрузка (50% уходят), баг на мобиле (40% базы) |
| 3 | Среднее: пользователи могут использовать, но с трудом | Неочевидный UX, требует дополнительных кликов, confusing |
| 2 | Низкое: маленькое раздражение, не блокирует использование | Опечатка, неправильный цвет, edge case с 1% users |
| 1 | Очень низкое: едва заметно | Не совпадает с mockup на 5 пикселей |
EFFORT (Усилия)
Сколько времени потребуется на исправление:
| Score | Время | Примеры |
|---|---|---|
| 1 | < 1 часа | Исправить опечатку, поменять цвет кнопки, убрать лишний div |
| 2 | 1-4 часа | Исправить алгоритм сортировки, оптимизировать запрос |
| 3 | 4-24 часа (1 день) | Переделать компонент, добавить validation |
| 5 | 1-3 дня | Переделать функцию, добавить интеграцию |
| 8 | 3-7 дней | Значительный redesign, новая фича |
| 13 | 1-2 недели | Рефакторинг большого куска кода, новая архитектура |
Матрица приоритизации
IMPACT
5 │ ▓▓▓▓▓ │ ▓▓▓ │ ▓ │ ░ │ ░
│ Crisis│ Very│High │ Med │ Low
4 │ ▓▓▓▓ │ ▓▓▓ │ ▓▓ │ ░ │ ░
│ ASAP │ This│Next │Skip │ Skip
3 │ ▓▓▓ │ ▓▓ │ ▓ │ ░ │ ░
│ Today │Week│Later│ Skip│ Never
2 │ ▓▓ │ ▓ │ ░ │ ░ │ ░
│ Maybe │Maybe│ Nope│ Nope│ Never
1 │ ░ │ ░ │ ░ │ ░ │ ░
│ Never │Never│ Never Never│ Never
├───────┼─────┼──────┼────┼─────
1-2 3 5 8 13
EFFORT
Легенда:
- ▓▓▓ = FIX IMMEDIATELY (фикс в эту секунду)
- ▓▓ = FIX THIS WEEK (в текущий спринт)
- ▓ = FIX LATER (в roadmap, когда будет время)
- ░ = MIGHT FIX (если будет time, но не обязательно)
- пусто = NEVER FIX (это не стоит делать вообще)
Примеры из реальной жизни
Пример 1: "Checkout не работает на Safari"
- IMPACT: 4 (Safari — 15% трафика, люди не могут купить)
- EFFORT: 3 (нужно исправить JavaScript ошибку, могу повтори на мак)
- Матрица: IMPACT 4 + EFFORT 3 = FIX THIS WEEK ✓
- Решение: Приоритет в текущий спринт, фиксим завтра утром
Пример 2: "Опечатка в курсе 'Маркетинг'"
- IMPACT: 1 (это просто текст, не влияет на функционал)
- EFFORT: 1 (просто поменять одно слово в базе)
- Матрица: IMPACT 1 + EFFORT 1 = MAYBE (можно попутно)
- Решение: Не приоритет, но если инженер заканчивает рано — может пофиксить
Пример 3: "Страница курса грузится 4 секунды"
- IMPACT: 4 (30% пользователей уходят из-за медленной загрузки — это факт)
- EFFORT: 5 (нужна оптимизация БД, кэширование, возможно рефакторинг)
- Матрица: IMPACT 4 + EFFORT 5 = IMPORTANT, BUT NOT URGENT (FIX NEXT SPRINT)
- Решение: В следующий спринт выделяем инженера на оптимизацию
Пример 4: "Люди жалуются, что не понимают как купить в рассрочку"
- IMPACT: 3 (среднее, люди могут купить в рассрочку, но некоторые путаются)
- EFFORT: 3 (нужно улучшить UX, может быть добавить tooltip, переписать текст)
- Матрица: IMPACT 3 + EFFORT 3 = DO THIS SPRINT OR NEXT (планируем)
- Решение: Запускаем A/B тест с лучшей UX
Пример 5: "Dashboard выглядит не как в Figma mockup (расстояние между элементами 4px вместо 5px)"
- IMPACT: 1 (это дизайнерское совершенство, пользователи не заметят)
- EFFORT: 2 (нужно отредактировать CSS)
- Матрица: IMPACT 1 + EFFORT 2 = NEVER FIX (это пустая трата времени)
- Решение: Дизайнер, это не важно, давайте сосредоточимся на других проблемах
Дополнительные факторы приоритизации
1. Strategic Alignment (Стратегическое выравнивание)
Если проблема мешает ключевой метрике компании, она автоматически повышается в приоритете.
Пример:
- CEO сказал: "Наша главная метрика в этом квартале — увеличить retention"
- Проблема: "Люди удаляют аккаунт, потому что нет кнопки delete"
- Приоритет: ПОВЫШАЕТСЯ (хотя IMPACT может быть низкий)
2. Frequency (Частота)
Если проблему видят много пользователей, она важнее, чем если её видит 1 человек.
Пример:
- Проблема 1: 1000 пользователей не видят кнопку "Купить"
- Проблема 2: 5 пользователей видят ошибку в браузере Internet Explorer 6
- Приоритет: Проблема 1 выше (даже если обе IMPACT=5)
3. Дорогостоящесть для компании
Если проблема приводит к потере денег (отток клиентов, потерянные продажи), она приоритезируется выше.
Пример:
- Проблема 1: Посредственный UX на странице курса (может потерять 5% конверсии = $50K в месяц)
- Проблема 2: Опечатка в bio преподавателя
- Приоритет: Проблема 1 намного выше
4. Easy wins (Низко висящие фрукты)
Если можно быстро 80% значимо повлиять на метрику с минимальными усилиями — это делаешь в первую очередь.
Пример:
- Проблема: Люди говорят, что не видят курсы "Для начинающих"
- Решение: Добавить один фильтр (effort = 1 час)
- IMPACT: может быть 3, но с минимальными усилиями
- Приоритет: ВЫСОКИЙ (easy win)
Процесс приоритизации в команде
Я не приоритизирую один в кабинете. Обсуждаю с командой:
Еженедельная "Triage meeting" (30-40 минут)
Участники: PM, Engineering lead, QA lead, иногда дизайнер
Процесс:
- Я показываю список из 10-20 новых проблем (из support, аналитики, code review)
- Для каждой проблемы:
- Описываю что это
- Даю оценку IMPACT и EFFORT
- Слушаю мнение инженеров (может быть их оценка effort другая)
- Приходим к консенсусу: urgent, important, later, never
- Обновляем Jira с приоритетом
Пример Triage Meeting
PM: "Проблема 1: Checkout медленно грузится на 4G сети"
Lead Engineer: "Согласен, это важно. Сколько % пользователей на 4G?"
PM: "Примерно 25% из мобильных"
Lead Engineer: "Effort, наверное, 5-8 дней для оптимизации"
PM: "IMPACT 4, EFFORT 5-8 = Next sprint, давайте запланируем"
PM: "Проблема 2: Support говорит, что люди путаются с процессом оплаты"
Designer: "Я видела сессионные recordings, да, много людей кликают не туда"
Lead Engineer: "Может быть, это просто плохая копия? Effort 2-4 часа?"
PM: "Давайте A/B тест с лучшим текстом. IMPACT 3, EFFORT 4 = This sprint"
PM: "Проблема 3: Один пользователь говорит, что button на iPhone X за notch"
Lead Engineer: "Это edge case, effort 1 час, но влияет на < 2% users"
PM: "IMPACT 1, EFFORT 1 = Если время будет, fix poppy"
Как я коммуницирую приоритет
Когда решение принято, я очень четко объясняю ПОЧЕМУ эта проблема важнее.
Плохо: "Чувакам, нам нужно первым делом пофиксить скорость страницы курса"
Хорошо: "Чувакам, скорость страницы курса — IMPACT 4 потому что 30% пользователей на медленной сети уходят. EFFORT 5-8 дней потому что нужна оптимизация БД. Это значит меньше покупок и меньше денег. Я приоритизирую это в следующий спринт, потому что это даст нам наибольший ROI (1 день работы = $20K потенциальной потерянной прибыли в месяц)"
Чеклист для приоритизации проблем
## Для каждой новой проблемы спрашиваю:
### IMPACT: Как сильно это влияет на пользователя и бизнес?
- [ ] Сколько % пользователей это затрагивает? (1%, 10%, 50%, 100%)
- [ ] Это блокирует основной функционал (покупку, обучение)?
- [ ] Это приводит к потере денег? Насколько?
- [ ] Это security/privacy issue?
- [ ] Это вызывает жалобы в support? Сколько?
### EFFORT: Сколько времени потребуется?
- [ ] Это просто (< 1 часа) или сложно (> неделю)?
- [ ] Какие зависимости? (нужны ли другие fix перед этим)
- [ ] Какой риск регрессии? (может сломать другое)
- [ ] Нужен ли code review, QA, deployment?
### STRATEGIC ALIGNMENT
- [ ] Это совпадает с квартальными целями?
- [ ] Это мешает roadmap?
- [ ] Это просьба от важного клиента?
### FREQUENCY
- [ ] Сколько пользователей жалуются в месяц?
- [ ] Это новая проблема или хроническая?
- [ ] Это растет или уменьшается?
### BUSINESS VALUE
- [ ] Сколько денег потеряем, если не поправим? (в месяц)
- [ ] Сколько денег выигрываем, если поправим? (в месяц)
- [ ] ROI = (Business value / effort) — высокий ли ROI?
Итог
Приоритизация проблем — это баланс:
- IMPACT vs EFFORT — матрица помогает не делать по очереди, а выбирать smart
- Frequency vs Severity — одна проблема у многих vs одна большая проблема
- Strategy vs Triage — работаем на квартальные цели, но откликаемся на критичные проблемы
- Data-driven vs Common sense — слушаем метрики, но и интуицию инженеров
- Communication — всегда объясняю ПОЧЕМУ, это повышает buy-in от команды
Когда делаешь это правильно, команда знает, что делать в первую очередь, и не тратит время на неважные проблемы. И пользователи видят, что проблемы решаются быстро и эффективно.