|
|
| Строка 1: |
Строка 1: |
| = Шпаргалка: Аргументация больших оценок по проекту =
| | * [[Обоснование сроков]] |
| | | * [[Регулярные фразы]] |
| == Участники и их ключевые задачи ==
| |
| '''Системный аналитик:'''
| |
| * Анализ БТ (проверка полноты)
| |
| * Проработка ТЗ (техрешения, артефакты)
| |
| * Согласования с архитектором/разработкой
| |
| * Поддержка разработки и тестирования
| |
| | |
| '''Разработчик:'''
| |
| * Декомпозиция задач по фиче
| |
| * Реализация + деплой (СТ → ИФТ → ПреПрод)
| |
| * Багфикс, подготовка релиза | |
| * Дежурство на релизе | |
| | |
| '''Тестировщик:'''
| |
| * Написание кейсов (атомарные + e2e)
| |
| * Тестирование на всех контурах
| |
| * Работа с дефектами + документирование
| |
| * Подготовка к ПСИ/демо
| |
| | |
| == Ключевые аргументы для больших оценок ==
| |
| === 1. Аналитика: высокие риски неполноты ===
| |
| * «Сжатые сроки на анализ → ошибки в ТЗ → переделки в разработке»
| |
| * «Артефакты (АР, ТкИС) требуют проверок и согласований – это время»
| |
| * «Поддержка разработки/тестов – постоянные уточнения»
| |
| | |
| === 2. Разработка: многоэтапный процесс ===
| |
| * «Деплой на 3 контура (СТ → ИФТ → ПреПрод) = минимум N дней»
| |
| * «Багфикс после каждого этапа → циклы ретеста»
| |
| * «Релизные процедуры (ветка, чек-листы) – нельзя сокращать»
| |
| | |
| === 3. Тестирование: объем и документирование ===
| |
| * «Кейсы e2e должны покрывать все сценарии – это X часов»
| |
| * «Артефакты (ПТ, ПМИ) согласуются с другими командами → задержки»
| |
| * «ПСИ/демо – дополнительные ресурсы»
| |
| | |
| == Как отвечать на вопросы ==
| |
| '''Если спрашивают: «Почему так много?»'''
| |
| * «Оценка включает все этапы – от анализа до ПСИ. Сокращение любого из них повысит риски».
| |
| * «Пример: если урезать тестирование, баги уйдут в Prod → дороже исправлять».
| |
| | |
| '''Если предлагают сократить сроки:'''
| |
| * «Возможные компромиссы:
| |
| # Уменьшить scope (выкинуть часть функционала).
| |
| # Добавить ресурсы (но потребуется время на адаптацию).
| |
| # Сократить тестовые контуры (риск пропуска критичных багов)».
| |