На этой странице
В условной интеграции заказаны двенадцать полей. Три определяют возможность первой одобренной синхронизации: идентичность клиента, аудитория назначения и разрешение на маркетинг. Остальные девять могут понадобиться позже. Если сейчас уделить всем одинаковое внимание, команда потратит неделю на дополнительные атрибуты, а первую безопасную запись так и не выполнит.
Ограничение меняет разговор. Дайте первой версии пять мест для проверки и поместите каждое поле в одно место. Шестое требует назвать поле, которое выйдет из списка.
Это не утверждение, что пять мест являются правильным числом. Так становится видна цена ещё одного запроса.
Приём работает и тогда, когда узким местом являются не люди. Поставщик допускает ограниченное число запросов за период; окно миграции позволяет одно изменение до проверки; поддержка успевает подтвердить лишь несколько клиентских сопоставлений. Полезное ограничение касается ресурса, который остановит результат даже при избытке остальных.
Список задач может скрывать свою цену
В обсуждении ограничений и творческой работы команда сделала недельный ресурс осязаемым с помощью физических меток. Дальнейшая отделка маленькой детали требовала забрать метки у другой работы. Приём не решал, что красиво. Он делал компромисс заметным.
Команды разработки обычно держат метки невидимыми. Запрос попадает в трекер, получает пометку приоритета и лежит рядом с двадцатью другими «важными» запросами. Пометка не говорит, какую проверку, миграцию или беседу с клиентом придётся отложить.
Для интеграции дефицитом может быть лимит запросов поставщика, доступ к настоящему тестовому аккаунту или время на изучение смысла согласия. Видимое ограничение должно назвать ресурс, сдерживающий результат, и показать, как предлагаемая работа его расходует.
Руководство Tajo по интеграции бизнес-инструментов предлагает сначала определить процесс и источник истины. Это не даёт списку разрастись вокруг каждого возможного поля. Для первой синхронизации нужны данные, обязательные для её фактического результата.
Выберите решающее, остальное отложите
В условной схеме из двенадцати полей решающих немного. Идентичность определяет изменяемую запись назначения. Разрешение определяет, можно ли использовать её для маркетинга. Принадлежность к аудитории определяет следующий процесс. Если эти три элемента неверны, остальные девять результат не спасут.
План может показывать решающие поля рядом с занимаемым ресурсом. Допустим, для каждого нужны определение, тестовый пример и проверка назначения. Сначала зарезервируйте эти проверки. Дополнительное поле предпочтения должно ответить: меняет ли оно первую работающую синхронизацию или подождёт?
Ожидание не означает неважность поля. Это частичный порядок. Ближайшая зависимость определена; остальные остаются доступными, когда данные или спрос клиента сделают их актуальными.
Отсрочку запишите явно. Поместите девять полей в следующую очередь и укажите условие продвижения каждого: названный сценарий, запись клиента, которой поле нужно, или требование контракта поставщика. Это отличается от потери запроса в общем списке. Условная очередь сохраняет варианты и защищает первый результат от предположительного объёма.
Разумное возражение: «Искусственные пределы душат команду и скрывают полезную идею». Да. Предел, защищающий неверный приоритет, сам становится проблемой. Запишите рядом с пределом результат и пересматривайте оба. Если новое поле оказалось обязательным для согласия, оно немедленно вытесняет необязательное обогащение. Ограничение показывает изменение, а не запрещает его.
Метки ресурса обнаруживают и скрытые разногласия. Одна команда видит ограничение во времени разработчиков; другая знает, что ждут администратора назначения. Дополнительные места для разработчиков тогда ничего не меняют. Проследите работу до утверждённой первой записи и поставьте предел на реально задерживающем шаге.
Какое поле получает место в первой синхронизации?
-
Нужно для идентичности, разрешения или аудитории
Проверить сейчас
Без него первая одобренная запись не определена.
-
Нужно для названного будущего сценария
Задать условие продвижения
Сохранить запрос, не задерживая первый результат.
-
Влияние на результат не определено
Отложить запрос
Не тратить дефицитную проверку на предположительный объём.
Измерьте пользу ограничения
Нужный график не «закрытые запросы за месяц». Покажите путь от запроса до первого правильного результата и препятствия на нём. Не ушло ли время проверки на необязательные поля? Не задержало ли отсутствующее определение поставщика все испытания? Сэкономила ли команда время, отложив панель, не нужную для запуска?
Не придумывайте прирост производительности. Для настоящей партии измерьте до и после: дни до утверждённого сопоставления, число проверенных в назначении полей и проблемы после запуска. Ограничение полезно, только если меняет эти результаты.
Руководство по Reverse ETL отделяет регулярное перемещение данных от определения его сопоставления. Ранний объём сильнее всего влияет на сопоставление. Дополнительные данные можно добавить позже; первый контракт должен быть правильным сейчас.
Список говорит, что попросили. Видимый предел говорит, чего это стоит.
Часто Задаваемые Вопросы
Как видимое ограничение улучшает приоритизацию?
Оно показывает, что новая задача забирает время или возможности у другой. Команда может сравнить вытесняемые результаты, а не считать каждый запрос бесплатным.
Что команда должна сделать видимым?
Конечный ресурс, действительно ограничивающий работу: время проверяющих, лимит запросов назначения, ресурсы миграции или число клиентских сопоставлений, которые можно проверить.
Могут ли ограничения стать произвольной бюрократией?
Да. Предел должен защищать названный результат и пересматриваться при новых данных. Декоративный лимит, скрывающий важную работу, тоже является потерей.