Ситуация: В проекте интеграции СДЭК логистики в наш маркетплейс написал задачу на системного аналитика по маппингу статусов заказа, чтобы после интеграции была их синхронизация.
Вот моё изначальное описание:
Реализовать забор и синхронизацию статусов от CDEK с помощью интеграции.
Цель: Обеспечить синхронизацию по смене статусов заказа в маркетплейсе в момент смены на стороне СДЭК.
Тем самым дать понимание где заказ:
-
для клиента в приложении,
-
для селлера в б2б ЛК,
-
для клиентской и б2б поддержки в суперсете,
-
для ДИ в базах доменов.
Получил вопрос от системного аналитика:
можем просто отдавать статус СДЭК. Это закроет потребность?
-
Опишите, что (какие объекты) должно измениться в физическом мире после того, как задача будет реализована. Явно пропишите: с точки зрения какой роли вы будете смотреть на ситуацию. Альтернативно: опишите, что вас смущает, что у вас “дребезжит”, то есть, распишите нынешнюю ситуацию/контекст с выбранной точки зрения/viewpoint.
Изменятся описания состояний заказов/посылок в цифровых эпистемах маркетплейса, при этом физически изменятся лишь байты как блоки информации на серверах.
Так же люди из 4х групп интересов в реальном мире будут видеть на экранах достоверную информацию о том где находится заказ/посылка.
В некоторых случаях результатом итоговой работы по интеграции будет, что утерянные и застрявшие в логистике посылки будут быстрее находиться и возвращаться в процесс доставки или возврата на склад, селлеру.Я смотрю на ситуацию из роли менеджера айти продукта (продакта), предмет интереса которого - регулярно удовлетворяемые интересы других ролей (клиент, селлер, саппорт) в продукте - знать где заказ.
-
*Выделите в описании агентов, которые будут теперь действовать иначе. Назовите эти иные действия. Назовите результаты этих действий: какие объекты изменят состояния (с точки зрения выбранной роли), назовите создаваемые артефакты. Проверьте, назвали ли вы все объекты из пункта 1?
*
Клиент будет действовать иначе - планировать время и место когда он получит посылку, забирать посылку, договариваться с поддержкой о переносе дат и продлении сроков хранения, отменять забор заказа, не забирать посылку без уведомления поддержки - просто не приходить.
Соответственно и поведение менеджеров клиентской поддержки, администраторов ПВЗ и курьеров будет подстраиваться под то как ведёт себя клиент.
Меняться будут деньги, оплачиваемые компанией за труд и логистику по агентскому договору со СДЭКом.
Селлер будет дольше или наоборот быстрее получать комиссию за свои проданные заказы и менять стратегию размещения товаров на маркетплейсе. -
*Распишите, каким образом/способом/методом вы будете проверять, что в физическом мире произошли нужные вам изменения. Какие замеры вы будете делать, чтобы увидеть, что изменения реальны, что вы будете измерять?
*
После запуска интеграции проверю статусы в эпистеме СДЭКа и маркетплейса.
Узнаю у руководителей клиентской поддержки были ли обращения от клиентов о неверных статусах. -
*При каких условиях результат возможно получить? А при каких невозможно?
*
API СДЭК доступны для обмена данными о статусах заказов.
Если системный аналитик и программист верно поняли описание задачи и выполнили её, тестировщик проверил результат их работы и подтвердил, что интеграция работает на основе созданных им тест-кейсов. После этого тимлиды команд ПВЗ и WMS выпустили релизы. -
Какие сигналы могут вам указать заранее на то, что делается что-то не то?
Системный аналитик задаёт вопросы какие статусы нужно учитывать, а какие нет, при этом имеет полное представление о том как работает обмен статусами между доменами в маркетплейсе сейчас. Значит он не понимает цели задачи, либо не хочет на себя брать отвественность, что ближе к правде. Следовательно не может сопоставить статус модель маркета с СДЭК документацией - это и произошло.