Нефункциональные требования. Их не видно, пока система не падает.
Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет. Их нельзя показать на демо, за них не платят отдельно и в бэклоге всегда есть фичи «поважнее». До первого инцидента.
Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.
Команда понимала, почему так произошло, и это сильно помогло пройти через ситуацию без лишних конфликтов, но время уже было потеряно.
НФТ бывают очень разными: производительность и нагрузка, масштабируемость (особенно когда команда активно проверяет гипотезы), безопасность, наблюдаемость, сопровождаемость. Бизнес часто их не видит, потому что они не в интерфейсе: нет кнопки — нет ценности.
Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?
· 16.03
По факту это вотчина архитектора. Потому как эти нфт можно соблюсти только при определенной архитектуре системы. И вышестоящие должности. Но в реальности может быть размазано и на другие должности. Особенно если выделенного архитектора нет, и эту роль выполняют другие.
ответить
коммент удалён