Заказчик не знает, что такое НФТ. И не должен

"Какие у вас нефункциональные требования?" — спрашиваю на встрече.

Заказчик смотрит как на инопланетянина.

Он не мыслит категориями "производительность 1000 RPS" или "доступность 99.9%". Он вообще не понимает, чего я от него хочу.

Зато он точно знает, как его бизнес работает. И вот из этого ты сам выводишь НФТ.

ФТ vs НФТ — в чём разница

Функциональные требования — это ЧТО система делает. Нефункциональные — это КАК она это делает.

Пример: "Пользователь может авторизоваться" — это ФТ. "Авторизация занимает не больше 2 секунд" — это НФТ.

ФТ отвечают на вопрос: какие функции есть? НФТ отвечают на вопрос: с какими ограничениями?

Основные типы НФТ

🔸 Производительность — сколько запросов в секунду, время отклика 🔸 Доступность — какой процент времени система работает (SLA 99.9% = 8 часов простоя в год) 🔸 Масштабируемость — что будет при росте нагрузки в 10 раз 🔸 Безопасность — кто имеет доступ, шифрование, аудит 🔸 Надёжность — что происходит при сбоях, как восстанавливаемся 🔸 Совместимость — с какими браузерами, ОС, устройствами работает 🔸 Локализация — языки, часовые пояса, форматы дат

Проблема в том, что заказчик не думает этими категориями. Он думает своим бизнесом.

Кейс с собеседования

На интервью в Леруа Мерлен дали задачку: приложение, которое показывает сотрудникам — сейчас день или ночь. Нужно собрать функциональные и нефункциональные требования.

Звучит как шутка. Но попробуй вытащить из этого НФТ.

Я начал спрашивать:

🔸 Сколько человек работает в компании? → 20 000 сотрудников → понимаю нагрузку

🔸 Есть геораспределение? Часовые пояса важны? → Магазины по всей стране → нужна логика определения времени по локации

🔸 Как будут использовать и зачем вообще? → "По приколу, сидят в тёмном помещении, не знают — идти домой или нет" → Низкая критичность, не нужен SLA 99.99%

🔸 На каких устройствах? → Личные телефоны → кроссплатформенность, разные версии ОС

Из ответа про использование понял ещё кое-что: пики нагрузки будут в начале рабочего дня и под конец. Все одновременно проверяют — пора домой или нет.

Что я упустил

Не спросил: "Нужно ли собирать статистику? Логировать действия? Синхронизировать что-то между пользователями?"

Если нет — день/ночь можно определять вообще без сервера, просто по времени на телефоне. И тогда:

🔸 Нет бэкенда → нет нагрузки 🔸 Нет интернета → работает офлайн 🔸 Нет синхронизации → нет проблем с часовыми поясами

Один вопрос мог изменить всю архитектуру.

Вопросы, которые вытаскивают НФТ

Заказчик не скажет "мне нужна доступность 99.9%". Но ответит на:

🔸 "Что случится, если система не будет работать час? День?" → Критичность, требования к доступности

🔸 "Сколько человек будет пользоваться одновременно?" → Нагрузка, производительность

🔸 "Откуда будут заходить — офис, дом, в дороге?" → Мобильность, офлайн-режим

🔸 "Данные одинаковые для всех или у каждого свои?" → Архитектура, где хранить логику

🔸 "Что будет через год — пользователей станет больше?" → Масштабируемость

🔸 "Кто не должен видеть эти данные?" → Безопасность, разграничение доступа

Выводы для аналитика

🔸 Не спрашивай про НФТ напрямую — спрашивай про сценарии использования 🔸 Из контекста бизнеса рождаются конкретные требования 🔸 Один вопрос про архитектуру может перевернуть всё решение 🔸 Упущенное ограничение больнее упущенной фичи — фичу добавишь, а переделывать архитектуру дорого

Да не суть, но с функционалом все справляются. А вот ограничения — это то, что отличает джуна от мидла.

А вы как вытаскиваете НФТ из заказчиков? Есть любимые вопросы?

@analyst_exe