Как бы вы приоритизировали ресурсы, если бы у вас были две важные задачи, но обе выполнить было бы нельзя?

Приоритизация ресурсов при конфликте двух важных задач

Это классическая ситуация в управлении продуктом — ресурсы ограничены, а требований больше. Раскажу, как я подхожу к такой ситуации и на что опираюсь при принятии решения.

Шаг 1: Правильный диагноз проблемы

Являются ли обе задачи действительно одинаково важны? Основная ошибка PM — считать, что "важно" = "urgently important". Часто одна задача кажется важной, но при анализе оказывается менее критичной.

Вопросы, которые задаю себе:

• Обе ли задачи влияют на стратегию, или одна — это тактическая? (стратегия имеет приоритет)
• Обе ли влияют на revenue, или одна — улучшение UX? (revenue обычно важнее)
• Обе ли срочны, или одна может ждать? (срочность — важный фактор)
• Какой downside если не сделать одну из них? (больший риск = выше приоритет)

Шаг 2: Оценка Impact vs Effort

Матрица приоритизации Для каждой задачи я оцениваю две оси:

• Impact (влияние): высокое, среднее, низкое. Как это повлияет на метрики (revenue, retention, growth, satisfaction)?
• Effort (усилия): сколько недель разработки нужно?

Практический пример:

Задача A: Интеграция с Salesforce (Enterprise требует)

• Impact: Высокий (может привести к 3 крупным сделкам)
• Effort: 4 недели
• Ratio: 3 deal / 4 weeks = высокий приоритет

Задача B: Полная переиндексация базы данных (технический долг)

• Impact: Средний (улучшит скорость на 30%, но неявно)
• Effort: 2 недели
• Ratio: умеренное улучшение / 2 weeks = средний приоритет

Вывод: Задача A имеет приоритет

Шаг 3: Анализ влияния на разные стейкхолдеры

Матрица stakeholders У разных людей разные интересы:

Консенсус vs争议 (несогласие) Если технический директор настаивает на Задаче B, это красный флаг. Может быть, есть hidden constraint, который я не вижу (например, БД готова упасть через 2 месяца).

Шаг 4: Альтернативные решения

Вопрос: можно ли сделать обе?

Вариант 1: Разделить команду

• Может ли один разработчик делать Задачу B, пока остальная команда делает Задачу A?
• Какова цена параллелизма (overhead, синхронизация)?
• Есть ли junior разработчик, который может взять Задачу B?

Вариант 2: Упростить одну из задач

• Можно ли сделать MVP Задачи A вместо полной интеграции? (Например, интеграция через API вместо native).
• Можно ли сделать Задачу B частично? (например, только для критичных таблиц).

Вариант 3: Отложить одну

• Если Задача B не критична для квартала, отложить на Q2.
• Если Задача A может ждать, но это "лучше сейчас", отложить и сфокусироваться на B.

Вариант 4: Использовать external ресурсы

• Можно ли хайрить контрактора для Задачи B (если она не требует глубокого знания кодовой базы)?
• Это стоит денег, но может быть оправдано, если Задача A генерирует значительный доход.

Шаг 5: Финальное решение

Мой процесс выбора:

1. Критичность: Есть ли deadline, который нельзя пропустить? (контрактное обязательство, конкурентное давление)

   • Если да для Задачи A → выбираю A
   • Если да для Задачи B → выбираю B

2. Стратегическое выравнивание: Что входит в наш OKR на этот квартал?

   • Если "расширить Enterprise аудиторию" → Задача A
   • Если "улучшить техническую стабильность" → Задача B

3. Risk: Какой downside если не сделать?

   • Потеря $100k revenue → выше, чем потеря performance
   • Но если система упадёт → потеря $1M → это higher risk

4. Возможность параллелизма: Можно ли разделить и минимизировать потери?

5. Stakeholder alignment: Согласны ли все с выбором?

Практический пример

Ситуация в моём предыдущем проекте:

• Задача A: Разработать mobile версию (CEO хочет, потенциал +100% пользователей)
• Задача B: Миграция на микросервисную архитектуру (CTO говорит, что текущая монолитность блокирует масштабирование)

Анализ:

• Impact A: Очень высокий, но неопределённый (может быть, мобильные пользователи не платят)
• Impact B: Среднее, но определённое (улучшит deployment cycle с 2 часов до 15 минут)
• Effort A: 8 недель (3 разработчика)
• Effort B: 6 недель (2 разработчика)

Мой выбор: Задача A

Обоснование:

1. Стратегия: мы нацелены на рост, mobile расширит рынок в 2x
2. Альтернатива B: CTO может оптимизировать текущую архитектуру на 4 недели (не полная миграция, но достаточно на этот квартал)
3. Risk: потеря мобильного рынка критичнее, чем медленный deployment
4. Alignment: CEO согласился, CTO неохотно, но понял логику

Результат: Запустили мобильную версию, пользователи выросли на 80%. Параллельно CTO начал предварительную работу над микросервисами, которую запустили в Q2.

Как я коммуницирую решение

Не просто выбираю, объясняю:

"Мы выбираем Задачу A, потому что:

• Прямой impact на revenue ($X)
• Входит в наш Q3 OKR на growth
• Risk потери competitive position выше, чем техдолг
• Задачу B оптимизируем и делаем в Q4, когда приоритеты другие"

Признаю trade-off: "Я понимаю, что это создаст техдолг. Давайте договоримся, что в Q4 мы выделим две недели на оптимизацию архитектуры."

Инволвирую заинтересованные стороны: CTO не будет чувствовать себя проигравшим, если я скажу: "Твоё замечание о техдолге валидно. Давайте вместе найдём, как его минимизировать не откладывая мобильную версию."

Типичные ошибки при приоритизации

Выбрать self-interested задачу Например, PM выбирает красивый feature, потому что нравится ему, а не потому что это лучше для бизнеса.

Игнорировать мнение expert Когда технический директор или опытный разработчик говорит, что техдолг критичен, нужно серьёзно слушать.

Не коммуницировать reasoning Люди не согласны не с решением, а с отсутствием логики. Если объяснить, примут.

Забыть про долгосрочные последствия Выбрал краткосрочный выигрыш (Quick fix), не посмотрев на архитектурное наследие.

Ключевой вывод

Приоритизация — это не математика, это искусство балансировать conflicting interests, ограниченные ресурсы и неопределённость. Успешный PM должен:

1. Быть data-driven — использовать metrics, impact estimates
2. Быть политически сознательным — понимать интересы разных stakeholders
3. Быть стратегическим — выбирать не просто "важное", а "важное для нашей стратегии"
4. Быть transparent — объяснять решение и trade-offs
5. Быть гибким — пересматривать при появлении новой информации

Лучший PM — это не тот, кто всегда выбирает "правильно", а тот, кто делает решение, может защитить его логикой и быстро адаптируется если оказалось неправильно.