Нефункциональные требования. Их не видно, пока система не падает.

Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет. Их нельзя показать на демо, за них не платят отдельно и в бэклоге всегда есть фичи «поважнее». До первого инцидента.

Один из моих ранних кейсов был как раз про это. Мы не заложили нагрузочное тестирование до старта MVP. Архитектор поднимал вопрос, но в бэклоге были фичи и жёсткий дедлайн. Перед релизом система не прошла нагрузочный тест. В итоге — два спринта рефакторинга и перенос релиза.

Команда понимала, почему так произошло, и это сильно помогло пройти через ситуацию без лишних конфликтов, но время уже было потеряно.

НФТ бывают очень разными: производительность и нагрузка, масштабируемость (особенно когда команда активно проверяет гипотезы), безопасность, наблюдаемость, сопровождаемость. Бизнес часто их не видит, потому что они не в интерфейсе: нет кнопки — нет ценности.

Интересно, как это устроено у вас. Кто в команде держит список нефункциональных требований — архитектор, тимлид или это появляется по мере необходимости?

Нефункциональные требования.
Их не видно, пока система не падает.
Нефункциональные требования — это то, что бизнес почти никогда не ставит в приоритет | Сетка — социальная сеть от hh.ru