Расскажи про свой опыт приоритизации задач

Опыт приоритизации задач: как не утонуть в backlog

Контекст: хаос приоритетов

В одной компании я столкнулся с ситуацией:

Проблема:

• 200+ задач в backlog
• Каждый день CEO говорит что-то новое это "priority"
• Разработчики не знают над чем работать
• Каждую неделю приоритеты менялись
• Ничего не доделывалось

Это был кризис управления backlog.

Мой первый опыт с неправильной приоритизацией

Что я делал:

Я создал простой scoring:

Приоритет = (Impact + Urgency) / (Complexity + Time)

Пример:
- Task A: Impact=10, Urgency=10, Complexity=1, Time=1 → Score = 20
- Task B: Impact=5, Urgency=5, Complexity=10, Time=20 → Score = 0.5

TaskA имеет приоритет!

Проблема с этим подходом:

Этот scoring игнорировал:

• Стратегические цели компании
• Зависимости между задачами
• Ресурсы команды
• Risk и mitigation
• Customer satisfaction

Оказалось, что мы делаем много quick wins, но не решаем стратегические проблемы.

Стандартные методы приоритизации, которые я освоил

Метод 1: MoSCoW (Must, Should, Could, Won't)

100 задач в backlog.
Оставляем:

MUST (обязательно): 20 задач
- Без них система не работает
- Critical bugs
- Security issues

SHOULD (нужно): 40 задач
- Улучшают функциональность
- Улучшают performance
- Customer requests

COULD (можно): 30 задач
- Nice to have
- Улучшают UX
- Опциональные фичи

WON'T (не будем): 10 задач
- Отложить на потом
- Может быть next year

Плюсы:

• Простой и понятный
• Все понимают что важно

Минусы:

• Не показывает порядок внутри MUST
• Не учитывает dependencies
• Субъективный выбор

Метод 2: Weighted Scoring

Лучший метод для приоритизации.

Критерии:
1. Strategic Alignment (25%)
   - Помогает ли это стратегии?
   - Score: 1-5

2. Business Impact (25%)
   - Revenue? Users? Retention?
   - Score: 1-5

3. Customer Impact (20%)
   - How many users affected?
   - Pain level?
   - Score: 1-5

4. Effort Required (15%)
   - Developers needed
   - Time
   - Score: 1-5 (inverted, lower is better)

5. Risk/Complexity (15%)
   - Can break something?
   - Technical debt?
   - Score: 1-5 (inverted)

Пример расчета:

Task: Add dark mode

1. Strategic Alignment: 3/5 × 25% = 0.75
2. Business Impact: 2/5 × 25% = 0.50
3. Customer Impact: 4/5 × 20% = 0.80
4. Effort Required: 2/5 × 15% = 0.30 (lower effort = higher score)
5. Risk: 2/5 × 15% = 0.30

Total: 2.65 / 5 = 53%

Task: Fix critical security bug

1. Strategic Alignment: 5/5 × 25% = 1.25
2. Business Impact: 5/5 × 25% = 1.25
3. Customer Impact: 5/5 × 20% = 1.00
4. Effort Required: 4/5 × 15% = 0.60 (more effort, lower)
5. Risk: 1/5 × 15% = 0.75 (less risk, higher)

Total: 4.85 / 5 = 97%

Ясно кто имеет приоритет!

Метод 3: RICE Scoring (от Intercom)

RICE = (Reach × Impact × Confidence) / Effort

Reach: How many users affected in 3 months?
Impact: How much impact on each user (1-3: minimal, 5: massive)
Confidence: How confident are we? (0.1-1.0)
Effort: Person-months of work

Пример:

Feature A: Add notifications
- Reach: 10,000 users
- Impact: 2 (medium)
- Confidence: 80% = 0.8
- Effort: 2 person-months

RICE = (10,000 × 2 × 0.8) / 2 = 8,000

Feature B: Dark mode
- Reach: 50,000 users
- Impact: 1 (small)
- Confidence: 100% = 1.0
- Effort: 1 person-months

RICE = (50,000 × 1 × 1.0) / 1 = 50,000

Дарк mode имеет больший RICE!

Но... это подразумевает, что user value вычисляется только как количество людей.
Это может быть неправильно, если 10k users готовы платить.

Мой собственный метод приоритизации

После опыта с несколькими методами, я разработал собственный подход:

FART Framework:

F - Financial Impact
A - Alignment to strategy
R - Risk mitigation
T - Team capacity & Time

1. Financial Impact (40%)

Прямой вопрос: сколько денег это принесёт/сэкономит?

Элемент: Экспортировать отчёты
- Сейчас: клиенты просят ручной экспорт
- Это требует 2 часа работы Support каждый день
- 2 часа × $50/час × 250 рабочих дней = $25,000/год
- Time to implement: 5 дней = $5,000 cost
- ROI: 5x за 1 год
- Score: 9/10

Элемент: Улучшить шрифты
- Прямой финансовый impact: $0
- Косвенный (улучшить UX, retention): трудно оценить
- Score: 3/10

2. Alignment to Strategy (30%)

Стратегия компании на 2024: "Стать #1 в enterprise B2B"

Элемент: Single Sign-on (SSO) для enterprise
- Прямо поддерживает стратегию
- Enterprise клиенты требуют SSO
- Это differentiator
- Score: 10/10

Элемент: Add emojis to comments
- Не поддерживает стратегию
- Enterprise не нужно
- Score: 1/10

3. Risk Mitigation (20%)

Что может упасть/сломаться?

Элемент: Обновить PostgreSQL версию
- Сейчас на v9 (end of life)
- Риск: security issues, no support
- Обновление критично
- Score: 10/10

Элемент: Перейти на новый UI framework
- Текущий framework работает
- Нет immediate risk
- Score: 2/10

4. Team Capacity (10%)

Может ли наша команда это сделать?

Элемент: Add real-time notifications
- Требует: 3 developer, 2 months
- У нас есть: 5 developers
- Current load: 30% capacity
- Можем ли сделать? ДА, начать через неделю
- Score: 9/10

Элемент: Rebuild on new architecture
- Требует: 5 developers, 6 months
- У нас есть: 5 developers
- Current load: 80% capacity
- Можем ли сделать? НЕТ, нужна другая команда
- Score: 1/10

Итоговый расчет:

Приоритет = (F×0.4) + (A×0.3) + (R×0.2) + (T×0.1)

Экспорт отчётов:
- F: 9 × 0.4 = 3.6
- A: 5 × 0.3 = 1.5
- R: 3 × 0.2 = 0.6
- T: 9 × 0.1 = 0.9
Итого: 6.6/10 — HIGH PRIORITY

SSO for enterprise:
- F: 7 × 0.4 = 2.8
- A: 10 × 0.3 = 3.0
- R: 6 × 0.2 = 1.2
- T: 4 × 0.1 = 0.4
Итого: 7.4/10 — CRITICAL (но низкая team capacity, нужен extra resource)

Emojis in comments:
- F: 1 × 0.4 = 0.4
- A: 2 × 0.3 = 0.6
- R: 1 × 0.2 = 0.2
- T: 9 × 0.1 = 0.9
Итого: 2.1/10 — LOW PRIORITY, может быть nice-to-have

Процесс приоритизации, который я внедрил

Monthly Review Meeting

Кажди месяц (последний день) собираю:
- Product Manager
- CTO (техническое видение)
- VP Sales (customer feedback)
- Finance (budget constraints)
- Team leads (capacity)

Порядок дня:

1. Review текущие приоритеты (15 минут)
   - Что реально произошло?
   - Задачи изменили приоритет?
   - Why?

2. Review новые requests (30 минут)
   - PM презентует 5-10 новых идей
   - Обсуждение
   - Scoring по FART

3. Финальная приоритизация (30 минут)
   - Ranking в backlog
   - Обсуждение dependencies
   - Согласование timeline

4. Communicate (15 минут)
   - Всей команде показываем новый приоритет
   - Объясняем почему
   - Отвечаем на вопросы

Специальные техники для особых ситуаций

Ситуация 1: CEO каждый день меняет приоритеты

Что я делал:

1. Создал "Interrupt Queue"
   - CEO может добавить task в очередь
   - Но это НЕ immediate
   - Пересмотрим в следующий планирование

2. Установил правило
   - Максимум 1 interrupt per week
   - Если 2-3, нужна обсуждение

3. Дал CEO visibility
   - Dashboard который показывает capacity
   - "Если мы сделаем Task X, Task Y отложится на неделю"
   - CEO может выбрать trade-off

Результат: CEO перестал случайно менять приоритеты.
Он видит consequences.

Ситуация 2: Много customer requests противоречивы

10 customers просят 10 разных фич.
Они не совместимы.
Выбрать только одну.

Что я делал:

1. Взвешивание по revenue
   - Какие customers платят больше?
   - Их requests приоритет выше

2. Взвешивание по churn risk
   - Какой customer может уйти?
   - Его requirements kritical

3. Поиск common ground
   - Может быть одна фича решит 80% problems?
   - Можем ли мы сделать "foundation" для всех?

Пример:
Customer A: хочет экспортировать в Excel
Customer B: хочет экспортировать в PDF
Customer C: хочет экспортировать в Google Sheets

Общее решение:
- Сделать generic export framework
- Подключить Excel, PDF, Sheets
- Все happy

Ситуация 3: Technical debt vs new features

Product Manager хочет новые фичи.
Developer говорит нужно refactor.
Что выбрать?

Ответ: Это не "или", это "и".

Мой подход:
- Каждый sprint: 70% features, 30% technical debt
- Ratio может изменяться, но не ниже 20% для debt
- Technical debt не убивает velocity
- Но и features не отпадают

Когда менять ratio:
- Если bugs растут быстро: до 40% debt
- Если performance degrading: до 50% debt
- Если все broken: stop features, 100% fixes

Инструменты для приоритизации

1. Spreadsheet (Excel/Google Sheets)

Просто, видимо, легко:

ID | Title | Strategic | Impact | Effort | Risk | Total | Priority
---|-------|-----------|--------|--------|------|-------|----------
1  | SSO   | 10        | 8      | 6      | 7    | 8.0   | P0
2  | Dark  | 3         | 6      | 9      | 9    | 6.3   | P1
3  | Emoji | 1         | 2      | 9      | 9    | 3.1   | P3

2. Dedicated tool (Jira, Linear, Asana)

- Custom scoring fields
- Automatic ranking
- Easy to update
- Visible to team

3. Decision framework (Confluence page)

- Explain criteria
- Show scoring rubric
- Document decisions
- Historical reference

Результаты правильной приоритизации

Когда я внедрил FART framework:

До:

• 200+ items в backlog
• Priority менялась еженедельно
• 15% features completed
• Team деморализована
• Все confused

После (спустя 6 месяцев):

• 50 items в backlog (пересмотрели, 150 отложили на после)
• Priority stable, меняется раз в месяц
• 80% planned features completed
• Team знает что делать
• Stakeholders happy

Главные уроки

1. Priortization это не math, это conversation
   - Spreadsheet помогает, но не решает
   - Нужно обсуждение stakeholders
   
2. Говорите NO
   - Невозможно сделать всё
   - Чем больше всего хотят, тем яснее нужно сказать
   - "Yes, and..." → лучше чем "Yes"
   
3. Communicate decisions
   - Объясните ЧТО и ПОЧЕМУ
   - People accept decisions если они понимают reasoning
   
4. Re-evaluate regularly
   - Стратегия может измениться
   - New info может появиться
   - Priortity должна быть живой
   
5. Balance short-term и long-term
   - Нельзя только quick wins
   - Нельзя только long-term projects
   - Нужен баланс