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

Как понять, что работа над требованием закончена

Это один из критичных вопросов в системном анализе. Неправильное определение момента завершения приводит к недокомплекту функционала или излишней работе. За 10+ лет выработал четкие критерии.

1. Критерии приёмки (Acceptance Criteria)

Всё начинается с документирования требования.

Перед началом разработки вместе с product owner я определяю чёткие acceptance criteria:

Требование: "Пользователь может фильтровать заказы по дате"

Acceptance Criteria:
☑ Есть UI элемент для выбора диапазона дат
☑ Фильтр работает при выборе "от" даты
☑ Фильтр работает при выборе "до" даты  
☑ Фильтр работает при выборе обоих дат
☑ Если нет данных в диапазоне — показывается "нет заказов"
☑ URL содержит параметры фильтра (для шеринга)
☑ Работает на мобильных устройствах
☑ Performance: загрузка < 500ms для 10,000 заказов

Без AC очень легко разойтись с ожиданиями.

2. Чеклист разработчика

Не требование считается сделанным, пока разработчик не пройдёт эти пункты:

Функциональность: ☑ Код написан ☑ Функция работает на happy path ☑ Обработаны edge cases и ошибки ☑ Логирование и мониторинг добавлены

Качество кода: ☑ Code review пройдена ☑ Нет hardcoded значений ☑ Нет дублирования кода (DRY) ☑ Имена переменных понятные ☑ Следуют стандарты проекта

Тестирование: ☑ Unit тесты написаны (coverage > 80%) ☑ Интеграционные тесты есть ☑ Все тесты проходят ☑ Нет регрессий в других функциях

Документация: ☑ Код задокументирован (docstrings, comments где нужны) ☑ API документация обновлена (если backend) ☑ README обновлён если требуется ☑ Список изменений (changelog) пополнен

3. Чеклист QA

Before QA начинает тестирование, нужно убедиться что требование ready:

Функциональное тестирование: ☑ Протестированы все AC ☑ Happy path работает ☑ Negative scenarios обработаны ☑ Граничные значения проверены

Кроссбраузерное тестирование: ☑ Chrome, Firefox, Safari — последние версии ☑ Mobile: iOS Safari, Chrome Android ☑ IE/Edge если необходимо

Производительность: ☑ Нет memory leaks ☑ Нет затяжных операций ☑ UI responsive (не freezes)

Безопасность: ☑ Нет SQL injection уязвимостей ☑ Нет XSS ☑ Авторизация проверена ☑ HTTPS работает

Usability: ☑ UX соответствует дизайну ☑ Error messages понятные ☑ Нет confusing элементов

4. Определение Definition of Done (DoD)

В командах используем DoD — общее соглашение что означает "сделано".

Пример DoD для требования:

Требование считается Done если:
- Acceptance criteria полностью пройдены
- Code review одобрена как минимум 2 разработчиками
- Все тесты зелёные
- Test coverage >= 85%
- QA одобрила
- Задокументировано
- Готово к production

Важно: DoD должен быть согласован со всей командой и не меняться в процессе спринта.

5. Проверка с Product Owner

После разработки и QA нужна валидация с бизнесом:

Демо:

• Показываю функцию в действии
• Проверяю что именно это требовалось
• Собираю feedback

Вопросы, которые задаю:

• Это соответствует вашим ожиданиям?
• Нужны ли какие-то уточнения?
• Вы готовы отправить в production?
• Есть ли feedback по UI/UX?

Документирование одобрения:

• PO подписывает acceptance (в JIRA, email, Slack)
• Добавляю screenshot demo как доказательство

6. Checklist перед production

Перед релизом проверяю:

Технические требования: ☑ Database миграции готовы ☑ Environment переменные настроены ☑ Логирование полное ☑ Мониторинг и алерты настроены ☑ Rollback план есть

Данные: ☑ Нет hard-coded тестовых данных ☑ Обработаны существующие данные (если миграция) ☑ Backup сделаны

Communication: ☑ Информировал stakeholders ☑ Support team обучена новой функции ☑ Release notes подготовлены

7. Post-release monitoring

Работу не считаю завершённой, пока функция не стабильна в prod.

Первые 24 часа:

• Мониторю логи на ошибки
• Проверяю метрики (нет ли скачков)
• Готов к quick hotfix

Первая неделя:

• Собираю feedback от пользователей
• Ищу performance issues
• Фиксу критичные баги

Первый месяц:

• Анализирую как люди пользуются (analytics)
• Выявляю неожиданное поведение
• Планирую улучшения

8. Признаки что требование ещё не готово

Красные флаги:

• "Почти готово, осталась мелочь" (потом мелочь раздувается)
• AC не пройдены полностью
• Много bugs в QA
• Нет тестов
• Не показывал product owner
• Нет documentation
• "Отправим в prod, потом доделаем" (не отправляй!)

9. Практические примеры

Требование: "Добавить кнопку Экспорт в CSV"

Донне когда: ✓ Кнопка видна на странице ✓ Клик экспортирует текущие данные ✓ Файл скачивается с правильным именем ✓ Поддерживаются Cyrillic символы ✓ Работает на мобильных браузерах ✓ Есть unit тесты ✓ QA протестировала ✓ PO одобрил ✓ В production 24 часа без критичных issues

Требование: "Оптимизировать загрузку страницы на 50%"

Донне когда: ✓ Время загрузки с 2s до 1s (измерено в Chrome DevTools) ✓ Performance на разных сетях проверен (3G, 4G, LTE) ✓ Mobile тоже быстрая ✓ Нет регрессий в других метриках ✓ User experience не пострадала ✓ Monitoring добавлен для отслеживания ✓ PO подтвердил что достаточно быстро

Мой подход

У меня есть простое правило: требование готово, когда я спокойно могу отправить его в production, не волнуюсь что что-то сломается.

Если есть сомнения — требование не готово. Лучше потратить час на доделку, чем неделю на баги в production.