Почему это реальный кейс?
В проектах интеграции с курьерскими службами нередко возникает неоднозначность термина «быстрый». Для логиста «быстрота» может означать минимальное время до прибытия к клиенту с учётом текущих заказов курьера. Для разработчика, не спросившего уточнений, «быстро» — это минимальная дистанция на карте (евклидово расстояние или время в пути без трафика). Результат: система предлагает курьера, который находится за углом, но у него ещё три невыполненных заказа, а реально свободный курьер из соседнего района — через 15 минут. Заказчик недоволен, бизнес теряет деньги.
Что должен был сделать аналитик?
Задать уточняющие вопросы:
«Как именно измерить "быстроту"? По времени, по расстоянию, по рейтингу?»
«Учитываем ли мы текущую загрузку курьера (активные заказы)?»
«Где брать данные о времени освобождения? Из какого API?»
«Нужно ли учитывать пробки, время суток?»
Перевести ответы в измеримое бизнес-правило:
«Система выбирает курьера с минимальным ожидаемым временем прибытия к месту заказа, рассчитанным как: (время завершения текущих заказов курьера) + (расчётное время в пути от его текущей позиции до точки заказа). Данные о текущих заказах получаем из API курьерской системы. При равенстве времени выбираем курьера с более высоким рейтингом».
Зафиксировать требование с критериями приёмки:
Пример 1: Курьер А свободен и находится за углом (1 мин), курьер Б занят на 20 мин, но его время пути 5 мин. Итог: А — 1 мин, Б — 25 мин → выбираем А.
Пример 2: Оба курьера свободны, но А — 5 мин пути, Б — 10 мин → выбираем А.
Последствия для проекта, если не уточнить
Разработчик тратит время на реализацию не того алгоритма.
На приёмке выявляется несоответствие → переделка (стоит в 5–10 раз дороже, чем уточнение на этапе анализа).
Заказчик теряет доверие.
Курьеры распределяются неэффективно → задержки доставки, недовольные клиенты.
Вывод для системного аналитика
Любое субъективное прилагательное («быстрый», «удобный», «лучший», «оптимальный») — красный флаг. Всегда конкретизируйте: по какой метрике, на основе каких данных, с какими допущениями. Превратите "быстрый" в формулу или таблицу принятия решений. Это основа качественных требований.