Как ставились сроки на последнем месте работы?

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

На моём последнем месте работы в продуктовой IT-компании мы использовали гибридный подход, сочетавший элементы Agile с реалистичным прогнозированием, что позволяло балансировать между гибкостью и обязательствами перед бизнесом.

Ключевые принципы и процессы

1. Иерархия планирования:

• Квартальное планирование (OKR): В начале квартала определялись ключевые результаты (OKRs) на продукт и отделы. Это задавало стратегические рамки и приоритеты.
• Планирование спринта (Sprint Planning): На двухнедельных итерациях мы (команда Frontend, Backend, дизайнер, продакт) оценивали готовые к работе задачи из бэклога.

2. Методы оценки задач:

• Мы применяли планирование покера (Planning Poker) с модифицированной последовательностью Фибоначчи (1, 2, 3, 5, 8, 13, 21). Это помогало выявить расхождения в понимании сложности.
• Задачи размером более 13 story points считались эпиками и обязательно дробились перед внесением в спринт.
• Для оценки использовалась комбинация факторов: сложность логики, необходимость интеграций, состояние legacy-кода, требования к UI/UX (анимации, адаптивность), риски, связанные с новыми технологиями (например, внедрение WebGL или WebAssembly для части функционала).

3. Учёт capacity команды:

• При планировании спринта мы учитывали не идеальные человеко-дни, а реальную доступность (capacity): отпуска, больничные, время на code review, митинги, исследования. Обычно закладывалось 6-6.5 часов продуктивной работы в день.

Роль Frontend-разработчика в процессе

Как старший разработчик, моя ответственность выходила за рамки оценки только своей работы:

• Декомпозиция и уточнение: Перед планированием я анализировал макеты и ТЗ, задавая уточняющие вопросы дизайнерам и продакт-менеджеру. Часто выявлялись "узкие места": например, неочевидные состояния компонентов или отсутствие API-контрактов.

  // Пример: Изначальная задача "Добавить валидацию формы" дробилась на:
  // 1. Интеграция с react-hook-form
  // 2. Кастомные валидаторы для email/phone
  // 3. Визуальный показ ошибок (с анимацией)
  // 4. Блокировка кнопки отправки
  // 5. Юнит-тесты для валидаторов
  

• Технический долг и инфраструктура: Я отстаивал включение в спринт задач по техдолгу и обновлению библиотек (например, миграция с Webpack на Vite), что влияло на долгосрочную скорость.
• Обучение и менторинг: В оценку задач джунов закладывалось время на мой code review и правки.

Коммуникация сроков с бизнесом и управление ожиданиями

• Прогноз vs. Дедлайн: Мы чётко разделяли прогноз, основанный на текущей скорости команды (velocity), и жёсткий дедлайн, обусловленный внешними событиями (например, запуск рекламной кампании).
• Визуализация и прозрачность: Прогресс был виден всем стейкхолдерам в Jira через burndown charts и скрам-/канбан-доски.
• Эскалация рисков: Если в процессе спринта возникали непреодолимые блокеры (например, критическая зависимость от другой команды), я немедленно информировал тимлида и продакта для корректировки планов или переговоров о сроках.

Результат: Такой подход снижал количество "сорванных" сроков на 30-40% по сравнению с периодом, когда оценки спускались "сверху". Он формировал у команды чувство ответственности за данные承诺 (commitments), а у бизнеса — реалистичное понимание возможностей разработки. Ключевым уроком стало то, что точные сроки — это не самоцель, а результат совместной работы над качественным планированием, прозрачностью и постоянной коммуникацией.