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

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

Ставить задачи по срокам — это балансирование между амбициями и реальностью. Неправильные сроки — это главный источник stress и burnout в технических командах. Я узнал этому на собственном опыте, поэтому approach очень специфичный.

Основной принцип: не-срочные дедлайны, срочные гипотезы

Я ставлю не сделать до 30 апреля, а нам нужно проверить гипотезу про retention к концу квартала, и это требует фичу X. Разница в том, что первый вариант — это deadline, а второй — это контекст.

Процесс планирования спринта (2-недельный цикл)

Шаг 1: Оценка ёмкости (ёмкость Estimation)

Я не верю в perfect оценки, поэтому использую story points или simple t-shirt sizing (S, M, L, XL).

Как это работает:

• S (Small): 1-3 дней работы (простой баг, очень понятная фича)
• M (Medium): Неделя работы (обычная фича)
• L (Large): 2-3 недели (сложная фича, требует рефакторинга)
• XL: 4+ недель (проект для полного спринта или больше)

Пример обсуждения:

• Я: Мне нужна фича Экспорт в CSV
• Разработчик: Это M — неделя работы
• Я: Сколько ёмкости на спринт? Разработчик: 40 points
• Я: Тогда это поместится, но нужно отодвинуть другую M задачу

Шаг 2: Приоритизация в порядке убывания

Я использую уже описанный фреймворк RICE для выбора приоритетов:

1. Задача A: RICE score 8000 (выполняет 30% roadmap)
2. Задача B: RICE score 4000 (выполняет 50% roadmap)
3. Задача C: RICE score 2000 (технический долг)

Правило: На спринт планирую максимум 80% ёмкости команды. 20% оставляю на неожиданное.

Пример спринта:

• Total capacity: 40 points
• Планирую: 32 points (80%)
• Оставляю 8 points на срочные баги

Шаг 3: Разбор на tasks (большие фичи)

Если задача L или XL, я не ставлю просто сделать — я разбиваю на маленькие куски:

Вместо: Реализовать платежную систему (XL, 4 недели)

Я делаю:

1. Дизайн и архитектура платежной системы (L, 3 дня, sprint 1)
2. Backend: интеграция с Stripe API (L, 5 дней, sprint 2-3)
3. Frontend: UI платежной формы (M, 4 дня, sprint 3)
4. Testing и security audit (M, 3 дня, sprint 4)

Почему: Когда задача видна как маленькие шаги, люди видят прогресс. Это мотивирует.

Шаг 4: Коммуникация deadline

Я избегаю фраз должно быть готово к X дате. Вместо этого:

Плохо: Платежную систему нужно закончить к 15 апреля Хорошо: Нам нужна платежная система к 15 апреля, потому что запускаем enterprise план и нам нужны 2 недели на sales. Если будет задержка на неделю, мы отложим лаунч. Какие блокеры видишь?

Это дает людям контекст. Они понимают, ЗАЧЕМ срок важен, и могут сами решить, как организовать работу.

Как я обращаюсь со сложными deadline'ами

Сценарий 1: Нужно ВЧЕРА

Ситуация: Ключевой клиент просит фичу, которая займёт 2 недели, а она нужна ему завтра.

Процесс:

1. Спрашиваю: Какая минимальная версия нужна? (Часто 80% фичи занимает 20% времени)
2. Можем ли мы сделать 80% версию за день?
3. Потом доделаем остальное в следующие 2 недели

Коммуникация с командой:

• Я: Это ОЧЕНЬ спешно, но это ключевой клиент, и это даст нам $200k в году
• Я: Можно ли за 24 часа сделать вот это? (указываю 80% версию)
• Если да: Спасибо, после этого вернемся в нормальный ритм
• Если нет: Ок, скажите максимум что можно

Сценарий 2: Оценили неправильно

Разработчик говорит после 3 дней: Я оценил это как M, но оказалось L. Нужно ещё 5 дней.

Я НЕ говорю: Ты неправильно оценил, давай в срок

Я говорю:

1. Спасибо за честность. Что изменилось в оценке? (Хочу понять, почему)
2. Какой вариант есть? (Может быть фича can быть упрощена?)
3. Давайте сделаем так... (Выбираем вместе)

Варианты:

• Отодвинуть дедлайн на 5 дней (и пересчитать, что выпадет)
• Упростить фичу и доделать потом
• Вовлечь другого разработчика

Сценарий 3: Непредвиденный баг в production

Все дропают дела и фиксят. Это нормально.

Как я планирую для этого:

• Никогда не планирую на 100% (оставляю 20%)
• Есть на-call разработчик, который может выезжать
• После фикса — retro: Как мы можем это предотвратить?

Инструменты и практики

Я использую:

• Linear/Jira: Задачи с описанием, acceptance criteria, story points
• Roadmap: Публичная дорога (что делаем в этом месяце, следующем, квартале)
• Slack reminders: Еженедельный напоминание о статусе спринта

Meetings:

• Sprint Planning (1-1.5 часа): Что берём в спринт, кто за что отвечает
• Daily Standup (15 мин): Статус, блокеры (если блокер — сразу решаю)
• Sprint Review (1 час): Показываем demo работы, собираем feedback
• Sprint Retro (45 мин): Что прошло хорошо, что плохо, что улучшить

Красные флаги (когда сроки неправильные)

1. Люди регулярно работают сверхурочно для срока

   • Это знак, что я неправильно планирую
   • Сроки нужно удлинить или задачи уменьшить

2. Оценки систематически неправильные

   • Мы переоцениваем сложность на 50%?
   • Нужен retro: Почему мы плохо оцениваем?

3. После дедлайна фича сломана

   • Спешили, не протестировали
   • Лучше отложить на неделю, чем запустить баг

4. Люди не говорят об ошибках

   • Команда боится сказать я не успею
   • Это значит я создал небезопасную среду
   • Нужно меняться

Мотивация вместо наказания

Вместо: Если не сделаешь к дедлайну, будет проблема

Я использую:

• Контекст: Это поможет нам получить $200k
• Гибкость: Если нужно 5 дополнительных дней, скажи
• Recognition: Спасибо, что на выходных подправил баг (но это исключение, не норма)
• Fair rewards: Хорошая зарплата, бонусы по результатам, отпуск

Главное правило: сроки нужны для бизнеса, но люди — это все. Если за сроками потеряю людей, бизнеса не будет.