Что делаешь если кто-либо из команды затягивает сроки?

Как справиться когда команда затягивает сроки

Это одна из самых частых проблем которая стоит между планом и реальностью. Я видел это сотни раз и научился несколько вещам как это решать правильно.

Шаг 1: Понять почему (это важнее чем ругать)

Первое что я делаю — спрашиваю, не ругаю:

Встреча с tech lead / инженером: "Мы договорились что это займет неделю но сейчас уже 10 дней. Что произошло? Что я не учел?"

Звучит по-другому чем: "Почему вы не закончили вовремя?"

Обычно выясняется одно из:

Причина 1: Неправильная оценка effort (60% случаев)

• Инженер честно предсказал неправильно
• "Я думал это 1 задача но выяснилось 3 задачи"
• "Я не знал что придется переделывать БД"
• Это не личное, это skill improvement

Причина 2: Переключение контекста (25% случаев)

• В середине спринта пришла urgent задача
• "Было "критичное" место что требовало моего внимания"
• Production упал, нужно было fix
• Это management проблема, не инженера

Причина 3: Неясные requirements (10% случаев)

• Инженер начал писать код и выяснилось что requirement неясный
• "Я потратил неделю пока мы разбирались что вы на самом деле хотите"
• Это моя проблема как PM

Причина 4: Лень / отсутствие мотивации (5% случаев)

• Это бывает но редко
• Обычно за этим скрывается что-то другое (плохой код который стыдно показывать, неправильное направление, человек burned out)

Шаг 2: Решение зависит от причины

Если причина 1 (неправильная оценка):

Я не ругаю. Вместо этого:

• "Спасибо что сказал правду. Теперь я знаю что нужно лучше разбираться в technical requirements"
• Я добавляю buffer к future оценкам этого инженера (если он говорит неделю, я планирую 1.5 недели)
• Я предлагаю: "В будущем давайте сделаем design meeting перед разработкой"

Это не punishment, это improvement.

Если причина 2 (переключение контекста):

Это management failure, не инженера. Я:

• Признаю проблему: "Мне нужно лучше protect тебя от interrupts"
• Я вводу правило: "Критичные задачи могут interrupt только если это production down"
• Я начинаю отслеживать все interrupts
• Если их больше чем 20% спринта, я поднимаю это в лидершип

Если причина 3 (неясные requirements):

Это моя ошибка. Я:

• Принимаю ответственность
• "Я плохо объяснил что нужно. Давайте это улучшим"
• Я начинаю писать better specs (более детально, с примерами, edge cases)
• Я начинаю делать design meetings перед разработкой

Если причина 4 (лень):

Это сложнее. Я говорю прямо но с уважением:

• Приватная встреча
• "Я вижу что ты не очень мотивирован этой задачей. Что не так?"
• Слушаю
• Это может быть: плохой код что нужно переделать, неправильное направление, человек бурнаут, работа не interesting
• Я ищу solution: может быть другой инженер? Может быть переделать requirement? Может быть дать перерыв?

Шаг 3: Система мер чтобы prevent это в future

Мера 1: Better estimation process

Мы начали делать так:

• Требование пишу я (PM)
• Tech lead смотрит requirement и дает technical estimate
• Они обсуждают, я не вмешиваюсь
• Если estimate высокий, я спрашиваю: "Есть ли другой способ сделать дешевле?"
• Это collaborative process, не top-down

Результат: оценки стали лучше потому что инженеры have ownership.

Мера 2: Smaller tasks

Вместо "сделай функцию X за 2 недели" я разбиваю:

• День 1-2: MVP версия (50% функционала)
• День 3-5: основные improvements
• День 6: polish + bugs

Это helps потому что:

• Shorter tasks легче оценить
• Visibility лучше (я вижу progress день за днем)
• Если delay, я видит это на день 3 а не на день 10

Мера 3: Daily standup

Мы делаем 15-минутный standup где каждый говорит:

• Что я сделал вчера
• Что я делаю сегодня
• Есть ли blockers?

Это catches problems рано. Если инженер говорит "Я stuck на X и не знаю как решить", я могу помочь на день 2 а не на день 7.

Мера 4: Clear scope definition

Для каждой фичи я пишу:

• Что входит в scope (что будем делать)
• Что НЕ входит в scope (что не будем на день 1)
• Edge cases которые нужно обработать
• Success criteria (как мы поймем что это done)

Это уменьшает surprise.

Мера 5: Protect time for deep work

Я говорю инженерам: "По вторникам и четвергам у вас нет встреч. Это ваше время для deep work."

Проблемы переключения контекста убывают потому что люди имеют continuous time.

Как я общаюсь если deadline уже missed

Привилегия PM это говорить truths to stakeholders. Я:

День 10 (когда выяснилось что задача не готова):

• Я сообщу лидершип ЧТО случилось и ПОЧЕМУ
• "Мы оценили это на 1 неделю но выяснилось это 2 недели потому что X"
• "Новый deadline: день 14"
• Я объясняю impact: может быть это означает что другая фича will be delayed

Я НЕ говорю:

• "Инженеры были lazy" (неправда и контрпроductive)
• "Это не моя ответственность" (это моя ответственность потому что я планирую)
• "Мы должны were faster" (unhelpful)

Я говорю:

• "Мы неправильно оценили complexity. Извиняюсь"
• "Вот новый план"
• "Вот что я буду делать чтобы это не повторилось"

Лидеры respect тех кто берут ownership за mistakes.

Реальный пример

В одном проекте был инженер который постоянно опаздывал. "5 дней" становилось "8 дней". Я мог расстроиться но вместо:

Я провел встречу:

• "Я вижу pattern что твои оценки на 50% underestimate. Что делать?"
• Выяснилось: он perfectionist
• Он писал код perfect но это занимало 50% extra времени
• Мы договорились: "Давай сделаем working version quick потом refactor"
• После этого его оценки стали accurate

Проблема была не в лени а в стиле работы.

Финальный совет

Когда кто-либо затягивает:

1. Спросите ПОЧЕМУ перед любыми выводами
2. Решение зависит от причины
3. Protect вашу team от unnecessary interrupts
4. Разбивайте большие задачи на smaller
5. Лучше know о problem на день 3 чем на день 10
6. Возьмите ownership за planning mistakes
7. Инвестируйте в better estimation process

А самое главное: предполагайте что инженеры хотят делать хорошую работу. Обычно они do. Ваша работа как PM — убрать obstacles и дать ясность.

Когда вы это делаете, "затягивание" disappears.