✅ Почему это нефункциональное требование:
Нефункциональные требования (NFR — Non-Functional Requirements) описывают не что система делает, а как она это делает, насколько хорошо, быстро, безопасно, удобно. В данном случае указаны измеримые показатели производительности: 1000 запросов в секунду (нагрузочная способность) и время отклика 2 секунды (латентность). Это классические атрибуты качества, которые относятся к нефункциональным требованиям. Они критически важны для архитектуры системы — под них проектируют масштабирование, выбирают оборудование, настраивают кэширование.
❌ Почему не подходят другие варианты:
A (Функциональное требование): Функциональные требования описывают конкретные функции, которые система должна выполнять. Примеры: «Система должна позволять переводить средства между счетами», «Система должна отображать историю операций». Требование про 1000 RPS не описывает функцию, а устанавливает критерий качества выполнения функций.
C (Бизнес-требование): Бизнес-требования формулируются на языке бизнеса и описывают цели, которые заказчик хочет достичь. Пример: «Увеличить долю рынка на 5% за счёт запуска мобильного приложения». Требование про 1000 RPS — это уже техническая детализация, а не бизнес-цель.
D (Ограничение): Ограничения (constraints) — это жёсткие рамки, которые нельзя менять. Они могут быть техническими («использовать только PostgreSQL»), организационными («разработка ведётся распределённой командой»), бюджетными или временными. Требование производительности — это цель, а не ограничение; его можно достичь разными способами.
Совет: В реальных проектах нефункциональные требования часто "забывают" или формулируют размыто («система должна быть быстрой»). Профессиональный аналитик всегда добивается измеримых метрик, как в этом примере, потому что иначе невозможно ни спроектировать архитектуру, ни проверить результат.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
4706. ам нужно быстро разобраться в реальных процессах работы склада для их автоматизации. Руководитель дал неделю на сбор требований. Какой метод сбора требований даст наиболее достоверную картину?
Anonymous Quiz
16%
Провести анкетирование всех сотрудников склада
9%
Изучить должностные инструкции и отчёты
39%
Применить метод наблюдения и теневого копирования
35%
Организовать фокус-группу с начальниками смен
✅ Почему наблюдение (shadowing) — лучший выбор:
Метод теневого копирования предполагает, что аналитик буквально следует за сотрудником в течение рабочего дня, наблюдает за его действиями, задаёт вопросы по ходу. Это позволяет увидеть:
Реальные действия, которые часто отличаются от описанных в инструкциях
Неформальные практики и «обходные пути», выработанные годами
Узкие места, которые сотрудники уже не замечают
Исключительные ситуации, которые не попадают в отчёты
Для склада, где много физических операций и неформальных коммуникаций, это незаменимый метод. За неделю можно охватить ключевые роли и составить достоверную картину.
❌ Почему другие варианты хуже:
A (Анкетирование): Анкеты дают субъективные ответы, люди склонны приукрашивать или упрощать. Кроме того, многие вещи сотрудники делают автоматически и не могут их описать в анкете. Анкетирование хорошо для сбора мнений, но не для изучения процессов.
B (Изучение документов): Должностные инструкции и отчёты показывают лишь «идеальную» картину, как должно быть по мнению руководства. Реальность почти всегда отличается, иногда кардинально. Документы не раскрывают неформальные практики и реальные проблемы.
D (Фокус-группа с руководителями): Начальники смен знают процессы, но часто — со своей управленческой колокольни. Они могут не знать деталей, с которыми сталкиваются рядовые сотрудники. Кроме того, в группе люди склонны соглашаться с мнением руководства, а не высказывать реальные проблемы.
Совет: В реальных проектах лучший результат даёт комбинация методов. Можно начать с наблюдения, чтобы понять реальность, затем уточнить детали в интервью с ключевыми сотрудниками, и уже потом сверяться с документами. Но если нужно выбрать один метод для быстрого погружения — наблюдение вне конкуренции.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
4707. Бюджет проекта ограничен, а список хотелок заказчика огромен. Нужно выделить требования для MVP (minimum viable product), которые обязательно должны войти в первую версию. Какую технику приоритизации лучше применить?
Anonymous Quiz
73%
MoSCoW
7%
Kano Model
16%
100-долларовый метод
4%
Pairwise comparison
✅ Почему MoSCoW — лучший выбор:
MoSCoW — это аббревиатура, которая делит требования на четыре категории:
Must have — критически важно, без этого продукт не имеет смысла
Should have — важно, но можно отложить на следующий релиз
Could have — желательно, но не критично
Won't have — точно не в этом релизе (но возможно в будущем)
Эта техника специально разработана для быстрой приоритизации в условиях ограниченных ресурсов. Она заставляет заказчика делать жёсткий выбор и чётко выделяет границы MVP. MoSCoW легко понять всем участникам — от бизнеса до разработчиков.
❌ Почему другие варианты хуже:
B (Kano Model): Kano модель оценивает влияние требований на удовлетворённость пользователей, разделяя их на «базовые», «линейные» и «восхищающие». Это полезно для понимания, какие функции сделают продукт конкурентоспособным, но не даёт жёсткой приоритизации под бюджет. Kano хороша для стратегического планирования, а не для выделения MVP.
C (100-долларовый метод): Участники распределяют 100 условных долларов между требованиями, показывая их относительную важность. Метод полезен для сбора мнений группы, но результат субъективен и не даёт чёткой категоризации «обязательно/необязательно». К тому же, он трудоёмок при большом количестве требований.
D (Pairwise comparison): Попарное сравнение (каждое требование с каждым) даёт точную числовую оценку приоритетов, но при N требований требует N*(N-1)/2 сравнений. Для списка из 50 требований это 1225 сравнений — непозволительная роскошь при ограниченном времени.
Совет: В реальных проектах MoSCoW часто комбинируют с голосованием или стоимостной оценкой. Но как базовый инструмент для выделения MVP он остаётся стандартом де-факто.
Please open Telegram to view this post
VIEW IN TELEGRAM
4708. В середине спринта заказчик обращается с просьбой добавить новое требование: «Хочу, чтобы в личном кабинете отображалась история покупок за всё время». Команда уже загружена задачами спринта. Что должен сделать аналитик в первую очередь?
Anonymous Quiz
1%
Согласиться и добавить задачу в текущий спринт
2%
Отказать, сославшись на занятость команды
93%
Оценить влияние требования, задокументировать и добавить в бэклог для следующего спринта
4%
Провести переговоры с заказчиком о замене одного требования другим
✅ Почему вариант C — правильный:
В Scrum (и других Agile-методах) действует правило: изменения в текущий спринт не вносятся, чтобы команда могла спокойно достичь спринт-цели. Аналитик должен:
Задокументировать новое требование (чтобы не забыть)
Помочь команде грубо оценить его сложность (хотя бы по шкале S/M/L)
Добавить его в бэклог продукта
На ближайшем планировании спринта команда вместе с заказчиком решит, насколько это требование приоритетно по сравнению с другими
Такой подход сохраняет предсказуемость спринта и уважает работу команды, но при этом не игнорирует потребности заказчика.
❌ Почему другие варианты хуже:
A (Согласиться и добавить): Это прямой путь к срыву сроков. Добавление новой задачи без пересмотра остальных приведёт либо к перегрузке команды, либо к тому, что что-то другое не будет сделано. Scrum-мастер такого не допустит, и правильно.
B (Отказать): Жёсткий отказ без обсуждения испортит отношения с заказчиком. Возможно, требование действительно критичное для бизнеса, и тогда надо искать компромисс (например, заменить менее важную задачу). Аналитик не должен быть «стеной», он должен быть коммуникатором.
D (Переговоры о замене): Это возможный следующий шаг, но не первый. Сначала требование нужно зафиксировать и оценить, иначе непонятно, на что его менять. К тому же, замена одного требования другим в текущем спринте — это исключительная мера, которая требует согласия всей команды и пересмотра спринт-цели.
Совет: В реальной жизни после такого обращения аналитик обычно говорит: «Отличная идея, давайте я её запишу. Мы посмотрим, сколько это примерно займёт, и на следующем планировании решим, что важнее — эта история или то, что мы запланировали на следующий спринт». Заказчик чувствует, что его слышат, а команда защищена от хаоса.
Please open Telegram to view this post
VIEW IN TELEGRAM
4709. Для описания процесса оплаты заказа в интернет-магазине нужно предусмотреть основной сценарий (успешная оплата) и альтернативные (ошибка ввода карты, недостаточно средств, отмена пользователем). Какой формат спецификаций лучше всего подойдёт?
Anonymous Quiz
11%
User Story: «Как покупатель, я хочу оплатить заказ картой, чтобы получить товар».
81%
Use Case с основным и альтернативными потоками
7%
Бизнес-правило в виде таблицы решений
1%
Прототип интерфейса (мокапы)
✅ Почему Use Case — лучший выбор:
Use Case (вариант использования) был придуман именно для описания взаимодействия пользователя с системой, включая:
Основной (успешный) сценарий — «счастливый путь»
Альтернативные потоки — варианты, отличающиеся от основного
Исключения — ошибки, сбои
Предусловия и постусловия
Всё это структурировано и читаемо. Для процесса оплаты Use Case позволит описать шаг за шагом, что происходит при успешной оплате, что при ошибке ввода CVV, что при отмене, что при таймауте платежного шлюза.
❌ Почему другие варианты хуже:
A (User Story): User Story — это «карточка-напоминалка» для команды, она намеренно короткая и не детализирует альтернативные сценарии. Хорошая User Story обрастает Acceptance Criteria, но если альтернативных потоков много, описание в виде списка условий становится громоздким и теряет наглядность последовательности.
C (Таблица решений): Таблицы решений (decision tables) хороши для описания сложной бизнес-логики, где результат зависит от комбинации условий. Например: «если сумма > 5000 и карта иностранная, то запросить подтверждение». Но для описания последовательности шагов (сначала ввод данных, потом подтверждение, потом ответ шлюза) таблица не подходит — она не передаёт динамику процесса.
D (Прототип интерфейса): Мокапы показывают, как выглядит экран, но не объясняют, что происходит при нажатии кнопок, особенно в ошибочных ситуациях. Прототип может дополнить Use Case, но не заменить его. По мокапу непонятно, что должно случиться при ошибке шлюза — просто «ошибка» или повторный запрос с таймаутом.
Совет: В реальных проектах часто используют связку: User Story — для быстрого добавления в бэклог, Use Case — для детального описания сложных сценариев. Для оплаты я бы написал Use Case с заголовком «Оплатить заказ картой», основным потоком (шаги 1-10) и таблицей альтернативных потоков (2а, 4б, 7в). Это даст разработчикам полную картину.
Please open Telegram to view this post
VIEW IN TELEGRAM
4710. Вы проектируете интеграцию между интернет-магазином и внешним платёжным шлюзом. Платежный шлюз поддерживает два варианта интеграции: REST API с синхронным вызовом и асинхронным. Какой вариант вы выберете и почему?
Anonymous Quiz
10%
Только REST API — проще реализовать и отлаживать
4%
Только webhook — асинхронность всегда надёжнее
86%
Комбинация: синхронный вызов для инициации платежа и webhook для уведомления о результате
1%
Общая база данных с платёжным шлюзом для обмена статусами
✅ Почему комбинация — оптимальное решение:
Синхронный вызов для инициации платежа:
Пользователь ожидает мгновенного перехода на страницу оплаты. REST-вызов позволяет сразу получить URL платёжной формы или токен для редиректа. Это естественно для пользовательского сценария.
Асинхронный webhook для результата:
Платёж может обрабатываться долго (fraud-проверки, 3D-Secure, межбанковские переводы). Синхронно ждать ответа — значит блокировать пользователя и держать соединение. Webhook позволяет платёжному шлюзу уведомить магазин, когда платёж точно завершён (успех/отказ). Это надёжно и не нагружает сервер магазина.
Дополнительно: синхронный запрос статуса (polling) как fallback:
Если webhook не пришёл (сбой сети), можно периодически опрашивать API для получения актуального статуса. Это добавляет надёжности.
❌ Почему другие варианты не подходят:
A (Только REST API): Если ждать ответ синхронно, пользователь будет "висеть" в ожидании, а при сбое соединения потеряет результат. Платежи могут обрабатываться минутами — это неприемлемо.
B (Только webhook): Непонятно, как пользователь сразу попадёт на страницу оплаты. Webhook — это уведомление сервера, а не редирект для клиента.
D (Общая база данных): Антипаттерн интеграции. Давать внешнему сервису прямой доступ к своей БД — значит нарушать инкапсуляцию, создавать риски безопасности и зависимости от схемы данных.
Совет: В реальных проектах всегда проектируйте платёжную интеграцию как комбинацию синхронного старта и асинхронного уведомления. Это стандарт, принятый во всех крупных платёжных системах (CloudPayments, YooKassa, Stripe).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
4711. Вы интегрируете CRM-систему с внешним сервисом email-рассылок. В вашей CRM даты хранятся в формате DD.MM.YYYY. Как правильно поступить аналитику, чтобы избежать ошибок при интеграции?
Anonymous Quiz
1%
Попросить разработчиков передавать дату как есть — сервис сам разберётся
52%
Задокументировать необходимость преобразования формата в интеграционном слое
7%
Изменить схему данных в CRM, чтобы хранить даты в нужном формате
40%
Использовать общий API-шлюз, который будет автоматически конвертировать все поля
✅ Почему вариант B — правильный:
Аналитик должен зафиксировать в требованиях правила трансформации данных (data mapping). В данном случае:
Входной формат CRM: DD.MM.YYYY (строка или дата)
Ожидаемый формат внешнего API: YYYY-MM-DD
Задача: преобразовать на стороне интеграционного слоя (адаптера, ESB или микросервиса-интегратора)
Это не требует изменения исходной CRM (что было бы сложно и дорого) и не полагается на "магию" внешнего сервиса. Чёткая спецификация маппинга — ответственность аналитика.
❌ Почему другие варианты хуже:
A (Передать как есть): Надеяться, что внешний сервис "поймёт" другой формат — наивно. Скорее всего, сервис вернёт ошибку валидации или, что хуже, интерпретирует 01.02.2024 как 01 февраля 2024 вместо 02 января 2024 (в американском формате). Это приведёт к некорректным данным.
C (Изменить схему CRM): Технически возможно, но это означает изменение ядра системы, что требует времени, тестирования и может затронуть другие модули. Непропорционально сложно для задачи интеграции.
D (Общий API-шлюз с авто-конвертацией): Создание "умного" шлюза, который пытается угадать формат и сконвертировать, опасно. Форматы дат не всегда можно определить однозначно (например, 01/02/2024 — это январь или февраль?). Лучше явно указать правило.
Совет: В документации к интеграции всегда создавайте таблицу маппинга полей, где для каждого поля указано:
Поле в источнике (название, тип, формат)
Поле в приёмнике (название, тип, формат)
Правило преобразования (например, TO_DATE(birth_date, 'DD.MM.YYYY'))
Please open Telegram to view this post
VIEW IN TELEGRAM
4712. В системе обрабатываются заказы. Из-за временного сбоя сети некоторые сообщения о новых заказах были отправлены повторно. Что нужно предусмотреть в архитектуре интеграции, чтобы избежать этой проблемы?
Anonymous Quiz
3%
Увеличить таймауты и добавить повторные попытки отправки
84%
Реализовать идемпотентность обработки сообщений на стороне получателя
8%
Использовать синхронный REST вместо очереди
5%
Хранить все отправленные сообщения в отдельной таблице для аудита