Как вы справляетесь, когда поставщик не соблюдает сроки?

Как справляться с задержками поставщика

Контекст: реальная история

Работа: Platform для подбора страховщиков (B2B2C).

Проблема: разработчик, которого нанял для backend'а, пообещал сделать API за 4 недели. Прошло 8 недель, он всё ещё не выложил code.

Это был момент: "либо я сейчас спасаю ситуацию, либо продукт死了".

---

Шаг 1: Осознание проблемы (как заметить вовремя)

Без мониторинга:

• Неделя 1: всё норм, разработчик говорит "идёт хорошо"
• Неделя 2: "небольшие задержки, потом нагоню"
• Неделя 3: "сложнее, чем думал, потреб ещё неделю"
• Неделя 4: (дедлайн) "почти готово, завтра выложу"
• Неделя 5: готово? нет.
• Неделя 8: наконец готово.

С мониторингом:

Вариант A: Daily standups

Каждый день (15 минут):
- Что сделано вчера?
- Что будет сегодня?
- Какие блокеры?

Повышенная видимость → проблемы видны на день 2, не на неделю 4.

Вариант B: Milestone-based tracking

Вместо "4 недели на весь API",
разбиваешь на:
- Неделя 1: endpoint #1-3 (GET /insurance, POST /quote)
- Неделя 2: endpoint #4-6 (authentication, error handling)
- Неделя 3: тестирование, документация
- Неделя 4: поправки, deploy

Ежедневно спрашиваешь: "Endpoint #1 готов?" → answer: да/нет.
Если нет → сразу видишь, что есть проблема.

Вариант C: Code reviews

Вместо "покажешь code в конце",
просишь:
"Покажи code каждый день, буду смотреть"

День 1: 200 строк
День 2: 400 строк
День 3: 200 строк (упадок!)
"Что случилось?"
"О, рефакторил, потеря в скорости"

Рано видишь проблему, можешь помочь или переделать.

---

Шаг 2: Управление ожиданиями (Buffer & Transparency)

Ошибка 1: Верить обещаниям разработчиков

Разработчик: "4 недели"
→ Я планирую запуск на неделю 4
→ Разработчик недостигает → я терпю убытки

Правильно: Буферизировать

Разработчик: "4 недели"
→ Я планирую запуск на неделю 6 (буфер 50%)
→ Если он опоздает на 2 недели → я всё равно в срок

Почему 50%? История IT проектов: 70% перевыполнены на 30-50%.

Правильно: Быть честным

Вместо: "обещаю неделю 4"
Клиенту говорю: "планируем неделю 6, но может быть быстрее"

Если готово на неделю 4 → клиент in восторге (раньше!)
Если готово на неделю 6 → клиент not surprised (как и ожидал)
Если готово на неделю 7 → клиент раздражен, но not shocked (я его подготовил)

---

Шаг 3: Типы задержек и как реагировать

Тип 1: Техническая сложность

"Разработчик пришёл: это сложнее, чем я думал. Нужна неделя вместо 3 дней."

Диагностика:

• Что именно сложнее?
• Мог ли ты это предвидеть?
• Может ли junior помочь?

Мой ответ:

Если это REAL complexity (DB индексирование, performance):
  → добавляю неделю
  → попрашу help (другой разработчик)

Если это SCOPE creep ("и ещё давай этот feature"):
  → я говорю: "это был не в плане, это отдельный проект"
  → либо приоритизируем, либо откладываем

---

Тип 2: Отсутствие прогресса

"Прошло 2 недели, разработчик говорит "вот-вот", но code нет."

Диагностика:

• Спрашиваю: "покажи мне code"
• Если code есть, но не готовый → нормально
• Если code вообще нет → красный флаг

Мой ответ:

"Если завтра code не появится, мы заменяем тебя на другого разработчика"

Это не угроза, это факт. 
I don't have time for slow people.

Альтернатива: пару дней на pairing (я сидим с ним, помогаю)

---

Тип 3: Личные обстоятельства

"Болел неделю, поэтому отстал. Потом бабушка приехала. Потом система сломалась."

Мой ответ:

Если это один раз в год → ok, даём буфер.
Если это каждый месяц → это не про обстоятельства, это про неорганизованность.

Даём возможность, но переводим на daily check-ins:
"Каждый день мне звонишь и показываешь, что сделано"

Или ищем замену.

---

Шаг 4: Тактики восстановления (как спасать ситуацию)

Тактика 1: Разбить на меньшие куски

Вместо: "API готов через 2 недели"

