4834. Заказчик просит: «Система должна выбирать самого быстрого курьера». Разработчик реализовал выбор по расстоянию на карте. Заказчик имел в виду освобождение от других заказов. Что упустил аналитик?
Anonymous Quiz
0%
Не проверил возможность реализации
100%
Не уточнил бизнес-правило: что значит «быстрый» (время освобождения) и как его вычислять
0%
Не назначил ответственного
0%
Не сделал ручной выбор курьера
В проектах интеграции с курьерскими службами нередко возникает неоднозначность термина «быстрый». Для логиста «быстрота» может означать минимальное время до прибытия к клиенту с учётом текущих заказов курьера. Для разработчика, не спросившего уточнений, «быстро» — это минимальная дистанция на карте (евклидово расстояние или время в пути без трафика). Результат: система предлагает курьера, который находится за углом, но у него ещё три невыполненных заказа, а реально свободный курьер из соседнего района — через 15 минут. Заказчик недоволен, бизнес теряет деньги.
Что должен был сделать аналитик?
Задать уточняющие вопросы:
«Как именно измерить "быстроту"? По времени, по расстоянию, по рейтингу?»
«Учитываем ли мы текущую загрузку курьера (активные заказы)?»
«Где брать данные о времени освобождения? Из какого API?»
«Нужно ли учитывать пробки, время суток?»
Перевести ответы в измеримое бизнес-правило:
«Система выбирает курьера с минимальным ожидаемым временем прибытия к месту заказа, рассчитанным как: (время завершения текущих заказов курьера) + (расчётное время в пути от его текущей позиции до точки заказа). Данные о текущих заказах получаем из API курьерской системы. При равенстве времени выбираем курьера с более высоким рейтингом».
Зафиксировать требование с критериями приёмки:
Пример 1: Курьер А свободен и находится за углом (1 мин), курьер Б занят на 20 мин, но его время пути 5 мин. Итог: А — 1 мин, Б — 25 мин → выбираем А.
Пример 2: Оба курьера свободны, но А — 5 мин пути, Б — 10 мин → выбираем А.
Последствия для проекта, если не уточнить
Разработчик тратит время на реализацию не того алгоритма.
На приёмке выявляется несоответствие → переделка (стоит в 5–10 раз дороже, чем уточнение на этапе анализа).
Заказчик теряет доверие.
Курьеры распределяются неэффективно → задержки доставки, недовольные клиенты.
Вывод для системного аналитика
Любое субъективное прилагательное («быстрый», «удобный», «лучший», «оптимальный») — красный флаг. Всегда конкретизируйте: по какой метрике, на основе каких данных, с какими допущениями. Превратите "быстрый" в формулу или таблицу принятия решений. Это основа качественных требований.
Please open Telegram to view this post
VIEW IN TELEGRAM
4835. Команда обновила API с v1/customers (поля: id, name) до v2/customers (поля: id, firstName, lastName). Через месяц старую версию отключили. Мобильное приложение перестало показывать имена клиентов. Что нужно было сделать аналитику заранее?
Anonymous Quiz
0%
Увеличить срок предупреждения о депрекации
96%
Спроектировать политику версионирования с перекрытием (grace period) и обратно совместимые изменения
4%
Переписать мобильное приложение до отключения старой версии
0%
Откатить API до старой версии
В микросервисной архитектуре у разных клиентов (мобильное приложение, веб-версия, интеграции партнёров) могут быть разные графики обновления. Если разработчики API меняют контракт (удаляют поле
namefirstNamelastNameЧто должен был сделать аналитик
Зафиксировать требование обратной совместимости: новая версия API не должна удалять поля, которые использовались в старой. Вместо этого добавлять новые поля (
firstNamelastNamenameВнедрить grace period: объявить дату устаревания (deprecation) старой версии, например, через 6 месяцев. Всё это время обе версии работают параллельно. В ответах старой версии добавить заголовок
Deprecation: trueПлан миграции: клиенты (мобильное приложение) должны перейти на новую версию в течение grace period. Только после того, как все клиенты переключились, старую версию можно отключать.
Мониторинг: отслеживать, какие клиенты всё ещё используют старую версию, и напоминать им о необходимости обновления.
Почему не подходят другие варианты
A (увеличить срок предупреждения) — без политики параллельной работы и обратной совместимости всё равно ломает клиентов в момент отключения.
C (переписать мобильное приложение до отключения) — на практике часто невозможно, так как обновление зависит от пользователей.
D (откатить API) — временное решение, не решающее проблему в будущем.
Реальный пример
GitHub API версионирует через даты (например,
2022-11-28SunsetВывод для аналитика
При проектировании API всегда закладывайте:
Параллельную работу нескольких версий.
Минимальный срок поддержки старой версии (например, 6–12 месяцев).
Обратную совместимость: добавляйте поля, не удаляйте и не меняйте типы существующих.
Механизм уведомления клиентов о deprecation (заголовки, email, документация).
Please open Telegram to view this post
VIEW IN TELEGRAM
4836. Пользователи говорили: тёмная тема важна, проверка орфографии — нет. После релиза орфографией пользуются все, а тёмную тему — единицы. Какую ошибку допустил аналитик?
Anonymous Quiz
2%
Не проверил реализуемость темной темы
88%
Не использовал модель Кано (не разделил требования на базовые, линейные и «восхитители»)
1%
Не согласовал приоритеты с разработчиками
10%
Опросил слишком мало пользователей
Модель Кано классифицирует требования по влиянию на удовлетворённость:
Базовые (must-have) — если их нет, пользователь сильно недоволен, но их наличие не повышает лояльность (например, проверка орфографии: пользователи её ожидают, но не говорят о ней).
Линейные (чем больше, тем лучше) — например, скорость работы приложения.
Восхитители (attractive) — неожиданные фичи, которые вызывают восторг (тёмная тема для некоторых аудиторий).
Ошибка аналитика: он спросил «насколько важно?» и получил ответы, не отражающие реальной категории. Базовые фичи кажутся неважными («это и так должно быть»), а восхитители — переоценёнными в опросах. Правильный подход: задавать вопросы в паре: «Как вы отреагируете, если функция есть?» и «Как отреагируете, если её нет?». Тогда можно определить тип.
Реальный кейс: В одном приложении доставки пользователи говорили, что «отслеживание курьера в реальном времени» важно, а «точное время доставки» — нет. После внедрения оказалось, что точное время гораздо критичнее. Модель Кано помогла бы выявить, что точное время — базовая функция, а трекинг — восхититель.
Вывод: Аналитик должен использовать модель Кано для выявления скрытых ожиданий и не доверять прямым оценкам важности.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
4837. Заказчик требует, чтобы «система работала без перебоев». Что аналитик должен указать в SLA вместо этого?
Anonymous Quiz
13%
Система должна быть доступна 24/7
85%
Доступность 99.9%, время восстановления после сбоя — не более 1 часа»
0%
Перебоев быть не должно
1%
Администраторы будут следить за системой
Доступность (uptime) — например, 99.9% (это допустимо ~43 минуты простоя в месяц).
RTO (Recovery Time Objective) — максимальное время восстановления.
RPO (Recovery Point Objective) — допустимые потери данных в минутах/часах.
Время отклика поддержки — например, ответ в течение 15 минут.
Без этих цифр заказчик и исполнитель будут спорить: «перебой» — это 1 минута или 1 час? SLA позволяет объективно измерить качество обслуживания.
Реальный пример: В контракте на облачный сервис прописывают 99.95% доступности. Если простой превышает оговорённый лимит, исполнитель выплачивает штраф.
Вывод: Аналитик должен переводить расплывчатые пожелания в измеримые SLA.
Please open Telegram to view this post
VIEW IN TELEGRAM
4838. Партнёр загружает выгрузку в SFTP. Ваша система забирает файл и удаляет его. Если обработка файла упала, файл теряется. Как доработать интеграцию, чтобы избежать потери данных?
Anonymous Quiz
20%
Не удалять файл, а переносить в папку failed
76%
Использовать двухстадийную обработку: сначала переименовать файл, после успеха — удалить
3%
Копировать файл на локальный диск
1%
Обрабатывать файл в исходной директории
Алгоритм:
Заметить файл
data.csvПереименовать в
data.csv.processingОбработать содержимое.
Если успех — удалить
data.csv.processingЕсли ошибка — переименовать обратно в
data.csvdata.csv.errorПочему это лучше, чем просто перемещать в
failedРеальный пример: В банковской интеграции с партнёрами используется паттерн
*.inprogressВывод: Аналитик должен закладывать в требования двухстадийную обработку для любых интеграций через файловые обменники.
Please open Telegram to view this post
VIEW IN TELEGRAM
4839. В DWH нужно хранить историю изменения адреса клиента. При обновлении адреса старый адрес должен сохраниться для прошлых заказов. Какой тип SCD (медленно меняющегося измерения) применить?
Anonymous Quiz
1%
SCD Type 0 (без изменений)
83%
SCD Type 2 (новая строка с датами начала и окончания действия)
5%
SCD Type 1 (перезапись)
11%
SCD Type 3 (отдельная колонка «предыдущий адрес»)
end_date = nowstart_date = nowstart_dateend_dateПочему не Type 1 (перезапись) – потеря истории.
Type 3 (отдельная колонка «предыдущий адрес») – хранит только текущий и предыдущий адрес, но не полную историю.
Type 0 – вообще без изменений.
Реальный пример: В розничной сети SCD Type 2 используется для измерения «Клиент», чтобы видеть, по какому адресу был сделан каждый заказ несколько лет назад.
Вывод: Аналитик должен выбирать тип SCD в зависимости от того, нужна ли история, и как далеко нужно видеть прошлые состояния.
Please open Telegram to view this post
VIEW IN TELEGRAM
4840. Распределённая система должна одновременно обеспечивать строгую согласованность данных (consistency) и доступность при любых сбоях. При сетевом разделении система перестаёт принимать записи. Какую теорему иллюстрирует этот пример?
Anonymous Quiz
4%
Теорема Геделя о неполноте
95%
CAP-теорема: из трёх свойств можно гарантировать только два
0%
Закон Амдала
2%
Теорема Коуза
В 2000 году Эрик Брюер сформулировал, что в распределённой системе невозможно одновременно гарантировать три свойства:
Consistency (C) – все узлы видят одни и те же данные в один момент времени (нет устаревших копий).
Availability (A) – каждый запрос получает ответ (даже если некоторые узлы недоступны).
Partition tolerance (P) – система продолжает работать при разрыве связи между узлами (сетевом разделении).
При возникновении сетевого разделения система вынуждена выбирать между C и A:
CP‑система (например, HBase, MongoDB с настройкой по умолчанию) жертвует доступностью: при разделении блокирует запись, чтобы не нарушить согласованность.
AP‑система (например, Cassandra, CouchDB) жертвует строгой согласованностью: возвращает данные, которые могут быть устаревшими, но система остаётся доступной.
Почему это важно для аналитика?
При выборе базы данных для распределённой системы (например, банковской или социальной сети) вы должны понимать, что невозможно получить и строгую согласованность, и абсолютную доступность при любых сбоях.
Финансовые транзакции – приоритет согласованности (CP). Даже если система временно недоступна, деньги не должны потеряться.
Лента новостей – приоритет доступности (AP). Лучше показать слегка устаревшие новости, чем вообще не открыть приложение.
Реальный кейс:
В Amazon при оформлении заказа применяется строгая согласованность (CP), а при просмотре каталога — eventual consistency (AP). CAP-теорема помогает объяснить такие архитектурные компромиссы заказчику.
Вывод:
Аналитик, знающий CAP-теорему, может аргументированно выбирать хранилище данных под бизнес-требования, понимая неизбежные компромиссы.
Please open Telegram to view this post
VIEW IN TELEGRAM
Если коротко, то ИИ уже не будущее, а наше настоящее.
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
* Он пишет тексты, анализирует данные, автоматизирует продажи, создает изображения и экономит десятки часов в неделю.
Вопрос уже не в том, заменит ли ИИ людей.
Вопрос – кто быстрее научится им пользоваться.
Специально для тебя ПОДБОРКА сильных экспертов в сфере ИИ
Включайся сейчас - 1 клик, без смс и регистрации. 🏁 Не отставай. Или обгоняй.
Делимся знаниями и аудиторией — растём вместе ⚡️
Забирай ПАПКУ бесплатно. Ссылка действительна 24 часа
* Отписаться можно в любой момент. Остаться — тоже. ✔️
Ссылка ➡️ https://t.me/addlist/n__Pk89IyogzOTVk
🔥1