Проблемный проект с демотивированной командой

План спасения проблемного проекта (2 месяца до дедлайна)

Это сценарий fire fighting. 40% ready за 2 месяца с демотивированной командой и конфликтами — это серьёзно. Но есть проверенный playbook.

Фаза 1: Диагностика и первая неделя (ЧАСЫ)

День 1: Понять реальное состояние

Не слушай мнения, смотри факты:

• Что физически готово в production? (не "почти готово")
• Какой velocity был в последних 4 спринтах?
• Сколько open bugs и какие их приоритеты?
• Что на самом деле блокирует проект? (есть hypothesis, но нужны факты)

Технический аудит (2 часа с техлидом):

• Показать мне все открытые tasks
• Оценить: что реально можно закрыть за 8 недель
• Какой технический долг критичен? (может тормозить другие части)
• На какие части нельзя надеяться (шаткие)

Результат: Реалистичный прогноз: "При current velocity мы закроем только X% в срок". Лучше жесткая правда сейчас, чем surprise в конце.

День 1-2: Индивидуальные разговоры с командой

30-минутные 1-1 с каждым разработчиком/QA:

Что спрашивать:

• Что тебя раздражает в проекте? (честно)
• Когда ты в последний раз чувствовал, что что-то получается?
• Что может сделать новый менеджер, чтобы улучшить ситуацию?
• Ты хочешь остаться в этом проекте или уйти?

Что НЕ делать:

• Критиковать предыдущих менеджеров
• Обещать чудеса
• Давать советы (ещё)
• Защищать клиента

Что делать:

• Кивать и слушать
• Писать конкретные issues: "блокирует QA", "непонятны требования", "toxic коллега"
• Показать, что слышишь

Результат: Ты поймёшь, где реальные проблемы (может быть, не технические, а человеческие).

День 2: Встреча с клиентом

30 минут, structured:

1. Слушай его боли (10 мин)

   • "Расскажите, что вас больше всего раздражает"
   • "Какие функции для вас самые критичные?"
   • "Какой минимальный scope сделает вас счастливыми?"

2. Покажи реалистичность (10 мин)

   • "Я провел аудит. Вот что реально возможно за 8 недель"
   • "Вот мой честный прогноз [гораздо жестче, чем обещали раньше]"
   • "Лучше я скажу вам правду сейчас, чем surprise перед дедлайном"

3. Предложи вариант (10 мин)

   • Вариант A: Сокращённый scope, всё на time
   • Вариант B: Full scope, но延期 на 2-4 недели
   • Вариант C: Core features на time, остальное в phase 2 (post-launch updates)
   • "Какой вариант вас устраивает?"

Цель: Переговорить deadlines реалистично. Это даст команде breathing room.

День 3: Публичное собрание команды (15 мин)

Скажи:

"Я знаю, что последние месяцы были тяжело. Я хочу быть честен с вами и с клиентом.

[Факты]: Мы на 40%, deadline через 8 недель. При current velocity это будет сложно.

[Что я услышал от вас]: Непонятные требования, блокирующие вопросы, иногда ловите себя на том, что пишете не то.

[Что я сделаю]:

• Ясность в требованиях КАЖДЫЙ ДЕНЬ (не вы отгадываете, я объясняю)
• Убираю blockers (уже пошёл в разговоры с клиентом)
• Фокус на то, чтобы вы писали код, не танцевали политику

[Что я прошу от вас]:

• Честность: если что-то непонятно → сразу говорим
• Качество code: я хочу гордиться тем, что мы делаем
• Support друг друга: конфликты dev vs QA — это боль про неясные требования, не про людей

[Итог]: Это будет жёсткие 8 недель. Но я вижу выход. Если вы сможете мне доверять, мы это сделаем."

Тон: Честный, уважительный, никаких бубликов. Команда мотивируется не слайдами, а действиями.

Фаза 2: Восстановление мотивации (Неделя 1-3)

1. Ясность в требованиях (критично!)

Главная боль: Разработчики пишут не то, QA тестирует не то, клиент недоволен.

Решение: Requirements review workshop (2-3 часа)

• Соберись с разработчиками, QA, PO, клиентом (если possible)
• Берёшь ТОП-10 задач (самые критичные)
• Обсуждаешь: что именно нужно сделать?
  • Какой input? Какой output? Какой edge cases?
  • Есть ли mockups? Есть ли тесты?
  • Когда это готово, что нужно проверить?

Результат: Acceptance criteria, которые ВСЕ понимают. Минус 50% переделок.

2. Убрать конфликты dev vs QA

Проблема: Разработчик пишет → QA находит баги → разработчик в защите → конфликт.

Решение:

• Поговори отдельно с QA lead и tech lead

  • "Вы оба на одной стороне. Враг — неясные требования, не друг друг"
  • "QA, ты не cops, ты quality guardian. Твоя роль — помочь разработчику найти баги ДО production"
  • "Dev, код пишется один раз, проверяется много раз. Если QA нашел 10 багов, может быть, надо медленнее писать?"

• Введи QA в процесс РАНЬШЕ

  • QA читает требования вместе с dev
  • QA пишет test cases ДО разработки (test-first approach)
  • Dev показывает QA feature в progress (не ждёт завершения)

Результат: Конфликты + rework снижаются. Вместо "баги в production" → "баги найдены на dev stage".