Новый план:
- Неделя 1: 3 самых критичных endpoint'а (MVP level)
- Разработчик показывает API мне
- Я могу начать интегрировать frontend
- Неделя 2: остальные endpoint'ы

Преимущество:
- Параллельная работа (я не жду, я работаю)
- Видимость (я вижу, он работает)
- Возможность fix'ить проблемы рано

Тактика 2: Добавить ресурсы

Один разработчик отстал → нанимаем second разработчика.

Минус:
- Два разработчика работают медленнее, чем 1.5x ускорение (overhead на sync)
- Стоит денег

Плюс:
- Спасаем deadline
- Второй разработчик может work на других features

Когда: когда deadline критичен и цена задержки > стоимость второго разработчика

Тактика 3: Переделать scope

Исходный план:
- API с 10 endpoint'ов
- Authentication
- Rate limiting
- Docs
- Tests

Отстали на 50% → переделяем:
- API с 5 критичных endpoint'ов (из 10)
- Authentication (обязателен)
- Rate limiting (отложить)
- Docs (я сам напишу потом)
- Tests (не критичны на MVP)

Выпускаем MVP, потом итеративно улучшаем.

Сроки: 1 неделя (вместо 2).

Тактика 4: Прямой разговор

Я приходу к разработчику:

"Давай по честному. Ты можешь это сделать в срок? Да или нет?"

"Нет, мне нужна ещё неделя."

"Окей. Это нам стоит $50K в убытках (отложенный запуск). Поэтому либо:
  1) Я нанимаю второго разработчика, и вы вместе
  2) Я переделываю scope (убираю половину фич)
  3) Я нанимаю другого разработчика

Что выбираешь?"

"Я могу спросить у друга помочь."

"Отлично. Это должно работать?"

"Да, готовы через 5 дней."

"Спасибо. Покажешь мне progress завтра?"

Это не на эмоциях, это на фактах. Стоимость задержки > стоимость решения.

---

### Шаг 5: Долгосрочные решения

**После задержки, я извлекаю уроки:**

**Урок 1: Процессы**

Вводу daily standups (15 минут, обязательны) Вводу code reviews (все code смотрю перед merge'ом) Вводу milestone tracking (не "когда будет", а "неделя 1 что будет")

**Урок 2: Люди**

Этот разработчик хорош в быстрых tasks, но плох в долгосрочных. → Даю ему только 3-дневные tasks

Наймаю second разработчика на долгосрочное (1-2 месяца).

**Урок 3: Планирование**

Вместо: "разработчик скажет, сколько времени" Теперь: я оцениваю, потом даю ему эту оценку

Разработчик не может быть объективен про свою speed (люди оптимичны). Я смотрю на его историю: "В прошлом проекте ты обещал 4 недели, получилось 8. Поэтому твоей оценке я умножу на 2."​

---

### Чеклист: как управлять поставщиком (разработчиком)

- [ ] **Ясные вехи** (не "4 недели", а "неделя 1: endpoint's 1-3")
- [ ] **Daily visibility** (standup, code review, или sync встреча)
- [ ] **Buffer в расписании** (обещаю неделю 6, но планирую неделю 4)
- [ ] **Честность с клиентом** (говорю риск, что может быть задержка)
- [ ] **Мониторинг прогресса** (не вожу слепо, я вижу code)
- [ ] **Готовность к action** (если отстаёт → сразу помощь, ресурсы или замена)
- [ ] **Post-mortem после задержки** (что выучили?)
- [ ] **Меньше доверия, больше проверки** (trust but verify)

---

### Когда я говорю "нет" поставщику

**Сценарий: Разработчик говорит: "4 недели на feature X"**

**Я спрашиваю:**
- "Это 4 недели твоего времени? (40 часов/неделю)"
  "Да"
- "Ты когда-то обещал 4 недели и опоздал?"
  "Да, на Проекте Y"
- "На сколько опоздал?"
  "На 2 недели"
- "Поэтому я планирую не 4, а 8 недель?"
  "Хорошо"

**Или я нанимаю другого разработчика.**

---

### Финал: Главное правило

**Не верь обещаниям, верь данным.**

Данные = история разработчика, его velocity, его точность оценок.

Обещание = "я буду быстрее" (никогда не быстрее).

**Второе правило: Видимость = спокойствие.**

Если я вижу code каждый день → я знаю, что происходит.
Если я жду 2 недели, потом вижу, что ничего не готово → паника.

**Третье правило: Цена задержки > цена решения.**

Если задержка стоит $50K, я потрачу $10K на extra разработчика.
Это простая математика.