Перегрузка: три проекта одновременно

Решение

1. Анализ текущей ситуации

Сбор данных (1-2 дня)

Метрики проектов:

• Для каждого из 3 проектов:
  • Плановый timeline vs актуальный timeline (насколько задерживаемся?)
  • Плановый бюджет vs актуальная трата часов (насколько перерасход?)
  • Percentage completion: где находимся в каждом проекте?
  • Количество baglog items: сколько ещё работы?
• Для поддержки:
  • Сколько часов в неделю тратим на support?
  • На что уходит время? (bugs, feature requests, emergency fixes?)
  • Есть ли паттерны? (одна система требует больше support?)

Метрики команды:

• Рабочие часы: реальное количество часов в неделю (не плановые 40, а фактические)
• Overtimes: сколько часов переработок?
• Turnover: был ли уход людей из-за усталости?
• Качество: количество bugs по проектам, требования переделок
• Morale: говорите ли люди что счастливы? (анонимный опрос)

Анализ проектов:

• Для каждого проекта: срочность (deadline), важность (business value), сложность (tech risk)
• Зависимости: проекты зависят друг от друга?
• Shared resources: какие люди работают на несколько проектов одновременно?

One-on-ones:

• Встречи с каждым разработчиком: как они ощущают ситуацию?
• Где основной bottleneck? (code review? testing? dependencies?)
• Какой проект самый болезненный?
• Что нужно убрать/отложить?

Встреча с клиентами:

• Какие задержки их больше всего беспокоят?
• Есть ли проекты, которые менее критичны?
• Готовы ли они ждать в обмен на лучшее качество?

Итоговая матрица:

Проект 1 | Deadline | Importance | Impact | Risk | Team allocation
Проект 2 | ...      | ...        | ...    | ...  | ...
Проект 3 | ...      | ...        | ...    | ...  | ...
Support  | ...      | ...        | ...    | ...  | ...

2. Решения для руководства

Вариант A: Дозирование ресурсов (recommended)

Суть: вместо одновременной работы на 3 проектах, переходим на волны (waves).

Реализация:

• Волна 1 (4 недели): Проект 1 (70% ресурсов) + Support (30% ресурсов)
  • Проект 2 и 3 в режиме minimal support
• Волна 2 (4 недели): Проект 2 (70% ресурсов) + Support (30% ресурсов)
  • Проект 1 в режиме minimal support (только critical bugs)
  • Проект 3 в режиме minimal support
• Волна 3 (4 недели): Проект 3 (70% ресурсов) + Support (30% ресурсов)

Плюсы:

• Команда может focus и deliver quality
• Нет многозадачности (context switching стоит ~25% продуктивности)
• Cliens видит прогресс по одному проекту, а не по трём одновременно
• Меньше stress на команде
• Более реалистичные deadlines

Минусы:

• Общие сроки выше (но качество лучше)
• Требует согласия всех трёх клиентов

Стоимость: средняя

Вариант B: Увеличение ресурсов

Суть: нанять больше разработчиков / временно привлечь контрактников.

Реализация:

• Дополнительно 2-3 разработчика (senior или mid-level)
• Они работают на текущие проекты
• Это ускорит доставку

Плюсы:

• Проекты движутся параллельно
• Deadlines не сдвигаются
• Team может дышать

Минусы:

• Новые люди требуют onboarding (2-4 недели)
• Дороговато (зарплата + overhead)
• Ненадёжно: контрактников потом нужно отпускать
• Temporary solution только если нужно преодолеть горб

Стоимость: высокая

Вариант C: Scope reduction (переговоры)

Суть: уменьшить объём работ на текущих проектах.

Реализация:

• Для каждого проекта переговор с клиентом: "Что critical для MVP, что nice-to-have?"
• Перенести nice-to-have на Phase 2 (后续обновление)
• Фокусироваться на MVP для каждого проекта

Примеры:

• Вместо полного аналитического dashboard: базовый dashboard (можно расширить потом)
• Вместо поддержки 5 браузеров: 3 основных (остальные потом)
• Вместо интеграции с 10 систем: 3 ключевых (остальные потом)

Плюсы:

• Быстрая доставка quality MVP
• Клиент видит результат быстро
• Может давать feedback и направлять развитие
• Team не перегорает

Минусы:

