Обоснование сроков

Шпаргалка: Аргументация больших оценок по проекту

Участники и их ключевые задачи

Системный аналитик:

• Анализ БТ (проверка полноты)
• Проработка ТЗ (техрешения, артефакты)
• Согласования с архитектором/разработкой
• Поддержка разработки и тестирования

Разработчик:

• Декомпозиция задач по фиче
• Реализация + деплой (СТ → ИФТ → ПреПрод)
• Багфикс, подготовка релиза
• Дежурство на релизе

Тестировщик:

• Написание кейсов (атомарные + e2e)
• Тестирование на всех контурах
• Работа с дефектами + документирование
• Подготовка к ПСИ/демо

Ключевые аргументы для больших оценок

1. Аналитика: высокие риски неполноты

• «Сжатые сроки на анализ → ошибки в ТЗ → переделки в разработке»
• «Артефакты (АР, ТкИС) требуют проверок и согласований – это время»
• «Поддержка разработки/тестов – постоянные уточнения»

2. Разработка: многоэтапный процесс

• «Деплой на 3 контура (СТ → ИФТ → ПреПрод) = минимум N дней»
• «Багфикс после каждого этапа → циклы ретеста»
• «Релизные процедуры (ветка, чек-листы) – нельзя сокращать»

3. Тестирование: объем и документирование

• «Кейсы e2e должны покрывать все сценарии – это X часов»
• «Артефакты (ПТ, ПМИ) согласуются с другими командами → задержки»
• «ПСИ/демо – дополнительные ресурсы»

Как отвечать на вопросы

Если спрашивают: «Почему так много?»

• «Оценка включает все этапы – от анализа до ПСИ. Сокращение любого из них повысит риски».
• «Пример: если урезать тестирование, баги уйдут в Prod → дороже исправлять».

Если предлагают сократить сроки:

• «Возможные компромиссы:

 # Уменьшить scope (выкинуть часть функционала).
 # Добавить ресурсы (но потребуется время на адаптацию).
 # Сократить тестовые контуры (риск пропуска критичных багов)».