Шесть правил сбора нефункциональных требований

Изображение сгенерировано нейросетью.

Вчера я посетил мастер-класс по сбору нефункциональных требований (НФТ), который провели Даниил Подольский и Филипп Дельгядо. В очередной раз меня впечатлили глубокие мысли спикеров, в которых чувствуется их многодесятилетний опыт. По итогам мастер-класса я сформулировал для себя шесть правил сбора НФТ и спешу поделиться ими с вами.

1. Анализируй User Story, а не голые цифры

Принятие архитектурных решений исключительно на основе средних арифметических значений — это ловушка, в которую попадают даже опытные архитекторы. Цифры вне контекста пользовательского сценария дезориентируют. Например, средняя загрузка сервиса в 100 запросов в секунду может скрывать пиковые всплески в моменты бизнес-событий. Архитектор обязан погружаться в нарратив использования системы. Важно не просто знать, что RPS равен N, а понимать распределение нагрузки по процентилям. Значение на 99-м процентиле часто кратно превышает медиану, и именно оно диктует требования к масштабированию.

Рассмотрим классический сценарий электронной коммерции с историей «После Черной пятницы будет больше споров». Средняя нагрузка на модуль арбитража может составлять 10 обращений в минуту, однако в конкретную дату, через 3–5 дней после распродажи, она возрастает в 3–5 раз. Если архитектор заложит решение исходя из среднего значения, система рухнет именно тогда, когда репутационные риски компании максимальны.

2. Управляй регламентами НФТ

НФТ являются ограничениями, а не бесплатным приложением к функциональности. В отличие от фич, которые генерируют выручку, НФТ потребляют ресурсы команды и бюджет. Каждый раз, когда архитектор вносит ограничение вроде «максимальный размер загружаемого файла 5 МБ», он меняет дизайн и пользовательский опыт. Это ограничение порождает целый каскад технических и продуктовых последствий. В UI появляется прогресс-бар, предупреждение о лимите, а на бэкенде включается алгоритм принудительного сжатия изображения до разрешения, например, 1200px по длинной стороне с качеством 80%.

Поэтому НФТ требуют строгого документирования в виде регламентов или записей в ADR. Важно явно зафиксировать, что подобное поведение системы не является ошибкой или недоработкой, а представляет собой осознанное архитектурное ограничение. Нужно донести до продакт-менеджера ценность такого ограничения, потому что альтернативой является экспоненциальный рост счетов за облачное хранилище и сетевой трафик. Эффективный архитектор управляет ожиданиями стейкхолдеров, переводя дискуссию из плоскости «сделайте неограниченно» в плоскость «сколько бизнес готов платить за каждые дополнительные 5 МБ на пользователя».

3. Не переоценивай стоимость падения

Оценка ущерба от простоя системы — одно из самых манипулятивных полей в IT. Бизнес-заказчики часто считают потери по формуле «средняя выручка в минуту, умноженная на время простоя», требуя RTO (Recovery Time Objective), равное нулю, и RPO (Recovery Point Objective), равное нулю. Такой подход игнорирует фундаментальное свойство пользовательского поведения — эффект отложенного спроса. Если сервис кратковременно недоступен, значительная часть пользователей не уходит к конкуренту безвозвратно, а просто повторяет попытку через некоторое время после восстановления работы. Конечно, если на восстановление ушли целые дни, то для компании явно есть потери.

Поэтому сбор НФТ должен включать аудит реальной чувствительности бизнеса к прерыванию сервиса. Опрос стейкхолдеров следует проводить не в формате абстрактных ожиданий о «пяти девятках», а через призму конкретных сценариев. Вопрос «Что произойдет, если чат поддержки встанет на 20 минут в 3 часа ночи?» гораздо информативнее вопроса «Сколько девяток доступности вам нужно?». Понимание того, что клиент напишет в чат позже, снижает приоритет дорогостоящей схемы георезервирования Active-Active в пользу более экономного Warm Standby. Деньги, сэкономленные на избыточном резервировании, можно направить на погашение технического долга, что в долгосрочной перспективе является более значимым вкладом в надежность системы, чем мгновенный автоматический failover любой ценой.

4. Экономь ресурсы команды

Архитектура программного обеспечения — это не только код и инфраструктура, но и организация труда людей, которые все это поддерживают. Сбор экономических ограничений и анализ операционных расходов (OPEX) являются прямой обязанностью архитектора. Когда команда перегружена задачами на 150% от своих возможностей, она неизбежно накапливает технический долг и допускает ошибки на проде. В такой среде погашение долга становится невозможной роскошью, что запускает порочный круг снижения качества.

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

Цель такого маневра — привести загрузку команды к устойчивому уровню в 80% или ниже. Только в этом случае у инженеров появляется время на рефакторинг, обновление библиотек и внедрение практик надежности. Следовательно, снижение функционального разнообразия системы является прямым методом выполнения НФТ по сопровождаемости и надежности.

5. Управляй рисками несоответствия и находи компромиссы

Работа с требованиями регуляторов часто ставит архитектора в тупик из-за невозможности выполнить их на 100% в рамках разумного бюджета и сроков. Попытка реализовать букву закона без оглядки на техническую реальность может парализовать разработку. В таких ситуациях критически важно перевести проблему из технической плоскости в плоскость управления рисками. Архитектор не обязан лично интерпретировать юридические нормы, но он обязан инициировать диалог между юристами, продакт-менеджерами и техническими специалистами.

Паттерн поведения здесь заключается в формализации компромиссного решения и осознанном принятии рисков. Необходимо зафиксировать, какие именно аспекты требований регулятора не будут удовлетворены в релизе, почему это невозможно технически на данном этапе и какие у этого могут быть последствия. В некоторых случаях в компании может быть принят риск полного несоответствия требованию до определенного момента. Такой документ (risk acceptance) снимает с архитектора и команды разработки персональную ответственность за инциденты, связанные с комплаенсом, и переводит ее на уровень принятия бизнес-решений. Это позволяет продолжать поставку ценности, не погрязая в бесконечных попытках сделать систему идеально соответствующей всем нормативным актам.

6. Знай своих стейкхолдеров и скрытые мотивы

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

Даниил Подольский описывал показательный кейс, когда команда блестяще реализовала проект, полностью удовлетворив требования непосредственного заказчика. Однако после сдачи выяснилось, что руководитель этого заказчика, обладающий большим политическим весом, был категорически против данного функционала. В результате труд команды был потрачен впустую. Поэтому работа с реестром заинтересованных лиц и построение карты их интересов (Power-Interest Grid) являются неотъемлемой частью архитектурного анализа. Архитектор должен уметь задавать неудобные вопросы о том, кому именно мешает или помогает данное решение, и только затем принимать окончательное техническое решение, соответствующее реальному распределению власти в компании.