Как принимал решение на чем фокусироваться из нескольких срочных дел?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Принятие решения при множественных срочных делах: фреймворк тайм-менеджмента
Контекст: парадокс срочности
Жизнь PM — это постоянный поток "срочных" дел. CEO зовёт в кабинет, клиент угрожает уходом, техника падает, инвестор просит отчёт. Всё срочно, всё сейчас. Если ты не научишься выбирать, ты сгоришь за месяц, а продукт будет в хаосе.
Я выучил это на своих ошибках. В одном стартапе я попытался делать всё одновременно, и ничего не сделал хорошо.
Сценарий: реальный день в жизни PM
День начинается нормально:
09:00 — Планирую день. На неделе запуск новой фичи, нужно доработать документацию.
10:30 — Срочный звонок от CEO: "У нас есть потенциальный контракт на $500k с Gazprom. Они просят кастомную интеграцию. Нужно обещать за час."
11:00 — CTO в Slack: "Сервер упал, 30% функционала недоступно. Нужна помощь PM в диагностике. Может быть, нужно отключить фичу X?"
11:30 — Support team: "10 клиентов пишут, что не работает платёж. Это срочно!"
12:00 — Другой CEO message: "Инвестор завтра хочет посмотреть Roadmap. Нужен красивый слайд про стратегию."
12:30 — Head of Sales: "У конкурента вышла новая фича, наши клиенты спрашивают. Нам нужно срочно ответить. Может быть, запустить что-то подобное?"
13:00 — Я чувствую панику. Всё горит. Что делать?
Правило: Не всё срочно
Первый инстинкт PM — "Всё критично, нужно делать всё!" Это ошибка.
Правда: только 20% проблем действительно срочные. 80% можно отложить на 1-2 дня.
Ключ — различить:
- Срочное: проблема существует СЕЙЧАС, нужно решение СЕЙЧАС
- Важное: проблема может привести к большим потерям, но можно отложить
- Не срочное и не важное: можно игнорировать
Фреймворк 1: Матрица Eisenhower (Срочное vs Важное)
ВАЖНОЕ
|
II | I
IMPORTANT|URGENT+IMPORTANT
NOT URGENT|(DO FIRST)
|
--------+--------
|
IV | III
NOT | URGENT
IMPORTANT| NOT IMPORTANT
NOT URGENT|(DELEGATE)
|
NOT URGENT
I (Urgent + Important) — потушить пожар
II (Important, Not Urgent) — предотвратить пожары
III (Urgent, Not Important) — делегировать
IV (Neither) — забыть
Применю фреймворк к моему дню
Задача 1: Сервер упал (30% функционала недоступно)
Срочность: ОЧЕНЬ СРОЧНО (сейчас теряем деньги) Важность: ОЧЕНЬ ВАЖНО (выживание продукта) Квадрант: I Моё действие:
- Не делаю сам (я не инженер)
- Делаю: созываю экстренный meeting (CTO + lead инженер)
- Мой вклад: помогаю определить приоритет (что отключить, чтобы сервер встал?)
- Время: 30 минут на meeting + decision, потом инженеры берут
Задача 2: Платежи не работают (10 клиентов жалуются)
Срочность: СРОЧНО (клиенты теряют деньги, уходят) Важность: ОЧЕНЬ ВАЖНО (это критичная функция) Квадрант: I Моё действие:
- Не решаю сам (техничеcкая задача)
- Делаю: даю Support'у информацию для ответа клиентам ("Это известная проблема, мы решаем в течение часа, извинитесь за неудобства, мы дадим бесплатный месяц")
- Время: 10 минут
Задача 3: Gazprom контракт на $500k (нужна кастомная интеграция)
Срочность: СРОЧНО (нужно ответить за час) Важность: ??? Анализ:
- Это реально $500k сделка или CEO надеется?
- Сколько времени нужна разработка? 1 неделя? 1 месяц? 6 месяцев?
- Это стратегический клиент или просто деньги?
Моё действие:
-
(Минута 1-5) Я звоню CEO: "Расскажи детали. Какая интеграция? Сколько времени?"
-
(Минута 5-10) CTO оценивает: "3 недели разработки"
-
(Минута 10-15) Я анализирую impact:
- Это нарушит запланированные фичи на 3 недели
- ROI: $500k за 3 недели = $166k per week = очень выгодно
- Но это отложит текущий roadmap
-
(Минута 15-20) Я говорю CEO: "Я могу предложить им: мы запускаем интеграцию за 3 недели. Но это означает, что запуск новых фич сдвинется на месяц. Это означает потеря 20 существующих клиентов, которые уходят на конкурента. Финансово: +$500k, но -$50k (потеря существующих). Net +$450k. Давайте делать."
Решение: Это реально важно и срочно (Квадрант I). Я берусь за это.
Задача 4: Конкурент запустил фичу, клиенты спрашивают
Срочность: СРЕДНЕЕ (клиенты спрашивают, но не уходят ещё) Важность: СРЕДНЕЕ (нужно ответить на конкуренцию, но это не критично) Квадрант: III или II (зависит от варианта ответа)
Мой анализ:
- Это можно отложить на 2-3 дня?
- YES → Квадрант II (Important but not urgent, делать после пожаров)
- NO → Квадрант III (Urgent, делегировать Sales team ответить на вопросы)
Моё действие:
- Делегирую Sales: "Ответьте клиентам: 'We have this on our roadmap, launching in 2 weeks'" (даже если это неправда, нужно время)
- Потом я добавляю в Roadmap как high priority
- Время: 5 минут на делегирование
Задача 5: Roadmap слайд для инвестора завтра
Срочность: СРОЧНО (завтра) Важность: ВАЖНО (инвестор = стратегический stakeholder) Квадрант: I или II (зависит от времени)
Мой анализ:
- У меня есть time? До конца дня
- YES → Я это делаю сегодня (I квадрант)
- Время: 1-2 часа
Задача 6: Документация для новой фичи (запуск на неделе)
Срочность: СРЕДНЕЕ (есть неделя) Важность: ВАЖНО (нужна для запуска) Квадрант: II (Important, not urgent)
Мой анализ:
- Это можно отложить на 2-3 дня?
- YES → Делаю после пожаров
- Время: 3 часа
Мой финальный план на день
10:00-10:30 (30 минут)
Сервер упал — экстренный meeting (I квадрант)
- Определяю приоритет
- Даю направление CTO
- Потом инженеры работают
10:30-10:40 (10 минут)
Платежи упали — даю Support'у скрипт ответа (I квадрант)
10:40-11:00 (20 минут)
Gazprom сделка — анализирую детали с CEO (I квадрант)
- Звоню CEO
- Спрашиваю CTO оценку
- Даю финальный ответ
11:00-12:00 (1 час)
Рoadmap слайд для инвестора (I квадрант)
- Создаю красивый слайд
- Согласовываю с CEO
12:00-13:00 (1 час)
Обеденный перерыв (критично!)
13:00-13:05 (5 минут)
Конкурент фича — делегирую Sales (III квадрант)
13:05-14:00 (55 минут)
Документация новой фичи (II квадрант)
- Начинаю её, но не суетью если будут перерывы
14:00+
Остальное время — резерв для new issues
Фреймворк 2: ICE (Impact, Confidence, Effort)
Когда нужно выбрать между несколькими важными делами (но все в квадранте I):
Score = (Impact × Confidence) / Effort
Пример:
У меня есть 3 критичные проблемы, все нужны сейчас:
Задача A: Фикс бага платежей
- Impact: КРИТИЧНЫЙ (теряем $10k/день)
- Confidence: ВЫСОКАЯ (знаю точно куда смотреть)
- Effort: 1 день
- Score = (10 × 100) / 1 = 1000
Задача B: Отключить функцию Y (она ломает сервер)
- Impact: ВЫСОКИЙ (теряем 30% функционала)
- Confidence: СРЕДНЯЯ (может помочь, может нет)
- Effort: 2 часа
- Score = (8 × 70) / 0.25 = 2240 ⬆️ ВЫШЕ!
Задача C: Срочно ответить Gazprom'у про интеграцию
- Impact: ВЫСОКИЙ (возможно +$500k)
- Confidence: СРЕДНЯЯ (нужно уточнить детали)
- Effort: 3 часа
- Score = (9 × 75) / 0.375 = 1800
Приоритет: B → C → A
Но внимание: если A это действительно платежи, то B может ждать 30 минут, а A делать первым, потому что A критичнее по определению.
Фреймворк 3: ABCDE классификация (из книги David Allen GTD)
A - MUST DO TODAY (критичное, deadline сегодня)
B - SHOULD DO TODAY (важное, но не критичное сроком)
C - NICE TO DO (было бы неплохо, но можно отложить)
D - DELEGATE (кто-то другой может сделать)
E - ELIMINATE (просто забить на это)
Мой день переклассифицирую:
A1 - Сервер упал (потеря денег ПО УМОЛЧАНИЮ)
A2 - Платежи не работают (потеря денег ПО УМОЛЧАНИЮ)
A3 - Gazprom ответ (+ потенциально больше, чем теряем сейчас)
B1 - Roadmap слайд (важно для инвестора, но можно доработать завтра)
C1 - Документация новой фичи (есть неделя на это)
D1 - Конкурент ответ (Sales может ответить)
E1 - Читать аналитику (nice to have)
Ошибки PM'ов при множественной срочности
❌ "Всё одинаково срочно" ✅ Отличай критичное от просто срочного
❌ "Я должен всё делать сам" ✅ Делегируй на 80% работы. Ты принимаешь решения, не делаешь работу.
❌ "Я буду многозадачным героем" ✅ Контекст-свитчинг убивает производительность. Делай одно за раз.
❌ "CEO сказал срочно, значит срочно" ✅ Спроси CEO: "На шкале 1-10, насколько это критично?" Обычно ответ 7, не 10.
Реальный example: как я выбирал из 5 срочных дел
Вторник, 11 AM. Звонят 5 разных людей в течение 1 часа:
- CTO: "Клиентская БД медленная, нужна кооперация PM с инженерами на оптимизацию архитектуры" (2-3 часа)
- CEO: "Нужно красивое pitch deck для инвесторов к четвергу" (4-5 часов)
- Support: "Клиент X угрожает отменить подписку, нужна встреча" (1 час)
- CFO: "Нужно доказать, что ROI маркетинга положительный, срочно отчёт" (2 часа)
- Sales: "Новый контракт требует кастомного API эндпоинта, займет неделю разработки" (solution design, 2 часа)
Мой процесс анализа:
1️⃣ Отличаю FAKE URGENT от REAL URGENT
- CTO: real (БД медленная = потеря денег)
- CEO: fake urgent (дедлайн в четверг, можно сделать в среду вечером)
- Support: real (клиент уходит = потеря)
- CFO: fake urgent (это аналитика, не product)
- Sales: real? (зависит от размера контракта)
2️⃣ Спрашиваю IMPACT
- CTO: $5k/день потерь (скорость = деньги)
- Support: $2k/месяц (одна подписка)
- Sales: $XXk (неизвестно)
- CEO: Нужно для раунда (влияние на выживание)
- CFO: Нужно знать для бюджета (средний impact)
3️⃣ Спрашиваю TIME TO FIX
- CTO: 2-3 часа мониторинга + диагностики
- Support: 1 час встреча + follow-up
- Sales: 2 часа solution design + estimate
- CEO: 4-5 часов, но распределить на 2-3 дня
- CFO: 2 часа анализа
4️⃣ Выбираю последовательность
Сейчас (до 12:30):
- Встреча с Support (1 час) → спасаю клиента
13:00-15:00:
- CTO диагностика (2 часа) → фиксю потерю денег
15:00-17:00:
- Sales solution design (2 часа) → готовлю оценку
Среда вечером:
- CEO pitch deck (4 часа) → не критично сейчас
Четверг:
- CFO отчёт (2 часа) → аналитика, не urgent
Заключение
Это не о том, чтобы сказать "нет" всему. Это о том, чтобы выбрать правильный порядок. Я использую:
- Матрица Eisenhower — разделить на квадранты
- ABCDE классификация — расставить приоритеты
- ICE scoring — объективно оценить (когда несколько A-задач)
- Делегирование — я не делаю 80% работы, я её назначаю
- Честный разговор с CEO — спрашиваю, действительно ли это критично
Средний PM делает всё хаотично. Хороший PM выбирает правильный порядок и зовёт нужных людей.