Сотрудник получил задачи от нескольких менеджеров

Решение

Часть 1: Решение текущей ситуации

Сценарий, когда разработчик получает срочные задачи от нескольких менеджеров одновременно, — классическая проблема управления приоритетами. Вот как её разрешить:

Немедленные действия (первые 30 минут):

1. Организовать срочное совещание с тремя менеджерами и Дмитрием одновременно

   • Причина: Конфликт приоритетов требует принятия решения на уровне выше менеджеров
   • Участники: IT PM (модератор), три менеджера, разработчик
   • Продолжительность: 15 минут

2. На совещании обсудить:

   • Бизнес-влияние каждой задачи (какой доход/потери?)
   • Сроки выполнения и гибкость
   • Зависимости от других работ
   • Реальное время, необходимое Дмитрию
   • Возможность разделить работу или привлечь других разработчиков

3. Принять решение по матрице приоритизации:

   Критерий	Вес	Задача 1	Задача 2	Задача 3
   Бизнес-критичность	40%	10	7	5
   Срочность (дни)	30%	5	8	9
   Затраты ресурсов	20%	6	5	8
   Зависимости	10%	3	7	4
   ИТОГ	100%	7.2	7.0	6.4

4. Установить реалистичный план:

   • Задача 1: Начало сейчас (1–2 дня)
   • Задача 2: Очередь (3–4 дня)
   • Задача 3: После завершения Задачи 2 (5–6 дней)
   • Дмитрий доступен полностью на одну задачу, не распыляется

5. Скоммуницировать результат:

   • Каждому менеджеру отправить письмо с обоснованием приоритета
   • Указать точные даты начала и завершения
   • Назначить PM ответственным за отслеживание

Часть 2: Системные изменения для предотвращения конфликтов

Проблема: Отсутствие централизованной системы управления приоритетами

Решение 1: Единый бэклог и портал заявок

• Все задачи поступают в единую систему (Jira, Azure DevOps)
• Менеджеры видят реальную загруженность разработчиков
• Видна вся очередь работ и приблизительные сроки
• Система не разрешает создавать "срочные" задачи без согласования

Решение 2: Еженедельное планирование спринта

• Каждый понедельник: встреча всех менеджеров + PM + ключевые разработчики
• На встречу берутся только задачи на текущую неделю
• Для "срочных" задач есть резерв ёмкости (15–20%)
• Если новая срочная задача — решение принимает PM на месте, что исключить из плана

Решение 3: SLA для разных типов задач

• Критичная (production down): 4 часа
• Высокая: 1 день
• Средняя: 3 дня
• Низкая: 1 неделя

Все задачи при поступлении классифицируются, менеджеры видят реалистичные сроки.

Решение 4: Обучение менеджеров и разработчиков

• Проведение workshop-а по приоритизации и планированию
• Создание документа "Как запросить срочную задачу" с процессом
• Регулярные ретроспективы по конфликтам приоритетов

Часть 3: Здоровая система приоритизации задач

Архитектура системы:

Уровень 1: Классификация по типам

├─ Production Issues (критичные баги в production)
├─ Planned Features (плановые разработки)
├─ Maintenance (улучшения, рефакторинг)
├─ Technical Debt (долг, улучшения архитектуры)
└─ Research (экспериментальные работы)

Уровень 2: Матрица приоритизации RICE

Для каждой задачи рассчитать Score = (Reach × Impact × Confidence) / Effort

• Reach: Сколько пользователей затронет за 1 квартал? (0–1000)
• Impact: Какой эффект на каждого пользователя? (3=массивный, 2=высокий, 1=средний, 0.5=низкий)
• Confidence: Насколько уверены в оценках? (100%=100, 50%=50)
• Effort: Недель разработки (целое число)

Пример:

• Task A: (500 × 3 × 100) / 4 = 37,500
• Task B: (50 × 3 × 100) / 2 = 7,500
• Task A приоритетнее

Уровень 3: Спринтовое планирование

Еженедельный процесс:
1. Пересмотр текущих работ (сторнирование завершённых)
2. Добавление новых задач в бэклог
3. Переклассификация по RICE
4. Согласование мощностей (ёмкость спринта = 80% от идеала)
5. Резерв 20% на непредвиденные срочные работы
6. Коммуникация итогов менеджерам

Уровень 4: Эскалация срочных задач

Если менеджер считает задачу "срочной":

1. Заполнить форму с обоснованием (бизнес-влияние, deadline)
2. PM проводит оценку за 30 минут
3. Если текущий спринт загружен < 80%, задача встаёт в очередь
4. Если > 80%, решение принимает PM или руководитель программы
5. Исключённая из спринта задача становится приоритетом на следующий спринт

Уровень 5: Метрики и отслеживание

• Velocity: Задачи, завершённые за спринт (тренд)
• Lead time: От создания задачи до начала работ (целевой: < 7 дней)
• Cycle time: От начала работ до завершения (для прогноза)
• Scope creep: Задачи, добавленные в спринт (целевой: < 10%)
• Срочность: % задач, поступивших как "срочные" (целевой: < 10%)

Коммуникационный цикл:

Понедельник 10:00  → Planning встреча (1 час)
Понедельник 11:00  → Коммуникация менеджерам (письмо)
Среда 15:00        → Синхронизация (проверка хода, обновление планов)
Пятница 16:00      → Ретроспектива и планирование на следующую неделю

Результаты здоровой системы:

• Менеджеры видят реалистичные сроки и не создают конфликты
• Разработчики не распыляются и не переутомляются
• PM имеет данные для принятия обоснованных решений
• Снижается количество "срочных" задач за счёт лучшего планирования
• Растёт предсказуемость и скорость разработки