• Требует честного разговора с клиентами
• Некоторые клиенты могут обидеться
• Нужно четко документировать фазы

Стоимость: низкая (от переговоров)

Вариант D: Переопределение support (частичное решение)

Суть: поддержка существующего продукта требует много времени. Её нужно оптимизировать.

Реализация:

• Выделить dedicated person (1 FTE) для support (ротация в команде)
• SLA для support tickets: high - 4 часа, medium - 1 день, low - 3 дня
• Автоматизировать support: chatbots, self-service docs, FAQ
• Для non-critical issues: очередь, обработка batch'ем 1-2 раза в день

Плюсы:

• Другие разработчики могут focus на проекты
• Support становится предсказуемым

Минусы:

• Один человек может перегореть
• Требует хороших процессов

Стоимость: низкая

Вариант E: Комбо (рекомендуется)

• Scope reduction: убрать 20-30% nice-to-have
• Переопределить support: 1 dedicated person
• Перейти на waves: вместо 3 параллельно, волны по 70-30
• Результат: команда может дышать, quality улучшится, сроки более реалистичные

Стоимость: низкая-средняя

3. Приоритизация в краткосрочной перспективе

Шаг 1: Матрица приоритизации (MOSCOW или Impact/Effort)

Для каждого проекта определите:

• Must have: критично для business, без этого проект не имеет смысла
• Should have: важно, но можно отложить на фазу 2
• Could have: nice-to-have, низкий приоритет
• Won't have (now): отложить явно

Пример (Проект 1 - e-commerce платформа):

• Must: user registration, product catalog, checkout, payment integration
• Should: wishlist, reviews, recommendations
• Could: social sharing, gamification, advanced search filters
• Won't: loyalty program, AI personalization (phase 2)

Шаг 2: Переговоры с клиентами

Для каждого проекта:

• Показать матрицу
• Объяснить: "Если сделаем ВСЁ, quality пострадает. Вот вариант Phase 1 (must+should) с quality, Phase 2 (could) потом"
• Получить согласие
• Документировать в контракте/scope

Шаг 3: Переделать спринт планирование

Волна 1 (Неделя 1-4): Проект 1 (70%) + Support (30%)

• Sprint 1: Must + 50% Should из Проекта 1
• Sprint 2: Остаток Should + Polish + Testing
• Sprint 3-4: Buffer для переделок и bug fixing

Параллельно:

• Support: 1 dedicated person (ротация)
• Проект 2: задания в режиме minimal (1-2 часа в неделю на communication)
• Проект 3: задания в режиме minimal

Шаг 4: Emergency protocol

Если случается критический bug в другом проекте:

• Оценка: это действительно critical? (data loss? security? revenue risk?)
• Если yes: pull 1 senior разработчик из Волны 1 на 2-4 часа
• Если no: добавить в очередь на Волну 2

Шаг 5: Мониторинг и adjustment

• Каждый спринт: retro с командой
  • Как со скоростью?
  • Как с качеством?
  • Как с stress?
• Каждую волну: review с руководством
  • Hitting timeline?
  • Quality OK?
  • Team happy?
• Adjust если нужно (например, scope слишком big, нужно урезать ещё)

Шаг 6: Communication с клиентами

• Еженедельные demo: показывать что сделано
• Clear expectations: "Сейчас focus на Проект 1, Проект 2 начнём 2 апреля"
• Transparency: если что-то задерживается, скажите сразу
• Возможность change requests: если клиент захочет изменить что-то, это обсуждается и reschedule

Краткий план действий (День 1-2)

1. Собрать данные: спросить команду, клиентов, руководство (день 1)
2. Анализ: посчитать mattrix (день 1-2)
3. Выбрать вариант: обсудить с руководством (день 2)
4. Переговоры с клиентами: объяснить plan (день 2-3)
5. Переделать спринт: написать новый план на волны (день 3)
6. Kommunикация в команде: объяснить что меняется и почему (day 3)
7. Начать волну 1: старт на новых условиях (day 4)

Итог

Перегруз это не просто PM проблема, это сигнал что что-то не так в системе. Вместо того чтобы заставить команду работать больше (что ведёт к burnout и turnover), нужно переделать систему: снизить scope, лучше приоритизировать, волны вместо параллельности, обучить команду. Это долгосрочное решение, не пластырь.