Как ответишь участнику команды, запрашивающему сроки проекта, если сроки определить невозможно

Как ответить на запрос сроков, когда они неопределённы

Это не техническое, а управленческое умение, которое отличает хорошего разработчика от просто кодера. Столкнулся с этим много раз.

Проблема: давление на сроки

Сценарий:

Меджер: "Когда будет готово?"
Вы: "Не знаю, задача сложная"
Меджер: "Но нам нужно обещать клиенту сроки!"
Вы: "..."

Ошибка: дать угадаемый срок = потом срываем сроки = потом теряем доверие.

Правильный подход: прозрачность и этапы

Фраза 1: Признать неопределённость

"Я не могу дать точный срок прямо сейчас, потому что:

1. Есть неизвестные аспекты в требованиях
2. Есть технические риски, которые нужно исследовать
3. Зависимости от других команд

НО я могу предложить план как их снизить."

Это честно и профессионально. Менеджер это уважит больше, чем если вы потом сорвёте сроки.

Фраза 2: Предложить структурированный подход

"Давайте сделаем R&D спринт (2-3 дня):

1️⃣ Разобраться в требованиях (2 часа)
2️⃣ Исследовать технические риски (1 день)
3️⃣ Проверить зависимости (2 часа)
4️⃣ Дать оценку по Agile (3 часа)

После этого я смогу дать вам диапазон: ±30% от оценки.

Пример графика:

Недовольство<────────────────────────────────────>Точность
Точная дата    Диапазон    Вилка      Сценарии
(угадаем)      ±2 дня      ±1 неделя  (best/avg/worst)
   ↓             ↓            ↓          ↓
  5 дня     3-7 дней    3 дня - 2 нед  Best: 3, Avg: 7, Worst: 14

✓ Выбираем диапазон → меньше стресса

Фраза 3: Три сценария

"По опыту, проекты такой сложности выглядят так:

OPTIMISTIC (лучший случай): 2 недели
  - Все требования ясны
  - Никаких проблем с зависимостями
  - Удача со сложностью

NOMINAL (средний случай): 3-4 недели ← ПРЕДЛАГАЮ ОБЕЩАТЬ ЭТОТ
  - Требования уточняются по пути
  - Небольшие проблемы с интеграциями
  - Обнаруживаем 1-2 edge case'а

PESSIMISTIC (худший случай): 6-8 недель
  - Много неясностей в требованиях
  - Серьёзные проблемы с зависимостями
  - Нужно переделывать архитектуру

Я рекомендую планировать на NOMINAL сценарий.
ESTIMATE: 3-4 недели."

Фраза 4: Раньше? Договариваемся о tradeoffs

"Если нужно ускориться, мы можем:

✓ Добавить людей на задачу (но это замедлит в начале)
✓ Расширить scope later (убрать features из версии 1.0)
✓ Потратить меньше времени на testing (но риск багов)
✓ Убрать требования к performance/scalability
✓ Отложить код review (не рекомендую)

Что из этого приемлемо?"

Важно: никогда не говорите "да, можем быстрее" без tradeoff-ов. Это ложь.

Фраза 5: Промежуточные результаты

"Давайте разобьём на этапы с demos:

Недели 1-2: Core functionality
  - Можете увидеть работающий prototype на конец недели 1
  
Недели 2-3: Integration + performance
  - Готово работать с production данными
  
Недели 3-4: Refinement + tests
  - Готово к release

Между этапами у нас будут feedback loops,
и мы сможем корректировать оценку."

Это дает менеджеру visibility и уверенность.

Фраза 6: Документирование рисков

// Risk Register (ведём во время проекта)
1. Неясная архитектура микросервисов
   Impact: High (может потребовать переделки)
   Probability: Medium (потребуется дополнительный R&D)
   Mitigation: Архитектурный review на неделе 1
   Timeline impact: +3 дня

2. Зависимость от API third-party service
   Impact: Medium (может быть задержка API)
   Probability: Low (но может быть)
   Mitigation: Мок сервис параллельно
   Timeline impact: +1 день if happens

3. Требования меняются
   Impact: High
   Probability: High (всегда меняются)
   Mitigation: Agile approach, 2-week sprints
   Timeline impact: Variable

Показываем это менеджеру → они видят что вы думаете реалистично.

Фраза 7: Если настаивают на точной дате

"Я понимаю нужна дата для клиента.

Если я скажу 'готово в среду', а в среду не будет готово,
Это потеря доверия — как к вам, так и ко мне.

Давайте сделаем так:

1. Обещаем клиенту: '3-4 недели' (диапазон)
2. Мне даёте 3 дня на R&D
3. После R&D я скажу точнее: '14-16 дней' 
4. Когда я уверен на 90% — говорю дату
5. К этой дате добавляю buffer (15%)

Лучше обещать позже и выполнить вовремя,
Чем обещать раньше и сорвать сроки."

Примеры хороших ответов

1️⃣短ANSWER (когда спешат)
"Нужен день на исследование. Завтра скажу точнее."

2️⃣ MEDIUM ANSWER (стандартный случай)
"По предварительной оценке 2-3 недели.
Но нужна дополнительная информация про [требование].
Давайте уточним требования — и я дам гарантию ±10%."

3️⃣ LONG ANSWER (сложный проект)
"Задача имеет несколько неизвестных:
- Архитектура микросервисов (нужен дизайн док)
- Интеграция с legacy системой (нужна информация)
- Требования к масштабируемости (уточним с бизнесом)

Предлагаю:
1. Sprint 0 (3 дня): Исследование + дизайн
2. Sprint 1-2: MVP (2 недели)
3. Sprint 3: Refinement (1 неделя)

Общий диапазон: 2-4 недели, после Sprint 0 будет точнее."

4️⃣ КОГДА СРОКИ УЖЕ СОРВАНЫ
"Я сорвал сроки. Вот почему:
1. [Причина 1]
2. [Причина 2]
3. [Что я буду делать иначе]

Новая оценка: [дата]. Я это гарантирую."

Чеклист честного ответа

✅ Признал неопределённость (не угадываю) ✅ Предложил план как её снизить ✅ Дал диапазон вместо точной даты ✅ Обозначил риски и mitigation ✅ Готов к tradeoff-ам ✅ Обещаю меньше, чем думаю (всегда есть буфер) ✅ Документирую предположения ✅ Готов дать промежуточные результаты

Фраза для начальника/PM

"Я хочу быть надёжным членом команды.
Это значит:
- Не обещаю то, в чём не уверен
- Говорю рисковые моменты заранее
- Если срок не получится — дам знать за день
- Никогда не скрываю проблемы

Доверие важнее оптимизма."

Итоговый совет

В 10 лет я видел проекты, которые:

🔴 ПРОВАЛИЛИСЬ: разработчик сказал "готово в пятницу", но не было 🟢 УСПЕШНЫЕ: разработчик сказал "3-4 недели, вот как это отследить"

Второй вариант всегда выигрывает.