3. Daily структурированный

Проблема: Daily может быть либо waste (ничего не решается), либо отбивает мотивацию (все обвиняют друг друга).

Структура (10-15 мин):

1. Что закрыли вчера? (facts, не планы)
2. Что закроем сегодня?
3. Что блокирует? (я помогаю, не критикую)

Правила:

• Я как PM слушаю blockers и разруливаю ВНЕ daily
• Никакой критики на всех
• Фокус на progress, не на blame

4. Quick wins (видимый прогресс)

Проблема: Команда в отчаянии. Нужно показать, что это не крах.

Решение:

• Берёшь 2-3 задачи, которые можно закрыть за пару дней
• Задача: что-то видимое для клиента (не рефакторинг)
• Пример: Fix 5 критичных bugs → Покажи клиенту → Видимый улучшение

Результат: Команда видит, что идёт вперёд. Мораль растёт.

5. Публичное признание

Что делать:

• На каждом daily: "Спасибо, Петр, что закрыл эту сложную задачу"
• В письме клиенту: "Команда сделала хороший прогресс на неделе" (не люди, а результаты)
• 1-1 с каждым раз в 2 недели: "Вижу, как ты растёшь в этом. Ценю это"

Фаза 3: План действий для клиента (Встреча +5 дней)

Вариант 1: Честный прогноз (рекомендуемый)

Документ: Project Recovery Plan

Текущее состояние:
- 40% ready
- Velocity последних 2 недель: X user stories/неделю
- При этом velocity: ~60% к дедлайну

Проблемы, которые мы зафиксировали:
- Неясные требования (ведут к переделкам)
- Конфликты dev-QA (ведут к задержкам)
- Технический долг в X областях (замедляет разработку)

Что мы меняем:
[Список из 5-10 действий из Фазы 2]

Прогноз:
- Вариант A: Full scope к [дата] (延期 на 3 недели)
- Вариант B: Core features к [текущий deadline], остальное в Phase 2
- Вариант C: Сокращённый scope к [текущий deadline] (какие фичи убираем)

Метрики успеха:
- Velocity вырастет на X% за 2 недели
- Bugs в production упадут на Y%
- Клиент выставляет оценку качества

Презентация (20 мин):

1. Честь: мы были неправы, лезли с пустыми обещаниями
2. Диагноз: что реально было сломано
3. План: что мы меняем
4. Выбор: варианты, которые реально возможны

Встреча с клиентом (структура)

Сценарий 1: Клиент согласен с延期

• "Спасибо, что доверяете. Вот наш план улучшений"
• Еженедельные демо (пятница, 30 мин)
• Следующий статус-апдейт через 2 недели

Сценарий 2: Клиент хочет придерживаться дедлайна

• "Какой scope для вас критичен?"
• Убираешь всё остальное
• "Остальное мы делаем в Phase 2 после launch"
• Фокусируешь команду на это

Сценарий 3: Клиент хочет уйти

• Ты: "Я понимаю. Дайте мне 2 недели. Если не улучшится → ухо́дите"
• Ставишь KPI: velocity, качество, клиентское удовлетворение
• Делаешь всё возможное на эти 2 недели
• Скорее всего, улучшится, и клиент останется

Фаза 4: Execution (Неделя 3-8)

Главное: Deliver. Всё остальное — слова.

Еженедельная структура

Понедельник: Sprint planning (1.5 часа)

• Что закроем за неделю?
• Есть ли blockers ДО старта?

Вторник-четверг: Daily (10 мин) + фиксинг blockers

Пятница: Demo (30 мин для клиента/PO)

• Что готово (физически)
• Что планируем на следующую неделю
• Вопросы?

Итой спринта: Retro (30 мин)

• Что пошло хорошо? (не много слов, важны факты)
• Что не так? (конкретно, не общие фразы)
• Что меняем на следующий спринт?

Мониторинг (для себя)

Каждый день трекь:

• Velocity (сколько story points закрыли)
• Bugs (сколько нашли, сколько закрыли, сколько осталось)
• Morale (на глаз: команда энергична или в отчаянии)

Если что-то не по плану → сразу разруливаешь, не ждёшь конца спринта.

Red flags и как реагировать

Flag 1: "Клиент хочет добавить фичи"

• Немедленно: Что убираем? (scope management)
• Не допускаешь расширение scope без延期

Flag 2: "Velocity падает"

• Причина: болезнь? конфликты? сложность?
• Разруливаешь в день 1, не ждёшь

Flag 3: "Разработчик хочет уйти"

• 1-1 немедленно
• Если уходит — это нормально. Замени его
• Но если уходят несколько → проблема в менеджменте (в тебе)

Flag 4: "Технический долг не позволяет идти вперёд"

• Пробей дыру: 1-2 дня на refactoring
• После этого скорость повышается
• Лучше потерять 2 дня сейчас, чем 10 дней потом

Итоговые метрики успеха (через 8 недель)

• ✓ Velocity вернулась к норме (или выше)
• ✓ Команда не развалилась (никто не ушёл)
• ✓ Клиент доволен (5/5 или 4/5 баллов)
• ✓ В production < X критичных багов
• ✓ Никто не говорит "это worst project ever"

Это не волшебство. Это грязная работа: слушать, быть честным, решать blockers, показывать путь.